方式一

方式二

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

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

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

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

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