页面与DAO

首先，老帖子了，记得前几个月突然心血来朝发的，都是我个人的一些经验之谈，目前就是为了让我们的程序结构更清晰一些，能更加减少我们的工作量。 没想到还有朋友能够过来关心一下，十分感动。谢谢你们。 后面有些我今天的补充，大家随便看看，有什么好的建议提一提，交流交流。

   看见论坛上有人对页面是否100%对于DAO有比较大的分歧。

    从目前的开发模式来看，更多的是根据需求建立表。之后对表进行操作。撇开领域模型不谈。DAO层的操作在许多项目中的确是对应着页面。页面有什么需求，我就写什么样的DAO。这样其实也并非不是一个开发的方法，但是，问题出现了。许多项目中有许多相同的DAO操作，比如：登陆，注册。当然，它们之间也许有区别。有些系统要求登陆的时候记录一下它的登陆时间和登陆地址。而有些系统则要求登陆时只要记录一下它的登陆IP就可以了。问题出现了，怎么样我们去复用这个DAO呢？当然，我们不会傻到把这些功能都写到DAO中，我们把DAO需要的操作只留在DAO中，比如：FindUserByLoginName(String loginName)。OK，把之后一些需要判断，等等放到另外的分层中。这样一来，这个DAO可以被复用了。此时，这个DAO也和页面对应了。似乎这样开发也不错。别的项目中需要这个DAO。我就COPY一下，就OK了。但是，COPY不代表复用。
     复用（继承与组合）。我们可以把这些DAO封装在一个Package中。当然，你也可以不用这么做。但是，为什么会有人看不习惯页面与DAO完全一样呢？我想还是因为复用这个问题吧。100%的页面对应着DAO，也就说明DAO是根据项目需求写的。没有从别的Package中引入，只是COPY。这样一来，在许多项目中写着许多重复的DAO。
     当然，也有许多复用DAO的。把DAO层直接写为泛型。在把这些泛型DAO封装到一个Package中，之后在另外一个项目中直接引入，当成自己的架包使用。但是，这并没有完全100%的复用。因为你还得去做一些事情，比如：写配置，假如你使用了SPIRNG，MVC，ORM这些框架，你还是逃不了配置。虽然你的代码可以复用。这算不上是100%的复用。但是，代码确实被复用了。你不用COPY，你只要IMPORT，NEW。

     这很矛盾。页面100%对应DAO。页面不对应DAO。太多的争论！
     我想解决这种矛盾一定有更好的方法，完全可以利用我们目前的技术来解决这些矛盾。大家有什么好方法？


以上这些内容是在2个月前（一个月前？忘记了）写的。下面是今天补充的！


-------------------------------------------------------------------------------------------------


后记：目前有些比较好的解决方法，这些应该是大家常用的。

1.把一些通用方法些成独立的类。（之后对其引用或者继承）
2.进行更高成次的封装。（有些直接打包成JAR）
3.进行模型化，类似于充血模型的那种方法。
4.带网友补充！


这些方法都很常用，也很老套，似乎现在没有更好的方法。

1。继承的问题：关系太复杂，但是可以提高速度，复用性强。

2。引用的问题：现在使用IOC，问题不太大，但是如果程序结构不好，问题还是挺多的，而且一个类里到处去引用N个类，结构很混乱，但是有些时候我们不得不这样做。

3。使用AOP：老生常谈，问题就是AOP复杂，项目中使用会带来学习曲线，成本问题。而且维护的人对AOP不一定熟悉，虽然是非侵入式，这种侵入式我认为是非技术上的侵入，但是对人的侵入比较大，不过像事物处理，日志记录等等使用到是能带来良好的代码可读性。选择AOP需要在技术和人员上做出均衡的选择。

4。各种框架的拦截器泛滥问题：这个问题在SPRING与STRUTS2的组合中由为严重。SPRING中有AOP，STRUTS2中有拦截器，导致本身应该属于业务层的逻辑验证跑到了展现层中，导致代码难被复用（强大的封装），测试困难。


再次关于DAO与页面：

在回到DAO与页面，我认为如果Domain只是单纯的GET/SET，但是DAO与页面操作对应应该非常的好，程序结构完全的非OO，用的很爽，开发速度也很快，我就这么干过，一个功能，一个功能的写，类只是个空架子，模块与模块之间没有任何的继承关系，只是引用。小行项目很适合，而且连设计都不需要，本身功能很独立，有的时候连面向接口编程都省了。相比之下，还是要根据项目的大小，实施情况，人员水平来综合考虑。


个位网友的个人经验之谈：

