“Model 1” 和 “Model 2”（译）

2019-02-16 本文已影响7人 qinyu

这篇文章是软件架构编年史(译)的一部分，这部编年史由一系列关于软件架构的文章组成。在这一系列文章中，我将写下我对软件架构的学习和思考，以及我是如何运用这些知识的。如果你阅读了这个系列中之前的文章，本篇文章的的内容将更有意义。

JSP 是这样一种技术，它是可以与 PHP、ASP 或是 Python 比肩的脚本语言，用来创建服务端的页面，这些页面由 JVM 解释，可以使用 Java 对象。

最早的 JSP 规范，于 1998 年由 Sun Microsystems 发布，定义了两种组织应用结构的方式，因此，展现逻辑能够以 HTTP 请求/响应范式和业务逻辑甚至用例解耦。

有人认为 “Model 1” 和 “Model 2” 是最早将原本为桌面软件开发上下文而生的 MVC 模式应用到网络 HTTP 请求/响应范式的尝试。

Model 1

第一份 JSP spec. v0.92 提案，只是将 JSP 仅用作展现层的制品，它将包含全部展现层和用例逻辑。


“Model 1” (JSP spec. v0.92)

这种方法对大多数当时的用例来说已经足够好了，因为那时大部分 Web 都是由简单的动态页面组成，而不是用我们现在所了解的复杂 Web 企业应用组成。

第二份关于如何使用 JSP 的提案是为了那时所谓的复杂 Web 应用。但是，请记住，现在的 Web 应用的规模和复杂性要高得多。


“Model 2” (JSP spec. v0.92)

在 “Model 2” 中，一个 HTTP 请求将抵达一个 Servlet；它会解释 HTTP 请求，使用 Java 对象和 EJB（资源库）执行一些逻辑，将结果数据收集起来并将其传给 JSP；而 JSP 将渲染发回给客户端的页面。在 “Model 2” 中，JSP 纯粹作为模板引擎使用。

1999 年 Govind Seshadri 发表了一篇文章，他将 “Model 2” 和 MVC 做了映射：

挺奇怪的，“Model 2” 实际上是我学到的第一个版本的 “MVC”，就在不久之前。

最后，根据手头上的项目的范围和需求，两种方法现在都可以发挥作用。

话虽如此，我认为现在的 Web 企业应用需要更好的方法。
我发现这两种模式共同的毛病是它们都没有遵守单一职责原则。

当谈到 “Model 1” 时，我希望每个人都清楚的看到被混在一起的关注点：我们会把模板逻辑和用例逻辑混在一起。

关于 “Model 2”，我发现 View 和 Controller 都属于展现层，可是Govind Seshadri 却说得很清楚：“Model 2 架构应该导致所有的处理逻辑都集中在控制器 Servlet 之中”，尽管领域逻辑确实是放在外部的 Java 对象和 EJB 之中。

这意味着 “Model 2” 控制器包含了用例逻辑，它应该属于应用层而不是展现层。

例如，如果我们要通过事件触发一个现存的用例，我们需要在事件监听器中复制用例逻辑（已经存在于某个控制器中），而这是一个很大的禁忌，因为这将导致维护性降低并可能导致应用不一致（的问题）。