以下是粗略看看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.国内开源项目,有不能持续、健康发展的担忧。毕竟国内的开源商业模式不成熟,要工作之余搞开源项目,恐怕支持、升级力度不够,不持久。(不过好在是开源,不行自己改一下扩展一下也可以)
总的感觉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.国内开源项目,有不能持续、健康发展的担忧。毕竟国内的开源商业模式不成熟,要工作之余搞开源项目,恐怕支持、升级力度不够,不持久。(不过好在是开源,不行自己改一下扩展一下也可以)