为什么程序后台架构要分三层

其实也要看项目，小项目当然没必要搞三层啦。大项目三层，或者更多层都有必要
Service 主要用来控制业务逻辑。分层其实是为了重用。就像你的Dao层里面有一个方法，可以在Service中多处调用一样。

觉得action和dao两层就够了
是因为你的业务逻辑很简单。就是简单的CRUD当你系统业务逻辑很复杂时，你不能都将业务逻辑放到dao吧。很难维护。

不要把业务逻辑都写在action里那样action会变得很臃肿，struts负责的应该只是Controller吧

肯定要用事务的吧你事务写在action里面？
写在dao里面都不合适

就是说的MVC框架呗。
MVC 包含三个基础部分：Model、View 和 Controller，这三个部分以最小的耦合协同工作，以增加程序的可扩展性和可维护性。各个部分的实现技术可以总结如下： 1）Model：JavaBean、EJB 的 EntityBean 2）View：JSP、Struts 的 TagLib 3）Controller：Struts 的 ActionServlet、Action 概括起来 MVC 的优点主要有一下方面： 1）多个视图可以对应一个模型。按 MVC 设计模式，一个模型对应多个视图，可以减少代码的复制及代码的维护量，一旦模型发生改变，也易于维护 2）模型返回的数据与显示逻辑分离。模型数据可以应用任何的显示技术，例如，使用 JSP 页面、Velocity 模板或者直接产生 Excel 文档等 3）应用被分隔为三层，降低了各层之间的耦合，提供了应用的可扩展性 4）控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起，完成不同的请求。因此，控制层可以说是包含了用户请求权限的概念 5）MVC 更符合软件工程化管理的精神。不同的层各司其职，每一层的组件具有相同的特征，有利于通过工程化和工具化产生管理程序代码

dao里面只写增删改查 service里面写业务逻辑对应每一个action写一个service 偏于维护

这是为了分开管理，各司其责。有service是为了层次更清晰，不让action看起来太臃肿,action只控制页面传值及跳转就行了.

service 调用多个dao ，action调用一个service就可以，如果没有service，那你每个action方法都可能调用多个dao，那你就写吧

举个例子你dao可以有个功能召唤一个怪物出来
你action有个功能输出这个怪物
但是你的这个怪物从召唤到输出可能经行了很多不同的处理比如，给怪物安个大炮
给怪物装个翅膀之类的你要输出不同的怪物，就要写很多action
如果你把怪物的处理放在service里面
你的输出怪物的action就可以重用
你的处理怪物的Service也可以重用两全其美但是你的怪物本身就很简单不用做什么处理
那就没必要了

说是为了符合MVC的思想，方便以后维护。。

service是很重要的一层，你的业务处理都在这里边体现，而dao和action的重用性都比较高，干的事情也比较单一。

我的理解呢，java分层就是为了便于分块开发
每层有每层的用处，举个例子，你现在是bs架构，你用action+dao层，没问题，可以实现
等过两天，老板说了，我们要用android项目了，你说你是不还得改action层？然后调用dao？
如果三层或者更多层就没有这么麻烦了。你要用android项目，但是我的数据都是由service生成的，可以使用啊，不用的仅仅是action层的一些代码，组织数据什么的，由service和dao层解决就好了嘛

哥们你说的又点偏题了 MVC一般都是表示层的东东。

分层一般都是按对象的功能或职责来划分的。目的是使结构更清晰，系统更容易维护。套用策略模式来解释action用来组织表示层需要展示的数据。把数据读写的规则剥离出来放到service层的对象中。毕竟很多系统的功能不仅仅是简单的读写数据，在读写的过程中还要进行很多的业务计算。

嘻嘻，看下mvc是怎么说的，就明白了·

service层，主要是事务处理\及业务逻辑，如果把事物写到dao层，如果中间需要调用多个dao的，然后一个事物，有问题回滚，怎么做？，肯定是在service层调用多个dao，然后事物·哈哈，自己貌似都没看懂我说的什么，，，看个大概吧，每个人理解的也许不一样·打个比方:
创建一个用户，并且同时创建一个账户dao现在一般的做法是用户是一个dao,账户是一个dao
如果用户创建失败，那么就不需要创建账户所以service层就是调用这两个dao，然后事物放到service层、
任何一个失败都回滚·

要四層或五層才夠用
Action一個功能
Service一個業務邏輯，每一個小功能的實現在DS層
DS中間層，對service數據的邏輯驗證，實現service中的功能塊
DAO用最簡單的方式操作數據庫

