业务分层思想
根据MVC分层思想，我们的项目都会分成3层，而业务层是在M里面的。
现在的项目都会把M分层两层即DAO层(持久层)和Service层(业务层)。
由于业务的发展,Service层里面的业务会越来越复杂,这个时候为了保持Service层方法的抽象层次一致性,一般我们都会写成堆成堆的private方法，举个例子。
public class OrderServiceImpl implements OrderService{
public void createOrder(){
checkActivity();
createOrderInfo();
createTrade();
}
private void createOrderInfo(){
createOrderInfo();
createSkuInfo();
}
private void createOrderInfo(){
//创建订单信息
}
private void createSkuInfo(){
//创建订单对应单个SKU信息
}
private void createTrade(){
//调用支付接口,创建支付信息
}
private void checkActivity(){
//调用活动接口,看该订单对应的商品是否有活动信息
}
}
createOrder()方法中保持了抽象的一致性(增加代码的可阅读性,方便维护),但是里面的私有方法createOrderInfo()里面里面又有一个私有方法。如果这种情况很多的话,那么这个类就会变成一个私有方法很多的类。这个时候我觉得应该在service和dao中再增加一层,该层的抽象层次在service和dao之间。这样子的话,我们就可以把一些业务封装在该层，增加代码的可读性和维护性至于扩展性我目前还没有想到哪个场景可以增加扩展性。
不知道你们对这个是怎么看的。
1.个人认为，MVC里面，control，service，dao都属于控制层。前端界面作于view，数据库充当Model的角色
2.在service里面有很多private方法其实没有太大问题。如果需要可以增加manager这样的层次对某些privae方法进行封装。但是层次分的太多，在实际开发的时候就会觉得很繁琐，一个小功能就需要来几个层次间串。其实也是一种维护和开发成本。
3. 一般事务的界限会划分在service层的public方法，所以写private方法的时候要小心，不然嵌套在一起会出现一些问题。
个人感觉再拆分一层没有必要，写个helper类就差不多了，一个service的代码过长可以多拆分几个service，比如说orderservice可以拆分成ordermakeservice,ordercancelservice。平行拆分和再加一层拆分比较起来，平行拆分更好理解业务。
service里的每个方法只完成一个业务逻辑，如果业务逻辑比较复杂，可以考虑拆分成一个helper或者manager来专门处理这个复杂的逻辑，service就清清爽爽了，而不用一大堆的private方法在service里了。
- 同意 闲读岁月 的观点: MVC里面，control，service，dao都属于控制层。前端界面作于view，数据库充当Model的角色
- 如果service里的private方法都只有在这个service中存在，即其他service不会也有代码相同或类似的private方法，那我感觉写private方法没有什么问题，如果其他service中也有和这个service中private方法相同的代码，可以考虑单独抽出一层。
service建议做成一个facade，仅仅是其他业务操作的组合，控制事务用的。业务逻辑实现可以放到domain或者command里头。