简化Spring--Model层
2008-02-23 10:13:10来源:互联网 阅读 ()
因为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
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash