以下是粗略看看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.国内开源项目，有不能持续、健康发展的担忧。毕竟国内的开源商业模式不成熟，要工作之余搞开源项目，恐怕支持、升级力度不够，不持久。(不过好在是开源，不行自己改一下扩展一下也可以)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。