|
锁定老帖子 主题：在项目架构中如何进行分层才是最合理的？
精华帖 (2) :: 良好帖 (0) :: 新手帖 (17) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-24
lcllcl987 写道 有点晕.
此问题最终沦落到讨论interface是否有存在的必要了. 严重怀疑javaeye帖子的水准, 居然成了首页推荐. OOP思想的重要核心之一就是面向interface编程. 否则, 你直接面向过程写程序得了. 省却java, qbasic更适合. 接口是很有用，但要看用在哪里，怎么用。 |
| 返回顶楼 | |
|
发表时间：2008-09-24
这种大义凛然的教条腔很没必要
估计Rod Johnson提出 without EJB时，也会被你训个半死 lcllcl987 写道 有点晕.
此问题最终沦落到讨论interface是否有存在的必要了. 严重怀疑javaeye帖子的水准, 居然成了首页推荐. OOP思想的重要核心之一就是面向interface编程. 否则, 你直接面向过程写程序得了. 省却java, qbasic更适合. |
| 返回顶楼 | |
|
发表时间：2008-09-24
我认为面向接口的编程方式还是比较好的，如果不采用接口的话可能会引起不必要的麻烦
|
| 返回顶楼 | |
|
发表时间：2008-09-24
melode11 写道 godoo 写道 我做了多年的软件开发，从我的经历来讲讲我的意见，首先，看看你所说的采用接口的缺点吧
1. 创建的文件数量太多－－你做的项目多大，占用了多少开发工作量？请统计一下自己的工作内容和时间，从我的经验看，这个问题几乎可以忽略 2. 增加了开发人员的工作量－－同问题1，如果采用自动生成接口文件，那工作量就更少到忽略了 3. 增加了后期维护的复杂性－－本质同1 4. 程序调试不方便－－有一定道理，但我的情况来看，也不困难；还有些插件可以帮助找到接口的具体实现 优点说个体会最深的 1. 如果你自己写测试（特别是如果你是TDD爱好者），你会体验到接口的威力 2. 接口的确会使你的应用灵活很多；DAO改变实现很少，不管是换DB，还是换框架或实现，业务层换具体实现也不太多，但你测试时会方便很多（这个所有都适用）； 其他优点还有不少，可以参考如敏捷软件开发之类的书籍 测试我写的不多，不过我想写测试要替换一个伪DAO的话，使用匿名内部类也能实现这个目的。 用接口最不方便的地方不是要多些这些接口文件，是本来如Eclipse这种IDE可以用Ctrl+点源码，从Service中写的DAO类名直接找到DAO类，用了接口，就必须得自己手工打开这些实现类。 要有修改，也必须得两个文件一起改，真是不胜其烦，感觉这种直接提取所有方法组成Interface的做法，是对Interface功用的扭曲。 您为什么不尝试下 ctrl+T呢？ |
| 返回顶楼 | |
|
发表时间：2008-09-24
shevliu 写道 您为什么不尝试下 ctrl+T呢？ 太感谢啦，这样调试起来就快多了！ |
| 返回顶楼 | |
|
发表时间：2008-09-24
以上看得我崩溃了。（Eclipse快捷键推荐每个人都应该用熟，效率很高很多。）
应该说，项目中用Service的接口，多数是为了IOC；而DAO接口是为了冒名顶替进行Unit测试。 我只开发过很少的项目，都不大，而且都是LZ提倡的那种合并模式。数据通用简单的CRUD的写在一个CommonDAO当中。（第一只能查全表，第二完全不考虑事务） 但个人觉得这样子的话，Service层里面会充满一群群的引号括起来的HQL语句，还要处理try，看起来及其恶心，业务逻辑的思路都被各种HQL隔着。当维护的时候太虐待自己眼睛啥是干啥都不知道了。 所以觉得还是有必要用每个PO自己的DAO来处理CRUD，包括特殊查询和批量的CUD。 如此，Service中就是直接用DAO来处理: dao.查询(); dao.取值(); if (取出来的值怎么怎么样了) { dao.批量修改(); } 这样多清楚，然后在这一层里面处理声明性事务。 |
| 返回顶楼 | |
|
发表时间：2008-09-24
mingo 写道 适合的就是最好的。标准做法只能说是参考。
支持！经典！ |
| 返回顶楼 | |
|
发表时间：2008-09-24
觉得这不是什么问题，主要困扰的还是怎么让每个service类权责分明。
不明白为何楼主会说： 创建的文件数量太多。而Dao层需要接口吗？ 我觉得不需要，service层都有接口了，Dao层要接口干吗呢？ 楼主不是用service层来包装dao层吗？ 还有楼主是一个人开发吗？如果不是为什么说service层不需要接口、 |
| 返回顶楼 | |
|
发表时间：2008-09-24
chenjianjx 写道 这种大义凛然的教条腔很没必要
估计Rod Johnson提出 without EJB时，也会被你训个半死 lcllcl987 写道 有点晕.
此问题最终沦落到讨论interface是否有存在的必要了. 严重怀疑javaeye帖子的水准, 居然成了首页推荐. OOP思想的重要核心之一就是面向interface编程. 否则, 你直接面向过程写程序得了. 省却java, qbasic更适合. 这不是教条, 最佳实践不是凭空捏造的. 很难想象没有interface, 你如何做到充分的单元测试. 你的mock对象如何构建? 各个模块如何划分给不同的人去开发? interface最直接的感受, 就是解耦, 和容易单元测试. 当然不能用滥了, 没必要让每个class都"安装"一个interface 不知为什么有人就认为是教条了. |
| 返回顶楼 | |
|
发表时间：2008-09-24
你说容易单元测试我不反对，
但从OO的角度来说， “接口+类” 比“只有一个类”只在一种情况下有好处：就是已经知道了这个接口会有一个以上的实现。但我们这里讨论的是Service和DAO,一般情况下它们在系统中只有一个实现。 可以说 加一个接口，好处不明显、不确切，但坏处就很大了：就是“累死程序员”。从成本效益分析的角度来说，不应该轻易采用“接口+类”的模式。其实有些成熟的产品都是这样弄的，比如Jetty |
| 返回顶楼 | |
