java - 我是否使用 MVC 正确实现了 n 层应用程序？

Question

由于对设计模式和架构非常不熟悉，我很难向其他人解释我的最新应用程序是如何设计的。我已经在认为它是纯 n 层、纯 MVC 和表示层中带有 MVC 的 n 层之间切换。目前我认为后者是正确的，但我想要更有经验的开发人员的想法。

怎么运行的:

浏览器向 Tomcat 发送 HTTP 请求。通过 web.xml 将请求映射到一个 servlet(我称之为 Controller )

Controller 实例化一个或多个业务对象并在这些对象上调用方法，即 customerBO.getById(12)在调用一个或多个 DAO 方法之前再次执行业务逻辑/验证，即 customerDAO.getById(12) . BO 将 CustomerVO 列表返回给 Controller

Controller 为 View (JSP) (request.setAttribute("customers", customers);) 准备属性并选择要使用的 .jsp 文件，该文件反过来将迭代列表并将 XHTML 呈现回浏览器。

结构(我的建议/理解)

展示层 :目前使用我认为是 MVC Web 实现:servlet( Controller )、jsp( View )和我自己的 OO XHTML 表单实现(即 CustomerForm)就在这里。应该可以通过切换此表示层来使用 Swing/JavaFX/Flex GUI，而无需更改下面层上的任何内容。

逻辑层 :分为两层，上面是业务对象(BO)。负责业务逻辑，但除了输入验证之外，我还没有发现太多可放在这里的内容，因为应用程序主要由简单的 CRUD 操作组成……在许多情况下，这些方法只是调用 DAO 层上具有相同名称的方法。

带有 CRUD 方法的 DAO 类，它再次与下面的数据层联系。还有一个 convertToVO(ResultSet res) 方法，它们从数据库执行 ORM 并到(列表)值对象。所有方法都将值对象作为输入，即 customerDAO->save(voter) 并在成功时返回更新的投票者，在失败时返回 null。

数据层 :底部数据存储在数据库中或作为 XML 文件。除了一些 MySQL 存储过程和触发器，我在这里没有“编码”任何东西。

问题(除了标题中的问题):

MVC 中的 M。我不确定当模型是从逻辑层中的业务对象返回的列表/VO 时是否可以调用此 n 层 MVC？当 Controller / View 在这里时，模型是否需要驻留在表示层中？表示层中的表单模板可以称为模型吗？如果是这样; BO 中的表单和列表是否都被视为 MVC 中的 M？

据我了解，在 MVC 中， View 应该观察模型并根据更改进行更新，但这在 View 是呈现的 XHTML 页面的 Web 应用程序中是不可能的？这反过来又让我想到了一个问题:Web 应用程序与常规桌面应用程序的 MVC 实现方式是否不同？

当所有 HTTP 请求都显式映射到 web.xml 时，我没有使用前端 Controller 模式，对吗？要使用前端 Controller ，我需要将所有请求转发到标准 servlet/ Controller ，然后再评估请求并调用另一个 Controller ？

业务层在我的应用程序中感觉有点“无用”。您通常在此层/对象中放置什么？是否应该始终有一个业务层？我知道它应该包含“业务逻辑”，但这究竟是什么？我只是执行输入验证并实例化一个或多个 DAO 并在它们上调用适当的方法...

我意识到有 MVC 框架，例如 Struts for Java，但自从这是我的第一个 Java Web 应用程序以来，我试图更深入地了解事物的工作原理。回想起来，我希望你能回答我偶然发现的一些问题。

Answer 1

I'm not sure if I can call this n-tier MVC when the models are lists/VO's returned from business objects in the logic tier

这些都是非常好的模型。我还认为 Struts 中的 ActionForms 是模型。 ActionForms 是 Struts 用来表示/建模 HTML 表单的。

in MVC the view is supposed to observe the model and update on change, but this isn't possible in a web-application

是的，关于您是否可以在 Web 应用程序中使用真正的 MVC，这是一个有争议的问题。

Should one always have a business layer?

这取决于应用程序的类型。一些应用程序是数据库驱动的，本质上是数据库的 UI。在这种情况下，几乎不需要业务逻辑。

Data Tier:

存储过程实际上并不是数据层代码的一部分。您应该创建由业务对象调用的数据访问对象 (DAO)。 DAO 调用存储过程。此外，DAO 接口(interface)不应向业务对象提示数据存储在何处，无论是数据库、文件系统还是来自某些 Web 服务。