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

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

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

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

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

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、或未体现在UI上的重要业务逻辑

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

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

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

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