1.NBearV3.7.2_tutorials\cases\SimpleGuestbook：看这个对NBear的分层设计会有直观了解了。
2.NBear Offical Site v1.0.2: 这个比较实际的应用，不错。就是nbear.org的程序
3.NBear_PetShop: 这个不错，里面还可以看到DBHelper的写法
4.NBearManual_CN.exe/NBearV3中文教程.CHM/NBearV3 SDK.chm：学习、了解的帮助文档，推荐看看！不过可能过时滞后了。
5.v3版的教材汇总，重点学习！http://www.cnblogs.com/teddyma/archive/2006/11/07/553562.html
6.NBearV4预告及开发团队成员征集 http://www.cnblogs.com/teddyma/archive/2007/07/22/827346.html
上述资源在Nbear.org或博客园NB博客里都可以找到。
http://nbear.org
http://nbear.cnblogs.com
1.安装插件SetupNBearVsPlugin.exe
2.建表
3.用NBear.Tools.DbToEntityDesign.exe从数据库生成EntityDesign类，include到designs项目。
4.配好EntityDesignToEntityConfig.xml，编译Designs 项目,则插件会自动生成或更新entity/EntityImpls.xml（有新表或改了表，重复3/4）
5.配web.config里的connectstring、components
6.设计service类及接口，写ServiceInterfaces、ServiceImpls
7.在WebUI里调用IOC,Entity,ServiceInterfaces,完成业务操作。
注：个人觉得建表还是较好的，不习惯“先设计类图，再从类图生成design、表”。一是类图里直接得到不了 [SqlType("nvarchar(64)")]这样的代码，还得手写，二是大多习惯了先有表再有对象了，感觉更快。

以下是粗略看看NBear3.7.2版本的感觉，也给出了一点和castle的activeRecord的简单比较。
总的感觉nbear是不错的，它和castle方案在分层设计上基本是一样的，就是ORM的使用上有点不同。和castle方案的比较的感觉是：castle会更简单好上手一点，nbear的学习要长点时间。

一、优点：
1.提供了应用层的一些包装，省了不少事：
a.分布式部署的实现
b.序列化、多语言
c.ajaxhelper/WebUtil等

2.ORM的性能可能会比ActiveRecord好。(activeRecord是在NHibernate外包装了一层，性能又消耗了点。另外不能精确的设定NHibernate的属性和用法，可能也会导致性能上的担忧)

3.支持多种数据库。与activeRecord比，应该可以省略“自己扩展DbHelper”？
a.AR考虑性能问题，个人推荐用法应该是“增删改用AR，查询用自己扩展的Db”。
在NBear里看到里面有gateway.SelectDataReader()/gateway.ExecuteNonQuery()这样的接口，即NBear已经提供了DBHelper，并且还加了一点针对多数据库的包装，可能会比自己封装DBHelper更“跨数据库”一点。（不过估计不能完全避免“写select sql导致在特定数据库用不了”的问题）

