随笔 - 53  文章 - 0  评论 - 392 

使用NHibernate的系统体系结构

根据James的意见,我重新调整了基于NHibernate系统的体系结构

大致的建模原则为:
    用例基本上有对应的服务层的类来提供服务。
    根据界面,建立界面、服务类、领域类,以及DAO层之间的分层类图
    根据界面、用例建立动态模型
    有关保存、删除、Load、新建等都由服务层的类,调用DAO来执行,有关查询,由服务层的类调用Native SQL Dao来执行。

有关问题:
1. 在上一个项目中,发现NHibernate会经常更新一些并没有改变的对象,经过分析,发现是null值的问题,这个问题如何解决?
2. 有关面向对象模型中,领域模型的有关业务,如一个定购单,计算定购金额的方法等这些方法的位置问题,现在放在领域层,在J2EE的模型中,应该是放在服务层的。
3. 什么情况下,可以去掉Native Sql DAO,这个DAO,并不使用领域模型,直接使用IDictionary作为一行数据的载体,使用名字来访问,或者使用DataReader作为载体。

综合大家的意见,和我们架构评审、Demo实现的情况,架构已经修改成下面这个样子了:


这样:Business Service作为业务服务层,对应于用例的实现,而NHibernate的DAO由Domain层与之交互,来完成有关操作。
Native SQL 这一部分得以保留,以执行:SQL,存储过程,返回有关数据等等。

0
0
(请您对文章做出评价)
« 上一篇:木匠与总管,一则项目管理的小故事
» 下一篇:常见代码的编写规范(三)---对象的赋值与保存
posted on 2005-06-24 17:43 caidehui 阅读(3177) 评论(14)  编辑 收藏 网摘

  回复  引用  查看    
#1楼 2005-06-24 18:26 | ccBoy      
既然使用了DD,那么NHibernate应该在领域层之下, Native Sql DAO应该和NHibernate位于类似的同层上

这样2,3的疑问就可以解决了。如果定购单是一个Domain对象,那么计算定购金额应该属于Domain对象,而不是服务层。服务层应该放业务动作和流程操作或别的什么;)

其实DD并不拒绝Native Sql DAO,也不是要杜绝了Native Sql DAO,关键在于你编程和设计的方法。以前"设计模式"这个词汇让人感觉混乱,现在我发现"体系架构"这个词更让人迷惑,体系架构覆盖不到系统和业务设计这个层面,所以上面图只能算系统技术设计的一个view :)

  回复  引用    
#2楼 2005-06-24 18:39 | idior
感觉这个图的画法有些不好。 层次性体现的不太好。
不过意思是明白的, 第二个问题领域层并不是不能做啊, 而且就算想把它提到服务层也很容易啊。
为什么要去掉Native Sql DAO, 作为大量的查询操作确实可以使用Native。

j2ee还要考虑分布式对象, 感觉分布式对象在周围的应用好像不是太多。 所以entity显的很heavy(3.0不谈)

不知道企业应用中常用分布式对象吗?

另外在web层, j2ee纵多的模式在.net下用的就少了。 现在.net有什么好的mvc框架吗?

  回复  引用    
#3楼 2005-06-24 21:38 | neuhawk
你们开始用NH开发了?可是还是beta版阿。
Hiberante+spring会造成太多的XML文件,怕麻烦。

  回复  引用    
#4楼 2005-06-24 21:56 | 真没劲
关于NULL值导致UPDATE的问题:
1。数据库不允许NULL
2。修改\NHibernate\Type下的数据类型的Equals方法,修改string的空字符串等于NULL,INT的0等于NULL,因为。NET下数值型不允许NULL,而JAVA可以,所以HIBERNATE估计没这个问题
3。如果在WEB中应用,可以在HTTP MODULE的BEGIN REQUEST中打开SESSION,在END REQUEST中关掉,这个,执行SELECT造成的脏对象就不会被自动保存了。


这3个办法都可以解决这个问题,我也摸索了很久,并分析了NHB的代码才发现的。

  回复  引用    
