最近在网上看了几个开源的代码，有几个疑问
1。业务层命名叫service好呢，还是叫manager好呢？如UserService和UserManager哪个更清晰化更专业化呢》
2.很多代码里都有泛型的BaseDao，然后Dao类继承此类，Service没有基类，然后Action调用Service，在观察中看到很多Service里的方法都是重复的，如UserService里有 add,del,update，BackService里也有诸如此类的方法，那么为什么不写一个BaseService呢，然后所有Service继承此类，这样可以减少很多代码量的。
叫Service应该是主流做法，
Action、Service、DAO
问题2就不好回答了，如果一个Service里只有一个DAO，即只涉及到一张表，那就可以定义一个基类，但是如果涉及到操作多张表呢？那你Service中的add,del,update到底是针对哪张表或者哪几张表呢？
可以这样子做：
1. 针对每张表提供一个DAO，一个Service（只包括对该表的操作），
2. 然后各个模块提供一个模块Service，通过组合调用针对单表的Service来提供复杂的业务方法。
业务层命名叫当然是叫service好些，
业务业务，service本身就是业务的意思，
而manager只叫管理，要看什么项目里的什么管理模块吧
当然也可以搞个BaseService来通用些，
他们喜欢不搞一个也是有原因嘛，减少耦合BaseService嘛，继承怎么说还是。。
这也和团体的编程风格和规范有关系