晕你别说那么复杂嘛，人家是新手，不会明白那么多，只有在项目中磨练过后才明白你说的4.5层得好处，
什么充血模式、贫血模式、什么DDD类似的东东，你现在告诉他，也是白说·呵呵·
给他讲明白3层架构就OK

public class LoginAction extends DefaultActionSupport {
public Stirng login() {
AccountBO bo = loginService.login(user, pass);
if (bo != null) {
return SUCCESS;
}
return INPUT;
}
}@Transactional(rollbackFor = java.lang.Exception.class)
public class LoginServiceImpl implements LoginService{
public AccountBO login(String user,String password){
//存在帳號
if(accountDS.existsUser(user)){
//
}else{
//帳號不存在
}
AccountVO vo=null;
//帳號，密碼都正確
switch(accountDS.getStatus(user,password)){
case 0:
//帳號已被鎖定
//TODO返回信息
break;
case 1:
//登錄錯誤次數過多
//TODO返回信息
break;
case 2:
//密碼錯誤
//錯誤次數+1
accountDS.errorNumber(user,password);
break;
case 3:
//已登錄
//TODO返回信息
break;
case 4:
//密碼正確
//更新帳號在線狀態
vo = accountDS.setOnline(user,password);
break;
}
AccountBO bo = AccountHelper.voToBo(vo);
return bo;
}
}

一切设计的根本目标：管理复杂度。我们必须承认人的智力是有限的，无法理解太复杂的东西。然后降低复杂性的最直接做法就是分离关注点，从而使人有限的智商在特点的时间只关注一个方面，反映在程序设计上就是分模块，分层设计思想。至于你说的分三层，这只是在分离关注点的大要求上前提下，一个最自然的分割罢了。但是如果在分离三层之后，依然觉得程序难于理解，则需要继续进行分层，知道程序易于理解为止。MVC就是在表现层的继续分层，也是为了控制表现层的复杂度。软件工程最核心的问题就是管理复杂度，一切失败的项目根本的原因都在于没有控制好复杂度。一个极度简单的程序无论你怎么写都不会失败，因为你总是能够理解他，能够理解的东西就不容易出问题。而一切失败的项目都有一个显著的特征：复杂度失控。项目的总体轮廓越来越模糊，以至于最终没有人能够理解它，从而使得新功能的扩充都只能是战战兢兢的打补丁，最终软件趋于崩溃，变成面目可憎的怪兽。总之一个原则：对复杂的程序进行分层，直到程序易于理解为止。

我们公司项目主要4层：action , service, manager, dao
action: struts转发等
service:主要是String事务控制
manager:真正的业务逻辑
dao:数据操作(ibatis)

不好意思 service: String --> Spring

你这样想，把MVC想成一个软件公司，M对应程序员，V对应销售，C对应经历，用户请求来了就相当于有需求了，但不是直接给C或M，因为用户不知道，他只知道找销售，所以就是V， V 也不知道找哪个程序员去做这需求，所以他去找经理，就是M，他去负责分配这个需求给哪个程序员去做就是C找M，程序员完了后把结果返回经理，就是M->C, C返回给V，就是经理把结果给销售，销售去给客户展示结果，这样各司其责，谁也不影响谁，C是核心，他去控制交给谁做任务，把结果返回给谁。
不知道是不是能帮助你。

简单来说，页面只负责请求，封装数据，业务就只负责分析，分析完成后，调用底层直接实现。。MVC嘛，就把简单的事复杂化，但是也是为了降低耦合度、。

action层主要是前后天数据的交互，service是业务逻辑层，dao层主要是数据层。

为什么要使用service
马士兵的例子中有提到一种情况讲的是为什么使用dao 接口
Dao接口的存在是为了方便二次开发,如果换了数据库
只需要换数据库的实现马士兵的例子讲的是从不同的例子中拿取User,
那么为什么要实现service接口因为可以拿到不同修饰后的User
如果我需要拿到一个有帽子的User
那么我首先定义serviceCapImpl来实现service接口
在spring配置文件中加入bean
在service接口中定义一个BEAN_ID='serviceCapImpl'
在Action中定义一个
IService service=(ServiceCapImpl)applicationContext.getBean(IService.BEAN_ID);那么之后需求变了不想要戴帽子的了想要一个带手表的了
那么只需要改动以下地方就能实现:
实现ServiceWatchImpl类
修改service中定义的BEAN_ID
修改action中的强转类型

调试易

为什么程序后台架构要分三层

解决方案 »