java SSH关于service层接口定义 最近自己弄一个项目，使用面向接口开发。项目说小也不小，总之需要维护好几年
java SSH关于service层接口定义
最近自己弄一个项目，使用面向接口开发。项目说小也不小，总之需要维护好几年的。
所以考虑到后面的拓展。
分为：
1、DAO层
2、Service层
3、视图层
1、DAO层有专门的接口定义，叫ICommonDao。具体方法如下：
/**
* <p>保存一个对象.</p>
*@author Belen
*/
void save(T entity);
/**
* <p>删除一个对象 。</p>
*@author Belen
*/
void delete(T entity);
/**
* <p>根据Collection批量删除。</p>
*@author Belen
*/
void removeAll(Collection<T> entities);
/**
* <p>修改一个对象.</p>
*@author Belen
*/
void modify(T entity);
/**
* <p>通过ID查询对象.</p>
*@author Belen
*/
T findById(java.io.Serializable id);
每个表有一个DAO接口，接口继承了ICommonDao。
public interface IOperatorDao extends ICommonDao<Operator>{
Operator findOperatorByUsername(String username);
}
IOperatorDao 的实现类
public class OperatorDaoImpl extends CommonDaoImpl<Operator> implements
IOperatorDao {
public Operator findOperatorByUsername(String username) {
return null;
}
}
2、service层。
也有自己的IBaseService接口，与IBaseDao接口差不多。
1、现在我的问题是，需要一个表定义一个业务service吗？
2、如果一个service同时操作多张表，这个service该如何定义？
3、有相关这方面架构的博文也可提供看一下，万分感谢！
[解决办法]这个没有办法，hibernate本来一次就只能取一个表的数据，但是你的表之间是有关联的，取出一个表等于取了了跟他关联的所有数据，但这样有一些不好的就是加载的东西太多，虽然用的持久化框架可以很快的解决，但是等你应用的时候就会发现，原来这个东西不能这样搞，还是使用jdbc的方式来的直接，直接逻辑关联就是了，用框架自带的辉走向坟墓的，在用数据的时候还是用自定义标签来解决就是，你说面向接口开发，本来就是这样的，你定义了接口，我不计较你是用什么方式实现我的功能，只要性能达标，功能达标就OK，这就是面向接口编程了嘛
[解决办法]service是业务层, 根据业务功能划分的.
你业务共功需要操作几个表,需要几个dao完成业务功能都是不确定的
------解决方案--------------------
1.为了提高我们代码的扩展性和延展性,建议第个表对应一个service,这个一般会前期调研程序设计阶段就做好的规范,但也可不定义,哪个表需要定义再定义,另外,如果后期要扩展的话,把那个service加上就可以了(不建议,因为当程序很大的时候,加一个类有可以影响到其它类的运行)
2.关于一个service操作多张表,也就是一个service操作多个持久化类,可以使用Spring的依赖注入将相应的持久化类的service层注入到这个业务里就可以了.
3.关于架构方面的博文,百度一下,很多的.
[解决办法]我们公司现在的项目就是一个表对应一个service，你的action调用的是对应的service，如果操作多张表，就多注入几个service，不过我们也会在service里面写特殊的方法，这些都不是绝对的
[解决办法]按照面向对象的几个原则设计接口：参考文章http://blog.csdn.net/luxiaoxun/article/details/8041885
[解决办法]不要一个Service操作多张表，后续都不好扩展的，一对一是良策。
[解决办法]这个当然不是，什么叫业务？跟你底层的数据库是没太大关系的，我意思是并非一对一的。譬如你用户表需要自动生成一个ID，然后ID，是根据表A每次累加的，你需要再建一个AService吗？ 肯定不需要啊，因为它只是对应着你用户表的一个属性而已，所以这个并非是一对一，当然也不是绝对的，具体的看自己的业务需求，灵活创建。
[解决办法]DAO层仅仅处理数据库事务，CRUD，Session开闭，以及数据库异常等。
Service管的那是数据逻辑。也就是说，DAO就管拿数据，至于怎么解读数据那是Service的事儿。
建议LZ 用用Spring，里面有三大组件
@Controller
@Service
@Repository
就清晰的给一个应用系统分了层次。
