关于应用层次设计的讨论

请大家讨论一下：
以下两种分层结构，各有什么优缺点？
各适用于什么样的场景中？

结构1：




结构2：

 

我都是用结构2。  。  想不出什么优缺点。  貌似这个问题挺有意思。 关注。

结构2中，抽象业务逻辑类依赖于IDAO的实现，所有的业务逻辑类都继承了抽象业务逻辑类。
我个人认为：
该结构的优点是简化开发过程，不用针对每一个业务逻辑创建独立的DAO实现，仅此而已。
它的缺点是：
1、SQL语句或HQL语句，将出现在具体的业务逻辑类中。造成了业务逻辑类的臃肿。
2、不利于复用DAO层逻辑。
3、不灵活。举个例子，BusAManager和BusBManager都通过IDAO实现访问关系数据库，某一天由于业务需要，BusAManager依然访问关系数据库，而BusBManager需要访问文件数据库。这个时候要扩展起来，就很麻烦。

一需要aop或spring支持 写代码里 dao可以点出方法名,
二不必需 代理 可以直接把事务写在basesvc里 ,dao 里的方法只能用引号中"字串"区分 无法反射出方法名容易出见鬼的问题

大家都没有考虑过不用DAO，直接用service。spring和hibernate的合作使得很多service里面直接调用DAO的方法，很是麻烦。

1做点小应用，结构层次鲜明。容易维护修改。
稍微大点的项目用2好些。但是要主要，各自的作用区域，业务不要分担DAO

我们目前使用的第二种方式的涉及，项目一直沿用，确实使用起来很爽，而且封装了service，service封装了dao，这样访问service就能直接访dao了，而且service都抽到了baseservice，使用spring管理

如果是选择的话，我肯定会选择第一种方式！

也许定义的类会多一些，但具有了典型的mvc特征，也就有了他的好处，只是多几个类，而且类名并不难定义！

层次清晰，重写，测试，管理都很清楚

对于第二种方式，实在没有看出有什么好的地方，减少了类的定义，把dao层强制绑定到service层。当然对于很多用hibernate的人而言，也许已经习惯，毕竟hibernate作为orm，本身宣称的就是隔绝数据库的变化影响。习惯于弱化dao层的概念。

一个抽象的service让人看起来很是奇怪！有什么作用？少写点代码？一个抽象的作用如果仅仅被用来少写点代码想来有点得不偿失。

第二种有时候会出现一些只有名字而类里面什么方法都没有的情况（如果为了保证格式统一的话），这样的类更让人迷惑。

我的观点与您的正好相反。
一个大型的项目，在关注它的功能需求外，更要保证它的非功能性需求。
也就是说，性能、吞吐量、可扩展、可维护、可伸缩、安全等一系列的非功能性需求。

对于结构1来说，每个service的Dao都是独立的。在结构上，它可扩展和可维护性会比结构2的强。

因此，大型项目更适合于选择结构1。

结构2，层次划分不清晰，耦合度比较高。一旦涉及到变化，他的抽象模式就要被打破，必然也带来了一系列的不可预估的麻烦。

本人以为：
第一种适用于业务逻辑复杂的中大型项目，这样的项目特定于领域对象的DAO操作更多。这种方式层次清晰，低耦合，代码重用性更高。副作用是某些领域对象的业务逻辑层会非常薄，只是简单的调用DAO。
第二种适用于业务逻辑简单，绝大部分都是简单的CRUD的小型项目，简单的CRUD都可以使用泛型的BaseDAO完成，减少了“不必要”的薄业务逻辑的胶合代码。但这种方式耦合度高，正因为如此更适合几乎是CRUD的小型项目

PS：很久没看到这么接地气的帖子