|
锁定老帖子 主题：DAO和Service分层之愚见
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-06
s929498110 写道 yangguo 写道 s929498110 写道 yangguo 写道 你可以连dao层也不要，直接在action上访问数据库。
或者连action都不要，直接在jsp上面写逻辑。 看你开发的什么。 
汗啊。 老兄你这个看起来怎么那么奇怪呢 看起来奇怪的话，只能说明你还没入门。 好吧， 绝世高人。。。 或许“直接在jsp上面写逻辑” 是J2EE的最高境界 俺这个凡夫俗子还真没入门 yangguo说得很对，只要是看你的需求的！ |
| 返回顶楼 | |
|
发表时间：2011-04-06
HelloJimmy 写道 大学里还是好好学习下数据结构、操作系统等基础知识吧。。。。。框架什么的，这些都是浮云，工作中慢慢理解。
我们承认，这些课都十分的有用，但是我们至今无法学到其有用的地方。还得指望自己摸索 |
| 返回顶楼 | |
|
发表时间：2011-04-06
怎么舒服怎么写就行了，各种层都是浮云，浮云。。。。
|
| 返回顶楼 | |
|
发表时间：2011-04-06
分层应该只是维护方便一点吧，当然你也可以不分层。。。。
|
| 返回顶楼 | |
|
发表时间：2011-04-06
业务逻辑不多确实可以，玩玩的项目是可以不分的，否则不光要分service和dao，可能会分更多，业务层已经很复杂了，就不能让人家操心crud了，做平台的要把这些都做了，再提供出抽象的业务，因为业务不光是crud啊。
成然，我上学的时候也是楼主这样的想法，工作一年多后就不这么想了。呵呵 |
| 返回顶楼 | |
|
发表时间：2011-04-06
jackra 写道 DAO层面的目的是试图在表结构发生变化的时候尽量去少改动代码。
这些东西对于一次性的项目或许是没什么意义的。但是如果产品存在扩展和完善的需求，这样做的目的就显现出来。 只所以分层的设计思想在很多时候并没有体现出优势，主要原因就是规划和设计不足导致。 这位也说的很有见地 |
| 返回顶楼 | |
|
发表时间：2011-04-06
xugang8289 写道 建议楼主看一看<<企业应用架构模式>>, 里面讲到了事务脚本, 领域对象模型, 表模块三种逻辑层架构模式, 估计会对分层问题有些新的认识。本人认为目前国内的开发中98%都在使用的三层架构方式实际上是面向对象设计中的一种极其不好的实践，本质上是打着面向对象的旗号做面向过程的勾当。但是由于这种架构方式上手简单，学习成本低廉，非常容易理解，所以为广大公司津津乐道。对于软件架构的分层方式，是一个没有真正正确答案的问题。学习，学习，在学习。。。慢慢就知道了。
这本书我要去读一读。 |
| 返回顶楼 | |
|
发表时间：2011-04-06
dao层不应该要事务，把事务统一放到service中，这样比较好。
举个例子：比如 Userdao和Cardao，在一个service中需要同时修改 user表中car表中数据，这样就需要一个事务来保证user表更新的同时，car表也在更新，所以如果一个servic中用到了一个以上的dao，就应该把事务放到service层中来。 |
| 返回顶楼 | |
|
发表时间：2011-04-06
不错，很简短但我需要。曾经我也纳闷过如此神似为何要这样分层？
咦，楼主给答案了。 |
| 返回顶楼 | |
