|
锁定老帖子 主题：在项目架构中如何进行分层才是最合理的？
精华帖 (2) :: 良好帖 (0) :: 新手帖 (17) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-23
我同意楼主的观点。简单就好
|
| 返回顶楼 | |
|
发表时间：2008-09-23
fish2007 写道 DAO层为什么作为可选层呢? 你把对数据库的访问和逻辑的处理都放在service层， 不觉得很乱吗。
对于接口，DAO层的接口，我觉得是可选的，但是service层的接口还是有必要的。在项目中，有很多不期而遇的变化，当你使用了接口，那么你的实现类的变化，就不会对外界产生任何影响。 处理逻辑应该放在service层吧。 访问数据应该放在DAO层，但访问什么样的数据还是应该有service决定吧，DAO应该只是执行而已，并对执行结果进行一定的转换。这样DAO整个系统就只有一个啊，不需要每个service都对应一个DAO。而且这一个DAO对外提供的是一个接口，具体内部是用JDBC还是hibernate，service不需要关心。 |
| 返回顶楼 | |
|
发表时间：2008-09-23
chen-516888 写道 .................
Spring AOP对接口的动态代理类是通过Java Reflection 生成的 如果只是对类生成动态代理类,则使用CGLIB,效率稍微会低一些. 接口和实现分开是为了实现抽象化和实现的分离,使得实现可以动态的改变 你的应用中不需要考虑这样的问题,不代表这样不好 至于能不能"去掉",视具体情况而定吧.完全的话...个人觉得太绝对了 你的DAOImpl如果是基于MySQL和一些特有的东西,有一天你的系统数据库 迁移到Oracle,并且使用了Oracle的一些特性,只需要实现新的DAOImpl代替 原来的DAOImpl就可以了.如果没有接口和实现的分离,就很麻烦了, 可能需要大量修改业务层的代码. 个人拙见 请问，这个DAOImpl在整个系统中是不是只有一个。还是像楼主的图中那样，一个service对应一个dao？谢谢。 |
| 返回顶楼 | |
|
发表时间：2008-09-23
chen-516888 写道 .................
Spring AOP对接口的动态代理类是通过Java Reflection 生成的 如果只是对类生成动态代理类,则使用CGLIB,效率稍微会低一些. 接口和实现分开是为了实现抽象化和实现的分离,使得实现可以动态的改变 你的应用中不需要考虑这样的问题,不代表这样不好 至于能不能"去掉",视具体情况而定吧.完全的话...个人觉得太绝对了 你的DAOImpl如果是基于MySQL和一些特有的东西,有一天你的系统数据库 迁移到Oracle,并且使用了Oracle的一些特性,只需要实现新的DAOImpl代替 原来的DAOImpl就可以了.如果没有接口和实现的分离,就很麻烦了, 可能需要大量修改业务层的代码. 个人拙见 太理想化了，一般来说从mysql迁移到oracle，改动的比这个多的多，基本和数据库打交道的都要重写。 |
| 返回顶楼 | |
|
发表时间：2008-09-23
确实，Action+Service+Dao让人难受，如果有增加功能接口的话，上上下下都得改，针对比较简单的项目，我会把Service+Dao合并，就让Mmodel和Controler用一个类来实现，中间辅以业务接口，也能体现MVC的思想！
如今看看Seam，确实受启发，连Entity都可以充当VO了，那么SessionBean完成Model+Controler的功能也就能接受 |
| 返回顶楼 | |
|
发表时间：2008-09-23
我是觉得，分成Action，Service，Dao的思想的主要原因是DAO主要完成单表的一些增，删，改，主要给Service调用（重用了），Service代表着业务操作，Facade就是在这里起作用，更重要的是，事务必须起停在业务操作中
|
| 返回顶楼 | |
|
发表时间：2008-09-23
有这种标准。。。 可以工厂化吧！~~
|
| 返回顶楼 | |
|
发表时间：2008-09-23
没有什么最合理,,根据领域 业务不同,,划分不同的层.
|
| 返回顶楼 | |
|
发表时间：2008-09-23
我觉得接口还是必要的，而且分层也是必要的，接口易于扩展，
service是和业务有关，dao是和数据处理有关 |
| 返回顶楼 | |
|
发表时间：2008-09-23
chen-516888 写道 .................
Spring AOP对接口的动态代理类是通过Java Reflection 生成的 如果只是对类生成动态代理类,则使用CGLIB,效率稍微会低一些. 接口和实现分开是为了实现抽象化和实现的分离,使得实现可以动态的改变 你的应用中不需要考虑这样的问题,不代表这样不好 至于能不能"去掉",视具体情况而定吧.完全的话...个人觉得太绝对了 你的DAOImpl如果是基于MySQL和一些特有的东西,有一天你的系统数据库 迁移到Oracle,并且使用了Oracle的一些特性,只需要实现新的DAOImpl代替 原来的DAOImpl就可以了.如果没有接口和实现的分离,就很麻烦了, 可能需要大量修改业务层的代码. 个人拙见 有过测试，CGLIB效率其实比java动态代理更高，因为CGLIB是bytecode生成技术，而动态代理是纯反射。 但对于spring来讲这些都不怎么重要，DAO本来就是单例，而且反射浪费的那一点点时间相对别的操作可以忽略，正如你已经跑了5000米了，还在乎多跑一米吗。 |
| 返回顶楼 | |
