J2EE的MVC架构中的Service层

MVC架构

MVC架构的应用程序到现在还很流行。而M代表Model，V代表View，C代表Controller。Model是数据库或其他数据源取得的数据，独立于View。View是反映Model的UI。Controller是负责控制整个流程，从Model获取数据，处理，然后讲处理后的数据发送到View。

比如，MVC 架构模式是多种设计模式的复合，也可以说是复合设计模式的体现：

  1. Model 和 Controller 之间是策略模式 ，表示对同样的数据可以有不同的处理策略（算法），参考：接口的常用用法都有什么？策略设计模式复习总结
  2. Model 和 View 之间是观察者模式，View 表示观察者， Model 是主题，View 订阅了主题（Model）……参考：发布订阅/回调模型的核心技术——观察者模式复习总结

客户端里；输入用户名，密码 》发送http请求 》触发 Controller 调用 Model 的数据校验接口，Model 校验不符合，触发 Controller 选择登录失败的 View 返回给客户端，用户就看到一个登录失败的提示，之后客户端里输入正确的密码，重复之前的操作，如 model 校验 success，则触发 Controller 去做对应策略的选择，再调用 model 的登录接口来请求登录（策略设计模式），model 和数据存储系统交互，完毕之后触发 controller 更新 view（观察者设计模式）……用户就看到登录成功的提示了。

  • 业务层的架构模式有事务脚本模式、领域模型模式等等，企业应用中最关键的显然是业务层。
  • 事务脚本模式是最简单，最容易掌握的，如果开发团队面向对象设计能力一般，而且业务逻辑相对简单，业务层一般都会采用事务脚本模式，因为简单
  • 如果业务逻辑复杂，用事务脚本模式就很不明智了，简单点讲，就是违背了单一职责设计原则，Service 类成为万能的上帝，承担了太多职责……

事物脚本模式

  • 业务层的架构模式有事务脚本模式、领域模型模式等等，企业应用中最关键的显然是业务层。
  • 事务脚本模式是最简单，最容易掌握的，如果开发团队面向对象设计能力一般，而且业务逻辑相对简单，业务层一般都会采用事务脚本模式，因为简单
  • 如果业务逻辑复杂，用事务脚本模式就很不明智了，简单点讲，就是违背了单一职责设计原则，Service 类成为万能的上帝，承担了太多职责……

事务这里代表表示层的一个请求，所谓脚本就是一个方法，所谓事务脚本就是将一次请求封装为一个方法，所谓事务脚本模式，就是将业务层的对象分为三类，其中：

  1. Service 类封装业务流程，或者说是纯粹的界面上的业务流程
  2. DAO 类只负责对数据的操作，也就是封装对持久层的访问
  3. DTO（Student）类封装业务的实体对象，负责业务层内数据的传输流动

各个对象之间的关系，按照下图的方式组织起来——简单的学生管理业务层UML类图：

  • service类：包含一个 service 接口和对应的 service 接口的实现类，dao 类似，而 dao 和 service 是一种聚合关系，service 类聚合了 dao 类。
  • DTO类：在 dao 和 service 中都有关系，属于依赖关系。即：dao，service 依赖 DTO 类来传输数据对象

原文链接：https://www.cnblogs.com/kubixuesheng/p/10340313.html

MVC的问题

问题的本质是：业务逻辑粘连了C层和M层，应该从C层&M层解耦出来，成为独立的Service层。 在C层直接实现业务逻辑，缺点：

Service层的作用

大体上说，我认为Service + Controller = MVC的C。他们都属于Controller层。

Service负责将业务逻辑从Controller层剥离，放到自己这里。有了Service层，整个MVC架构的流程将是：Controller从Model获取数据----将数据送到Service层进行业务逻辑处理----Service将处理完的数据送回到Controller----Controller将Service返回的数据送入View层展示。

MVVM中ViewModel和MVC中Controller的区别

  • 简单的说，Controller所要担任的任务更加全面，包括了很多的业务逻辑。而ViewModel则简化甚至剔除了业务逻辑，主要的工作就只是把Model中的数据组装成适合View使用的数据。
  • 相对于Vue来说，Angular确实算得上MVC框架。其实吧，对于前端来说，只需要很少甚至不需要业务逻辑，所以MVC这种后端设计结构其实并不适合。所以随着MVP、MVVM这种弱化业务逻辑的结构在前端领域变得越来越流行。
  • 原文链接：https://segmentfault.com/q/1010000008063398/a-1020000008063977

根据以上的引用，我总结，MVC中Business logic在C中。而MVVM中Business logic一般在Model中，ViewModel只负责把Model中的数据组装成View需要的，是一个convert的功能。