xuzhfa123 写道

    各有各的好处:
    第一种:DAO对应页面,也可以说一个表对应一个DAO
    一般大项目时,DAO对页面,这样有利于分工,各自的开发工作独立开来.但是缺点也少,需求变化,相应的DAO跟着改,其次就是那一堆的配置文件也得做相应的改动.最糟糕的是，后期维护困难，这样项目成本也增加。
    第二种：泛型DAO结合目前流行的注解
    不管是大项目还是小项目都适合，因为共用一个DAO，需求变化时可以做出快速变动（用了注解，至少我hbm文件不用维护了，维护实体类就行啦），其中对DAO没有影响。在可扩展方面也好，可以继承这个DAO进行扩展。后期维护起来当然也减少工作量，降低项目成本。

   相比较一下，第二种除了拥有第一种的优点之外，在其他方面也优于第一种。

评论

6 楼 treblesoftware 2009-06-28  

xuzhfa123 写道

    各有各的好处:
    第一种:DAO对应页面,也可以说一个表对应一个DAO
    一般大项目时,DAO对页面,这样有利于分工,各自的开发工作独立开来.但是缺点也少,需求变化,相应的DAO跟着改,其次就是那一堆的配置文件也得做相应的改动.最糟糕的是，后期维护困难，这样项目成本也增加。
    第二种：泛型DAO结合目前流行的注解
    不管是大项目还是小项目都适合，因为共用一个DAO，需求变化时可以做出快速变动（用了注解，至少我hbm文件不用维护了，维护实体类就行啦），其中对DAO没有影响。在可扩展方面也好，可以继承这个DAO进行扩展。后期维护起来当然也减少工作量，降低项目成本。

   相比较一下，第二种除了拥有第一种的优点之外，在其他方面也优于第一种。

还是要看具体的项目，不过泛型DAO是绝对目前来说不可被替代的。

5 楼 xuzhfa123 2009-06-28  

    各有各的好处:
    第一种:DAO对应页面,也可以说一个表对应一个DAO
    一般大项目时,DAO对页面,这样有利于分工,各自的开发工作独立开来.但是缺点也少,需求变化,相应的DAO跟着改,其次就是那一堆的配置文件也得做相应的改动.最糟糕的是，后期维护困难，这样项目成本也增加。
    第二种：泛型DAO结合目前流行的注解
    不管是大项目还是小项目都适合，因为共用一个DAO，需求变化时可以做出快速变动（用了注解，至少我hbm文件不用维护了，维护实体类就行啦），其中对DAO没有影响。在可扩展方面也好，可以继承这个DAO进行扩展。后期维护起来当然也减少工作量，降低项目成本。

   相比较一下，第二种除了拥有第一种的优点之外，在其他方面也优于第一种。

4 楼 erikchang 2009-06-28  

thor0127 写道

DAO跟页面对应 到了后期维护 会累死人的

为什么用DAO对应页面呢？DAO只是方法级的，最好使用一个sevice层来处理具体的逻辑，DAO使用一个泛型，这样的话省去了很多的代码，也便于修改、扩张

3 楼 thor0127 2009-06-28  

DAO跟页面对应 到了后期维护 会累死人的

2 楼 treblesoftware 2009-06-28  

wq163 写道

现实中100%的复用是很难做到的，尤其是在大公司大项目中，一个系统会分为很多独立的工程，由各个小组进行独立立项开发，一个项目跟另一个项目完全有可能用到相同的逻辑，但你就是没办法复用，只能copy。要把这种相同的逻辑提到单独的包中让其他项目共享理论上能够做到，但这里面会涉及到横向团队之间的协调，普通开发人员就算认识到可以提出共享包也是没有权利去做这件事的。这会涉及到很多项目的重构和调整，是有成本和风险的。所以在开发过程中一般只能copy一些东西，等有权力的人提出该弄一个共享工程的时候再说

其实有些复用还是可以做到的，但是就像你说的，100%很难，除非是构件。但是问题又来了，构件一般是符合某种业务逻辑，但是你一个团队不可能总做那一个行业的东西，而且行业本身也在变化，不是技术上的原因，而是行业，人员，等原因。但是现在有了AOP（非侵入式），也许可以让100%复用这个理想状态能在现实一点。

1 楼 wq163 2009-06-27  

现实中100%的复用是很难做到的，尤其是在大公司大项目中，一个系统会分为很多独立的工程，由各个小组进行独立立项开发，一个项目跟另一个项目完全有可能用到相同的逻辑，但你就是没办法复用，只能copy。要把这种相同的逻辑提到单独的包中让其他项目共享理论上能够做到，但这里面会涉及到横向团队之间的协调，普通开发人员就算认识到可以提出共享包也是没有权利去做这件事的。这会涉及到很多项目的重构和调整，是有成本和风险的。所以在开发过程中一般只能copy一些东西，等有权力的人提出该弄一个共享工程的时候再说