简化Spring--Model层

2008-02-23 10:13:10来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

因为Spring的Example离我们的实际应用都很远,Example里的Model层便不具有代表性,因此就埋下了祸根, Domain-Driven逢初一、十五都会被拿出来讨论一遍。

其实我觉得,无论什么模式,都不过是一种人为的划分,抽象和封装。只要在团队里理解一致,感觉良好就行了。在我的Model层里,只有VO和Manager两位,VO作为纯数据载体,而Manager类放置商业方法,用getHibernateTemplate()直接访问数据库,在一些主要的Manager类里会包含一些小的同类。

1.VO:

考虑到VO如果带商业方法的话,因为它代表的是单个个体,无法承载针对个体集合的方法比如findOrderList()方法,这些方法始终还是要放在Manager类来做,另外基于传到View层的代价,代码自动重新生成的代价,不如把商业方法统一放在Manager类里。

2.Manager:

1.不使用纯DAO。以往的DAO是为了透明不同数据库间的差异,而现在Hibernate已经做的很好了。目前DAO的更大作用,是为了将来可以切换到别的ORM方案比如iBatis,但一个Pragmaic的程序员显然不会无聊到为了这个理由去做一个纯DAO层,直接使用getHibernateTemplate()已经足够。

2.也不使用纯的薄Service层。在JetpetStore里有一个很薄的Service层,Fascade了一堆DAO类,把这些DAO类的所有方法都僵硬的重复了一遍。而我认为Fascade的意义在二:
一是Controller调用Manager甲的时候,总会伴随着调用Manager乙的某些方法。使用Fascade可以避免Controller零散的调用一堆Manager类。
二是一个商业过程里可能需要同时调用甲乙丙丁的方法。

因此,我会在一些主要的Manager类里灵活的使用Fascade,在需要调用其他Manager的方法时就包含它,或者在其他Manager的某些方法总是被伴随调用时,就有选择的代理它的这个方法。

始终都没有在Manager类之上再建单独的一层Service类,我讨厌类膨胀,另外Fascade只是选择性的,Controler如果要同时面对Manager类和Service类有点脚深脚浅,那还不如都在Manager层里完成。

因此,我的模式里,VO作为纯数据载体,Manager类放商业方法。有人说这样太简单了,但一个应用,要划成一个JSP,一个Controller,一个Manager,一个VO,对我来说已经足够复杂,再要往上架墙叠屋,恕不奉陪,起码在我的应用范围里不需要。

上一篇: 简化Spring Controller至所有MVC方案中最简
下一篇: JSF Fundamental

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Java与正则表达式(2年级2)

下一篇:循序渐进学习JUnit