4.提供了若干好用的工具，可加快开发
a.从数据库生产EntityDesign类的工具：NBear.Tools.DbToEntityDesign.exe
b.从类图自动更新Entity和EntityImpls.xml(及更新数据表结构)的VS2005插件：SetupNBearVsPlugin.exe
c.从EntityDesign.dll生产entity/EntityImpls.xml(及SQL）的工具：NBear.Tools.EntityDesignToEntity.exe （有插件后就用不上了）

二、缺点：
1.学习成本高，文档写得不够简单易懂。一开始要花一些时间去学习熟悉。（有内部培训可能会好点）
2.更新快，版本向后兼容做得不够。（已计划v4版本了，变动更大）
3.ORM里3.7后的版本估计会搞得太复杂了点，过度包装。像LINQ了，需要学一套不通用的语法，太麻烦。另外性能怎样，能否支持一些较好用的SQL写法，也有待检验。
4.多出了一个EntityDesign层，可以省掉会更好。没有像activerecord那么简单简捷，另外还多了个EntityImpls.xml。（design层感觉是一个为了生成design和EntityImpls.xml的设计，最终没有用上。还不如先设计数据库，再自动生成entity）
5.WebUI和ServiceInterface层都引用了Entity层。这意味着把架构和NBear完全绑到一块了。
（如果不引用Entity,理论上是完全可以替换serviceInterface的实现层的，比如说完全换成用另一个ORM框架来写。）
当然它可能是把Entity当DTO来用了，方便分布式方案里的传对象参数的问题。==》未尝不可吧，这样也挺好用的。
6.最终分层设计会做成”贫血领域模型“，也就是entity实体对象只有数据没有动作。从OO的本意(对象=”数据+动作“的封装)来说，这当然不是一个好的设计。==》目前不能定论，应该也没什么问题的。entity里肯定是不能加方法进去了(分布式DTO的考虑)，这意味这service层会写成“事务脚本”类似的效果，设计不好控制不好的话，service类会写得很大很乱。
7.国内开源项目，有不能持续、健康发展的担忧。毕竟国内的开源商业模式不成熟，要工作之余搞开源项目，恐怕支持、升级力度不够，不持久。(不过好在是开源，不行自己改一下扩展一下也可以)

 

《UML三大硬伤》，一个弟兄攻击了一下UML，也来说说个人的一点理解吧。原文见下面的链接。

至少UML里的用例图、活动图、状态图、类图、时序图还是很好用的（目前我也只用到这个程度了）。用例图主要可以提供一个软件功能的大视图，并且也初步的把使用者的权限范围表达出来了；活动图好理解，相当于流程图，表达业务流程乃至程序算法时都是常用的；状态图和活动图互补，有时用状态机转换来表达一些业务流转等很清楚；类图用来表达实体关系图、表达类的设计时很好用；时序图可以用来表达业务流程和接口交互，尤其用来表达类之间的接口（方法）是怎么调用交互时，非常清楚。

UML可以用在系统分析阶段（用例图/活动图/状态图（业务建模）、类图(领域建模））、也可用在软件设计阶段（类图(类/对象设计）、活动图（算法描述）、用例实现(时序图，接口交互)）。并且，通过用例实现，就把分析阶段和设计阶段连接起来了，前者就是OOA,后者就是OOD,然后接下来的弟兄能看懂理解上述产出，基本照着实现程序就可以了，也就是OOP.这样一套下来，也就是说UML是帮助应用面向对象技术的一种表达方式，或许还有其他的表达方式（比如敏捷方法里的“代码就是设计”，通过不断重构来实现？），但至少这种方式算是不错的。当然最终的效果，还是要看设计者的内功。

人是最关键的，UML只是种表达方式，只是个工具而已。很多弟兄感觉UML没用，或许只是他们不习惯用而已，也就是他们不习惯UML这种软件分析、设计的表达方式而已。用惯UML的弟兄会觉得UML好用、能清楚表达自己的意思，看得懂UML的弟兄会觉得好理解，知道设计者要表达的意思--这也就是UML的价值所在；而不习惯用UML的弟兄就会觉得UML没用，不如用其他的表达方式。如此而已。

因为我习惯用Rose的原因，或许不免有些偏向UML还是好用的观点。不过也不觉得它有多精妙。或许是要看用的程度吧，而国内的软件环境，就中小企业来说，可能是不允许你用得那么深的，不能承受这个成本。

上述夸夸其谈，未经最终检验。之前本来很想试试能做成什么效果的，可惜一直没这个机会。这么一套搞下来，时间精力都不允许。

UML三大硬伤 http://www.vchome.net/swengineer/umlrosecmm/uml01.htm，回复比原文更精彩感觉，值得一看。

下面是在考虑公司内部的协作平台时的选型说明，贴出来供有需要的弟兄参考。
 
“软件开发协作平台”需求是
a.支持项目管理、BUG及用户支持管理；b.内部公告；c.可定制流程、可自定义字段；d.权限控制；e.Email通知及监控 f.统计报表及导出 g.最好易扩展

狂找一顿后的选型结果就是：“URTracker+Excel”。0321Update:最终还是“Mantis+Excel”了，考虑到URTracker收费的问题，因为要推广到全公司5个帐号就不够了。

具体操作的模式是：用excel来做项目计划、任务分解、记录指派、进度总结；用URTracker来分派任务并作进度反馈/跟踪。其中用“分级/组合”的效果可以做出像project那样任务分级下拉、收起的效果，用“数据透视表”可以方便实现统计分析的效果。project就没必要用了，常用的功能无非就是那几个，实在不需要这么庞大无聊的东西，excel就很好用。

注：选它的理由，是它可以很方便的定制流程、自定义字段，而且把项目管理和bug管理、需求管理都可以通过定制的方式，纳入同一个平台了;另外你可以看到它的sql server数据库，这样很方便你写sql或扩展程序，以得到需要的统计分析报表。mantis的字段也可以自定义，但唯一的不足就是不能加流程状态，它可以定制流程，但是状态就是那几个状态，加不了。

当然，“工具配合的是管理”，关键还是人。没有相应的理念，再好的工具也是白费。目前这个平台也未经验证，具体使用效果，以后再来总结。

需注意，URTracker是收费的，但是有5个帐号的免费版，可以满足小团队。以后如果要注册，45元/帐号，应该也可以接受。如果你一定要免费，那可以用mantis代替之，缺陷是流程定制的效果差点。
 
1.URTracker：
http://www.lealsoft.com/urtracker/
优点：可以满足我们的需求，操作也较符合国内习惯，另外是.net+sql 做的，可方便自行扩展。(内部公告可以用知识库来代替)
缺点：收费。(但是有5个帐号的免费版)

2.Mantis：
www.mantisbt.org/
如果要用免费的软件，就是这个了。它的不足除了流程状态不能加外，项目管理只能通过当一个bug项目来做，这样感觉可能不是很爽，有点折衷。

3.http://at.tryphpgroupware.org/phpgroupware/login.php
优点：可支持项目管理及bug,内部公告。(流程及自定义字段未知)。另外集成的功能模块较多，日历、论坛、wiki等。开源免费。国外开源会不断升级。
缺点：操作习惯没这么好，另外是php+mysql做的，较难扩展。

4.http://egroupware.outdoor-training.de/egw-head/login.php
优点：可支持项目管理及bug,内部公告。(流程及自定义字段好像不行?)。另外集成的功能模块较多，日历、论坛、wiki等。开源免费。国外开源会不断升级。
缺点：操作习惯没这么好，另外是php+mysql做的，较难扩展。

5.Sawin2006研发协作平台
http://www.sawin.cn/OpenProject/sawin2006/welcome.htm
界面、流程不符合我们的需求，不作考虑。
支持需求管理及bug管理。开源。

6.BugFree:
http://bugfree.1zsoft.com/Demo/
功能较简单，不能满足项目管理的需求。优点是界面设计比较清晰。用来做bug管理还是可以的。当然个人感觉Mantis用惯了。

7.https://gforge.org/
可能更适合开源软件，效果未知。可以支持项目管理及bug管理。

8.JIRA：
据说也可以支持项目管理和bug，且还可以，不过是收费的(对开源项目免费)。见
http://blog.csdn.net/judyxm/archive/2006/04/26/678456.aspx 

9.其他收费的软件，应该还有些。在此不找了。
http://www.php-open.com/ 有些开源软件。

最后，最近的发现，Windows SharePoint Services 3.0似乎都可以满足需求，似乎很不错。不过太庞大了点，维护也不好做，暂不考虑了。说明见这里：http://www.cnblogs.com/cleo/archive/2007/03/16/SharePointV3_Templates_Demo.html

考虑整合一个ORM框架，顺手把找到的资料索引一下，供大家参考。

NET开源项目介绍及资源推荐：数据持久层 
对.net的常见ORM有简略但不错的说明。一个好的总结和指引。

ORM之硬伤 
是对“ORM的缺点论”进行反驳的一篇最言之有物的一个帖子。楼主认为ORM的真正问题是国内.net程序员的OO功力不够。帖主尤其强调在“性能及复杂查询”的问题上认为是没有问题。
robin:个人认为“性能及复杂查询”是否有问题还有待验证。所以我还是推荐复杂查询还是自己扩展DBHelper来做，直接有效。

O/R Mapping，陷阱还是苹果？ 
这里对ORM的反思较为深入，使用ORM之前，值得参考考虑一下。

大型软件开发与ORM构架
帖子对选用ORM的前期预研、验证要求给出了一些指引。对企业使用新技术的预研、验证，也即新技术的风险控制，有不错的说明。
robin:确实大家不要听到ORM是个好东西就乱用，应该要经过严谨的验证、考虑才能用。

再次小结领域模型的种种观点 
这个帖子是在领域模型的设计方面讨论最深入的一个中文帖子。非常值得一看。
主要是讨论了”贫血模型“的经典问题。
给出了实际例子。注意其中的”rich domain object“里，domain是不依赖于DAO的。
robin:
1.感觉用NH的弟兄，大多都是写成了”贫血领域模型“，也就是实体对象只有数据没有动作。(这也是我有疑惑，目前还不能定的问题)。从OO的本意(对象=”数据+动作“的封装)来说，这当然不是一个好的设计。但是用了ORM后，如果要对象包括动作，domain object就要访问DAO，这又导致了双向依赖问题。
2.目前在分层设计上，仍存在疑惑。有待验证。

NHibernate下持久化类的两种设计，哪种更好一些？ 
讨论”NHibernate下持久化类的设计时关于关于对象的操作和数据是否应该剥离的问题“，给出了两种方式下的实现，值得参考。里面的回复里的讨论也颇有价值。
robin:贫血领域模型用的就是第一种方式。Castle ActiveRecord用的就是类似第二种方式。

使用NHibernate的系统体系结构
帖子给出了一种比较”传统“的NH的分层设计，有一定的参考价值。
robin:UI引用Domain、Domain引用NH DAO,都是有争议的。

Enterprise Persistence Design
帖子对ORM的意图作了逐步渐进的分析说明，对service/domain/DAO的分层设计作了原理上的讨论，值得推荐。
robin:依据这个理论做出来的分层设计，基本上就是hibernate的经典写法：贫血领域模型。但是帖主强调的” 不该做的不做(Separate persistence from business）、该做的要做(Implement business）、自己独力不能做的交给别人做(Delegate, Façade)”，很有意义(注意理解英文，更能体现本意)。“再次小结领域模型的种种观点”的弟兄认为：设计持久化的动作就放在service,不涉及持久化又适合放在domain的就放在domain。这个观点值得参考，但是有待验证实际效果怎样。讨论：是否可以省略DAO,直接在service调用NH的接口，完成持久化对象的职责？（不过这样就类似事务脚本的写法了）

从我的亲身经历来说说我对ORM的一些看法 
帖子认为”先有对象再映射到数据库才是使用ORM的正途。“。认为目前.net社区的弟兄的关于ORM的争论根源，就是来自于大家是先R(数据库)再O(对象），这个根本性的错误应用方法，也正是导致”ORM的缺陷“的根源。
robin:这个观点值得考虑、分析。但“先O再R”在实际开发是否真的适用，有待验证。

O/R Mapping乱弹 
帖子提出了”先O再R“还是”先R再O“的问题。认为ORM的价值在于可以支持你”从面向对象的角度分析考虑问题“。即先建立领域模型(O)，再通过ORM直接导出生成表设计(R)。
robin:这似乎是提出了ORM的”终极价值“。但感觉缺乏验证(跟贴的弟兄也提出质疑)。我个人也存在怀疑，先O再R是否真正可行。毕竟数据库设计本身就是一个非常专业、需要一定功力的事情，一个好的表设计是需要功力的，尤其是在性能提升方面。先O是否能直接映射生出本应该精心设计的表？存疑。更实际的做法可以是”先用OO作领域模型设计，再参考领域模型，完成数据库设计“。在数据库设计阶段，会应用一些专业的设计技巧，这个估计是对象所体现不了的。

O/R Mapping再乱弹
”ms注重数据，java注重动作(逻辑)“，这个帖子解释了为什么在.net上用ORM会有这么多困惑：因为ms平台上一向都是不OO实现的，一向都是表模块方式、事务脚本方式。
robin:一语惊醒梦中人，确实如此。微软平台的弟兄们，大多就算用c#这样的OO语言，也是将class当一个事务脚本类来写的。这么多年，一样写出了不少应用。
我个人就觉得是否需要使用ORM，是否需要转向真正的OO的写法，是需要根据本公司的具体情况作实际验证的--是否能提高效率，是否能提升设计？有没有可以胜任OO设计的设计人员？开发组成员的OO思维的学习成本有多高？需要考虑一个投入及收益的问题，不能为了OO而OO，为了ORM而ORM。

结束无谓的讨论吧
这位弟兄试图结束ORM的争论。并认为如果你的写法根本不是OO，那就没必要讨论ORM了。
robin:这又牵扯回”国内.net程序员OO功力不够“的问题了。确实是有这个问题。但是个人认为就算OO功力不够，ORM也是有意义的，至少可以将它当一个快速开发的代码生成器来用(如Castle ActiveRecord)。另外也确实是，用ORM，OO，其实对团队的设计能力有较高的要求，如果设计能力跟不上，反而不如直接用”表模块“、事务脚本的写法更有效。

分布式应用架构中的数据传输对象（DTO）
对DTO的常见实现方式及其优劣点，作了不错的描述，值得参考。
.Net 2.0: Entity as DTO vs Dataset as DTO / Xml Serialization vs JSON Serialization
这里有实际的测试。并认为dataset是一个好的DTO方案。
PO,VO,DTO....
PO,VO,DTO的一点讨论.
robin:个人倾向与用datatable和标量。最好不要再自己写dto对象，序列化等麻烦。有弟兄说在“贫血领域模型”里，可以将domain object当DTO用(不含持久化职责的Domain Object)，可以参考，但总觉得domain object不应暴露给UI，应用Service隔开才是好的设计。

 

 

 

这是标在原型上的功能规格说明的模版。实践证明还行，帖在这里或可给有需要的弟兄参考。
能在原型的UI上直接标上的功能说明，就近标在原型上控件旁边了，这是在主要界面上用text写的补充说明。
因为没有写独立的文本用例，所以在这里用“一、功能使用者及涉众利益”、“六、应用场景”、“七、客户收益”，兼顾了一点用例的效果，对功能的意图可以做一点说明。
有一点疑问：有没有弟兄写过很正规的功能规格书？比如“joel说软件”里提到的功能规格书那样的？

----------------------------------------
功能规格说明格式

一、功能使用者及涉众利益
  说明功能提供给什么角色用，对每个角色有个独立的说明

二、界面默认状态
  描述界面初始进去的状态，各个界面元素的默认效果

三、其他业务逻辑说明
  描述不便在UI、或未体现在UI上的重要业务逻辑

四、编程提示
  提供编程的建议，供程序员参考

五、未定事项等
  说明未定的事项等

六、应用场景
  简略说明一下应用场景

七、客户收益
  说明使用者通过此功能是要完成什么业务目标