|
锁定老帖子 主题：在项目架构中如何进行分层才是最合理的？
精华帖 (2) :: 良好帖 (0) :: 新手帖 (17) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-24
chenjianjx 写道 你说容易单元测试我不反对，
但从OO的角度来说， “接口+类” 比“只有一个类”只在一种情况下有好处：就是已经知道了这个接口会有一个以上的实现。但我们这里讨论的是Service和DAO,一般情况下它们在系统中只有一个实现。 可以说 加一个接口，好处不明显、不确切，但坏处就很大了：就是“累死程序员”。从成本效益分析的角度来说，不应该轻易采用“接口+类”的模式。其实有些成熟的产品都是这样弄的，比如Jetty 我们可以设想一个开发场景: 程序员A做应用层, 程序员B做service层, 也就是你说的DAO. 如果service层没有一个对外的interface. A如何在B没有完成任务的情况下进行开发? |
| 返回顶楼 | |
|
发表时间：2008-09-24
一个IService
N个XxServiceImpl |
| 返回顶楼 | |
|
发表时间：2008-09-24
个人感觉也是，因项目而定。
interface的好处不言而喻，但是也不是说所有的项目都必须要用到它。小心画虎不成反成犬，增加复杂度。 |
| 返回顶楼 | |
|
发表时间：2008-09-24
chenjianjx 写道 但从OO的角度来说， “接口+类” 比“只有一个类”只在一种情况下有好处：就是已经知道了这个接口会有一个以上的实现。但我们这里讨论的是Service和DAO,一般情况下它们在系统中只有一个实现。 可以说 加一个接口，好处不明显、不确切，但坏处就很大了：就是“累死程序员”。从成本效益分析的角度来说，不应该轻易采用“接口+类”的模式。其实有些成熟的产品都是这样弄的，比如Jetty 同意！我郁闷的就在这里！ |
| 返回顶楼 | |
|
发表时间：2008-09-24
ltian 写道 就DAO层而言，一个接口最多有一个实现类，大多数接口有零个实现类，你还会感到郁闷吗？ 我现在参与的几个项目中，在Service层和Dao层中，绝大部分都是一个接口类对应到一个实现类的，我增加一个方法就牵连到好几个文件的修改。既然是一对一的关系，为什么要搞得那么复杂呢？我想这些Service接口类和Dao接口类有多个实现类的可能性不会很大，一个项目开发完后就做其他的新项目了。 |
| 返回顶楼 | |
|
发表时间：2008-09-24
lcllcl987 写道 chenjianjx 写道 你说容易单元测试我不反对，
但从OO的角度来说， “接口+类” 比“只有一个类”只在一种情况下有好处：就是已经知道了这个接口会有一个以上的实现。但我们这里讨论的是Service和DAO,一般情况下它们在系统中只有一个实现。 可以说 加一个接口，好处不明显、不确切，但坏处就很大了：就是“累死程序员”。从成本效益分析的角度来说，不应该轻易采用“接口+类”的模式。其实有些成熟的产品都是这样弄的，比如Jetty 我们可以设想一个开发场景: 程序员A做应用层, 程序员B做service层, 也就是你说的DAO. 如果service层没有一个对外的interface. A如何在B没有完成任务的情况下进行开发? 首先，按你的说法，你们开发团队必须得有能力在开发前就定义好所有接口。 假设你们没有这个能力，那么所谓“没有完成DAO时开发上层”，只不过是从自下而上的开发方式改成了自上而下的开发方式。而自上而下对于自下而上来说没有任何优势，反而会在开发下层时遇到难以预料的问题。 退一步讲，你们有能力在开发前定义好所有接口。但其实你说的单元测试，你说的开发的分配，都没有体现接口的真正意义。如果你只是想让接口做个"替身"，那么空实现的具体类完全可以代替，甚至更易用。 有位仁兄说“就DAO层而言，一个接口最多有一个实现类，大多数接口有零个实现类，你还会感到郁闷吗？ ”，他本来想说明DAO需要接口，但我觉得这个说法反而证明了DAO与大多数需要面向接口的情形的不同之处。 项目中DAO的实现至少会有一个，而至多也就一个。而JDK中，尤其是J2EE中的不少接口，官方确实是连一个实现类都没提供，这恰恰说明了，实现类数目的不确定性与接口扩展性。因为你看一个接口需不需要，不能看他当前有多少实现，而是要看以后，最多情况下会有多少实现。 因为一个接口发布之后，就会有各种各样的实现纷至沓来，完全没必要自己提供实现类，他们要做的就是做好整个j2ee的架构。 接口在扩展类型功能，提供实现框架，提供代码重用等各方面都是居功至伟。但是就事论事，那种有且只有一个的DAO，没特殊需要的情况（如需要动态代理）下用接口是自找麻烦。是为不可能的事情在编程 |
| 返回顶楼 | |
|
发表时间：2008-09-24
去就去了.
反正在写面条或结构化代码时都是一气想完,再一次写好全部的代码. OO是先把问题拆成小问题 拆的过程就是用接口来记录. 你写的东西改来改去分明是由于结构化设计得出的恶果, 非说OO的方式用着不顺手. 等你的业务非要用几百上千行才能表示时, 你会写出一个什么样的service?与DAO? 每点一下后面有几百个方法等你选. |
| 返回顶楼 | |
|
发表时间：2008-09-24
如果你觉得标准的一些做法不适合你,你就裁剪掉它!直到适合你为止.只有这样你才会知道什么是适合你现在这个项目的,什么是多余的.随着维护量的增加,你就会慢慢体验到更深刻的需求.如果根本没有维护或维护量很少,那就大胆的裁剪吧!
|
| 返回顶楼 | |
|
发表时间：2008-09-25
看你是做“项目”还是“产品”，如果是做项目，service和dao都没有必要用接口,直接用类也可以了，如果是做产品，还是见意你的dao层使用接口,service可以不用。
|
| 返回顶楼 | |
|
发表时间：2008-09-26
melode11 写道 lcllcl987 写道 chenjianjx 写道 你说容易单元测试我不反对，
但从OO的角度来说， “接口+类” 比“只有一个类”只在一种情况下有好处：就是已经知道了这个接口会有一个以上的实现。但我们这里讨论的是Service和DAO,一般情况下它们在系统中只有一个实现。 可以说 加一个接口，好处不明显、不确切，但坏处就很大了：就是“累死程序员”。从成本效益分析的角度来说，不应该轻易采用“接口+类”的模式。其实有些成熟的产品都是这样弄的，比如Jetty 我们可以设想一个开发场景: 程序员A做应用层, 程序员B做service层, 也就是你说的DAO. 如果service层没有一个对外的interface. A如何在B没有完成任务的情况下进行开发? 首先，按你的说法，你们开发团队必须得有能力在开发前就定义好所有接口。 假设你们没有这个能力，那么所谓“没有完成DAO时开发上层”，只不过是从自下而上的开发方式改成了自上而下的开发方式。而自上而下对于自下而上来说没有任何优势，反而会在开发下层时遇到难以预料的问题。 退一步讲，你们有能力在开发前定义好所有接口。但其实你说的单元测试，你说的开发的分配，都没有体现接口的真正意义。如果你只是想让接口做个"替身"，那么空实现的具体类完全可以代替，甚至更易用。 有位仁兄说“就DAO层而言，一个接口最多有一个实现类，大多数接口有零个实现类，你还会感到郁闷吗？ ”，他本来想说明DAO需要接口，但我觉得这个说法反而证明了DAO与大多数需要面向接口的情形的不同之处。 项目中DAO的实现至少会有一个，而至多也就一个。而JDK中，尤其是J2EE中的不少接口，官方确实是连一个实现类都没提供，这恰恰说明了，实现类数目的不确定性与接口扩展性。因为你看一个接口需不需要，不能看他当前有多少实现，而是要看以后，最多情况下会有多少实现。 因为一个接口发布之后，就会有各种各样的实现纷至沓来，完全没必要自己提供实现类，他们要做的就是做好整个j2ee的架构。 接口在扩展类型功能，提供实现框架，提供代码重用等各方面都是居功至伟。但是就事论事，那种有且只有一个的DAO，没特殊需要的情况（如需要动态代理）下用接口是自找麻烦。是为不可能的事情在编程 是否采用接口, 其标准并不是要看有多少个实现如此简单. 我举个简单的例子吧,比如DAO. 单就DAO来说, 众所周知, 针对DAO的测试不是一件容易的事,因为mock一个数据库确实需要不少功夫(内存数据库), 并且得不偿失. 如果DAO没有一个对外的接口,势必其他模块和DAO紧耦合,随之而来的是其他模块很难单元测试. 如果DAO有一个对外的接口, 其他模块对该接口提供set和get方法, 便可实现解耦合(简单的strategy模式应用), 进而其他模块的单元测试就引刃而解: 对DAO interface做一个庸俗实现. 这仅仅是从单元测试的角度阐述一下dao 需要一个interface. 如果你从来不做单元测试那就另当别论了. 顺便说一下, interface就是一个甲方乙方的契约.在OO的世界, interface是基石.很难想象, 如果没有interface, 模式运动如何进行. 楼上的抛出异常的爱, 可谓说到了点子上. |
| 返回顶楼 | |