#5楼 2005-06-24 22:09 | caidehui
这里说一下,左边两个DAO属于DAO这一层,不是说一个属于业务层一个属于领域层。

另外,不将DAO放到领域层之下,是通过仔细思考后作出的选择,这里不做详细说明,等我将例子做好后,再作出说明

  回复  引用    
#6楼 2005-06-26 21:39 | yanghx[未注册用户]
使用这种富Domain Object也是很好的,但是你在“业务服务层”到Web应用层得DTO呢,你用Domain object代替?(VO???)
而且NativeSql Dao如果放在这一层那就更有问题了,业务层怎么变的需要关心数据库操作了?
还有就是DAO层,你用了Domain Object已经包含了DAO层,怎么又把Dao层放到这里?同一“ccBoy”的话,不要
总把“体系结构”结构乱用,很滥的,所以只有经过验证的才可以说“体系结构 ” 。 个人意见:)
我的贫血Domain Object你可看http://www.yjsoft.net/Archive/6.aspx

  回复  引用  查看    
#7楼[楼主] 2005-06-27 07:53 | caidehui      
这个体系结构,已经在一个项目中用了,并且效果很好。需要说明的是DAO这一层不是和业务层对应的东西,可以理解为通过他可以获得你想要的对象、数据等。这个体系结构也不遵循绝对的上下层关系,如果有需要上层可以访问所有的下层,只是在设计的时候需要进行评审,如果评审认为可以,就认可了。

现在我想把DAO作为Domain的下层,服务层还可以访问DAO,而Domain也可以访问DAO来生成有关对象。

我并不支持J2EE中干净的DAO,也不准备搞一个什么DTO来多此一举,我这里要相对清晰简单,需要开发人员一下子就能够理解,并且可以通过设计工具生成原始框架代码。

对于:需求、分析设计、编码、测试的分工对体系结构的影响,不知道有没有有所了解。如果你有专门的需求分析人员、系统分析设计人员、编码人员、测试人员,请说说你们是如何解决这个问题。

如果你一个人身兼数职,那就不必说了,这个角色我已经做了5-6年了,知道应该怎么搞才效率最高。




  回复  引用  查看    
#8楼 2005-06-27 08:33 | neuhawk      
如果你一个人身兼数职,那就不必说了,这个角色我已经做了5-6年了,知道应该怎么搞才效率最高。
/////////////////
呵呵,同感。

  回复  引用  查看    
#9楼 2005-06-27 09:04 | James      
最近Nhibernate的網站上不去了
  回复  引用  查看    
#10楼[楼主] 2005-06-27 09:31 | caidehui      
是啊,我也发现了,可能还在迁移的过程中吧

这就是有偿服务与无偿服务的区别,前者要承担责任,收取费用,后者尽管不收取费用,但承担责任方面就差一些,有时候使用开源的东西真是一种冒险啊。

  回复  引用  查看    
#11楼 2005-06-27 18:59 | 冰火      
基本同意ccboy得看法

你的修改后的模型和我得想法比较接近。

但不知道你对查询和事务的处理是怎样的?
我的做法是:
Web->Service->Domain->IDao<-Dao
Web->Domain<-Dao
Service->Dao

对事务的处理我是放在Service中的。
另外也可以将Find接口从Dao中分离出来。
具体项目可以适当裁减。

  回复  引用  查看    
#12楼 2007-01-13 10:34 | 乌龙      
这个分层还是不错的,但是我不明白为什么web UI可以访问Domain?应该是UI都要经过Service才能访问Domain更好吧?
另外DTO问题是怎么解决的?用dataset/datatalbe性能不好,用标量又老是要改参数,用DTO对象又要自己写对象也是麻烦?
谢谢指教。

  回复  引用  查看    
#13楼 2007-07-30 11:46 | 布鲁斯南      
是不是有了NHibernate,还是需要一个单独的数据访问层DAL???比如说要生成那些复杂的报表等功能,用NHibernate是不是实现不了?


  回复  引用  查看    
#14楼 2007-07-31 14:24 | 镜涛      
学习一下