问题描述
我是刚开始学java web 开发，我看了很多项目，很不明白为什么分这么多层.例如一个项目采用struct 有:1.实体类：2 Action类：3.DAO类4service类。5jsp.请问为什么这样分啊，把这些都放在一块是个坏主意,可是我不能理解的是：service，我觉得省掉service会更简单些，而且为什么DAO,service，真正起作用的类都要实现一个借口呢？使用它们的时候都是声明接口类，然后再注入它们，为什么不直接使用呢，疑惑中。。。
解决方案
这个问题很好解释，当初我也是不明白，但是后来遇到实际情况就明白了。DAO只负责数据库的操作接口。而service平常的时候只是和dao是类似的方法。那么service的真正含义是什么呢？讲的官方点，service就是做业务逻辑的，就普通点service对dao的数据进行一些处理。我们的jsp属于现实逻辑，把数据传入action，而action再好的结构中应该不会有太多的业务逻辑，而只是把数据直接转入service,而这些数据并不是我们数据库能直接存取的，怎么办，通过逻辑算法进行计算后者转换。这样jsp只负责显示，而action只负责跟view层的数据交换，而dao层只要根据特定表生成特定的增删改查接口。一些比较烦人的复杂的业务逻辑都放在service中了。你没有感觉到service重要，因为你根本就没有什么业务逻辑，你仅仅是把数据库的数据提取出来直接就能通过action传给页面，加入你提取的数据并不是你页面能够直接显示的呢？遇到的时候你可以再回头想这个问题。
解决方案二：
我了个擦，这也太积极了吧。。。
解决方案三：
1 建议仔细读一遍《java与模式》2 请问为什么这样分啊？ 因为他们的职责不同，使命不同3 要实现一个借口呢？依赖倒转原则 dip强调针对接口编程 dao service这些对象的 经过仔细设计后，接口是非常稳定的，有了稳定的接口，当面对变化的时候，就可以 用最少最小的改动适应新的需求 。例如。dao 如果接口稳定，oracle一种是实现 db2 一种实现，mysql一种实现，非常方便
解决方案四：
永远针对接口编程，这样可以调用方和被调用方独立变化、替换等。看看《设计模式》就明了。DAO层在一种情况下可以不用，那就是业务逻辑除了数据库操作，没有太多其他的东西了。Rod Johnson 的 《Professional Java Development with the Spring Framework》：引用We recommend using the DAO pattern to separate business logic from the persistence code. The exception to this rule is when the application's business logic consists of data access operations and not much else. In this case it makes sense to include the data access code in the business operations themselves.
解决方案五：
我一开始也不理解，但是跟着项目组开发一段时间后就慢慢明白了，这个问题会随着你经验的不断积累自然而然解决的，不必担心，上面两位大哥的回答都很专业，很官方，一定要结合实际项目去理解，祝你成功
解决方案六：
MVC是三个单词的缩写,分别为： 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。 View层用于与用户的交互，通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。为什么使用MVC： 大部分 Web 应用程序都是用过程化语言来创建的。它们通常将数据层（例如查询数据操作）代码和表现层代码混在一起。经验比较丰富的开发者会将数据从表现层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。 而 MVC 框架则从根本上强制性的将它们分开。尽管构造 MVC 架构的应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。 首先，MVC 框架最重要的特性之一就是多个视图能共享一个模型，正如之前所提及的，现在需要用越来越多的方式来访问同一个数据源。对此，其中一个解决之道是使用 MVC 的方式来组织代码，无论用户想通过何种渠道或界面来访问数据，只需要用一个模型就能处理它们。由于现在已经将数据和业务规则从表现层分开，所以可以实现最大化的重用代码。另外，由于模型返回的数据没有进行格式化，所以同样的数据能被不同界面使用。例如，很多数据可能用 A 方式来表现，但是它们也有可能会用 B 方式或 C 方式来表现。 模型也有状态管理和数据持久性处理的功能，例如，从服务器端请求的数据和用户的操作数据将在始终保存在程序内，直到该程序的生命周期结束。因为模型与控制器和视图分离，所以很容易改变应用程序的数据层和业务规则。如果我们改变了获取后台数据的方式，只需改变相应的模型即可。一旦我们正确的实现了模型，不管数据来自何方，视图将会正确的显示它们。 由于运用 MVC 的应用程序的三个部件是相互对立，改变其中一个不会影响其它两个，所以依据这种设计思想能构建良好的松偶合的组件，增大复用可能。对我们来说，控制器的也提供了一个额外好处，就是可以使用控制器来连接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器就可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。