本文探讨了DAO层与页面对应性的两种不同方法及其优劣。一种是DAO直接对应页面需求，另一种是采用泛型DAO结合注解的方式，提高了代码复用性和维护效率。
[color=blue]首先，老帖子了，记得前几个月突然心血来朝发的，都是我个人的一些经验之谈，目前就是为了让我们的程序结构更清晰一些，能更加减少我们的工作量。 :) 没想到还有朋友能够过来关心一下，十分感动。谢谢你们。 :oops: 后面有些我今天的补充，大家随便看看，有什么好的建议提一提，交流交流。 :D [/color]
看见论坛上有人对页面是否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。太多的争论！
我想解决这种矛盾一定有更好的方法，完全可以利用我们目前的技术来解决这些矛盾。大家有什么好方法？
[color=blue][size=medium]以上这些内容是在2个月前（一个月前？忘记了）写的。下面是今天补充的！[/size]
[/color]
-------------------------------------------------------------------------------------------------
[color=red][size=medium]后记：目前有些比较好的解决方法，这些应该是大家常用的。[/size][/color]
1.把一些通用方法些成独立的类。（之后对其引用或者继承）
2.进行更高成次的封装。（有些直接打包成JAR）
3.进行模型化，类似于充血模型的那种方法。
4.带网友补充！
[color=red][size=medium]这些方法都很常用，也很老套，似乎现在没有更好的方法。[/size][/color]
1。继承的问题：关系太复杂，但是可以提高速度，复用性强。
2。引用的问题：现在使用IOC，问题不太大，但是如果程序结构不好，问题还是挺多的，而且一个类里到处去引用N个类，结构很混乱，但是有些时候我们不得不这样做。
3。使用AOP：老生常谈，问题就是AOP复杂，项目中使用会带来学习曲线，成本问题。而且维护的人对AOP不一定熟悉，虽然是非侵入式，这种侵入式我认为是非技术上的侵入，但是对人的侵入比较大，不过像事物处理，日志记录等等使用到是能带来良好的代码可读性。选择AOP需要在技术和人员上做出均衡的选择。
4。各种框架的拦截器泛滥问题：这个问题在SPRING与STRUTS2的组合中由为严重。SPRING中有AOP，STRUTS2中有拦截器，导致本身应该属于业务层的逻辑验证跑到了展现层中，导致代码难被复用（强大的封装），测试困难。
[color=red][size=medium]再次关于DAO与页面：[/size][/color]
在回到DAO与页面，我认为如果Domain只是单纯的GET/SET，但是DAO与页面操作对应应该非常的好，程序结构完全的非OO，用的很爽，开发速度也很快，我就这么干过，一个功能，一个功能的写，类只是个空架子，模块与模块之间没有任何的继承关系，只是引用。小行项目很适合，而且连设计都不需要，本身功能很独立，有的时候连面向接口编程都省了。相比之下，还是要根据项目的大小，实施情况，人员水平来综合考虑。
[size=large][color=red]个位网友的个人经验之谈：[/color]
[/size]
[quote="xuzhfa123"] 各有各的好处:
第一种:DAO对应页面,也可以说一个表对应一个DAO
一般大项目时,DAO对页面,这样有利于分工,各自的开发工作独立开来.但是缺点也少,需求变化,相应的DAO跟着改,其次就是那一堆的配置文件也得做相应的改动.最糟糕的是，后期维护困难，这样项目成本也增加。
第二种：泛型DAO结合目前流行的注解
不管是大项目还是小项目都适合，因为共用一个DAO，需求变化时可以做出快速变动（用了注解，至少我hbm文件不用维护了，维护实体类就行啦），其中对DAO没有影响。在可扩展方面也好，可以继承这个DAO进行扩展。后期维护起来当然也减少工作量，降低项目成本。
相比较一下，第二种除了拥有第一种的优点之外，在其他方面也优于第一种。[/quote]
看见论坛上有人对页面是否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。太多的争论！
我想解决这种矛盾一定有更好的方法，完全可以利用我们目前的技术来解决这些矛盾。大家有什么好方法？
[color=blue][size=medium]以上这些内容是在2个月前（一个月前？忘记了）写的。下面是今天补充的！[/size]
[/color]
-------------------------------------------------------------------------------------------------
[color=red][size=medium]后记：目前有些比较好的解决方法，这些应该是大家常用的。[/size][/color]
1.把一些通用方法些成独立的类。（之后对其引用或者继承）
2.进行更高成次的封装。（有些直接打包成JAR）
3.进行模型化，类似于充血模型的那种方法。
4.带网友补充！
[color=red][size=medium]这些方法都很常用，也很老套，似乎现在没有更好的方法。[/size][/color]
1。继承的问题：关系太复杂，但是可以提高速度，复用性强。
2。引用的问题：现在使用IOC，问题不太大，但是如果程序结构不好，问题还是挺多的，而且一个类里到处去引用N个类，结构很混乱，但是有些时候我们不得不这样做。
3。使用AOP：老生常谈，问题就是AOP复杂，项目中使用会带来学习曲线，成本问题。而且维护的人对AOP不一定熟悉，虽然是非侵入式，这种侵入式我认为是非技术上的侵入，但是对人的侵入比较大，不过像事物处理，日志记录等等使用到是能带来良好的代码可读性。选择AOP需要在技术和人员上做出均衡的选择。
4。各种框架的拦截器泛滥问题：这个问题在SPRING与STRUTS2的组合中由为严重。SPRING中有AOP，STRUTS2中有拦截器，导致本身应该属于业务层的逻辑验证跑到了展现层中，导致代码难被复用（强大的封装），测试困难。
[color=red][size=medium]再次关于DAO与页面：[/size][/color]
在回到DAO与页面，我认为如果Domain只是单纯的GET/SET，但是DAO与页面操作对应应该非常的好，程序结构完全的非OO，用的很爽，开发速度也很快，我就这么干过，一个功能，一个功能的写，类只是个空架子，模块与模块之间没有任何的继承关系，只是引用。小行项目很适合，而且连设计都不需要，本身功能很独立，有的时候连面向接口编程都省了。相比之下，还是要根据项目的大小，实施情况，人员水平来综合考虑。
[size=large][color=red]个位网友的个人经验之谈：[/color]
[/size]
[quote="xuzhfa123"] 各有各的好处:
第一种:DAO对应页面,也可以说一个表对应一个DAO
一般大项目时,DAO对页面,这样有利于分工,各自的开发工作独立开来.但是缺点也少,需求变化,相应的DAO跟着改,其次就是那一堆的配置文件也得做相应的改动.最糟糕的是，后期维护困难，这样项目成本也增加。
第二种：泛型DAO结合目前流行的注解
不管是大项目还是小项目都适合，因为共用一个DAO，需求变化时可以做出快速变动（用了注解，至少我hbm文件不用维护了，维护实体类就行啦），其中对DAO没有影响。在可扩展方面也好，可以继承这个DAO进行扩展。后期维护起来当然也减少工作量，降低项目成本。
相比较一下，第二种除了拥有第一种的优点之外，在其他方面也优于第一种。[/quote]
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
