我是否正确地使用 MVC 实现了 n 层应用程序？
由于对设计模式和架构非常不熟悉，我很难向其他人准确解释我最新的应用程序是如何设计的。 我在认为它是纯 n 层、纯 MVC 和在表示层中使用 MVC 的 n 层之间切换。 目前我认为后者是正确的，但我想听听更有经验的开发人员的想法。
工作原理：
- 浏览器向 Tomcat 发送 HTTP 请求。 通过 web.xml 将请求映射到 servlet（我称之为控制器）。
- 控制器实例化一个或多个业务对象并调用这些对象的方法，即
customerBO.getById(12)，这将再次执行业务逻辑/在调用一个或多个 DAO 方法之前进行验证，即customerDAO.getById(12)。 BO 将 CustomerVO 列表返回给控制器。 - 控制器为视图 (JSP) 准备属性 (
request.setAttribute("customers",customers);) 并选择一个 .jsp 文件以在turn 将迭代列表并将 XHTML 渲染回浏览器。
结构（我的建议/理解）
表示层：目前使用我认为的 MVC Web 实现：servlet（控制器）、jsp（视图）和我自己的 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？ 当控制器/视图位于此处时，模型是否需要驻留在表示层中？ 而表现层的表单模板可以称为模型吗？ 如果是这样; BO 中的表单和列表都可以被视为 MVC 中的 M 吗？
- 根据我的理解，在 MVC 中，视图应该观察模型并根据变化进行更新，但这在视图是渲染的 XHTML 页面的 Web 应用程序中是不可能的吗？ 这又引出了我的问题：Web 应用程序与常规桌面应用程序的 MVC 实现方式是否不同？
- 当所有 HTTP 请求都显式映射到 web.xml 中时，我没有使用前端控制器模式，对吗？ 要使用前端控制器，我需要将所有请求转发到标准 servlet/控制器，该标准 servlet/控制器又评估请求并调用另一个控制器？
- 业务层在我的应用程序中感觉有点“无用”。 你通常在这一层/对象中放置什么？ 是否应该始终拥有业务层？ 我知道它应该包含“业务逻辑”，但这到底是什么？ 我只是执行输入验证并实例化一个或多个 DAO，并在它们上调用适当的方法...
我意识到有 MVC 框架，例如 Struts for Java，但自从这是我的第一个 Java Web 应用程序以来，我试图更深入地了解如何工作。 回顾过去，我希望你能回答我偶然发现的一些问题。
Being pretty unfamiliar with design patterns and architecture, I'm having trouble explaining to others exactly how my latest application is designed. I've switched between thinking it's a pure n-tier, pure MVC and n-tier with MVC in the presentation layer. Currently I think the latter is correct, but I want thoughts from more experienced developers.
How it works:
- Browser sends HTTP request to Tomcat. Maps the request via web.xml to a servlet (which I call controller)
- The controller instantiates one or more business object and calls methods on these, i.e.
customerBO.getById(12)which again will perform business logic/validation before calling one or more DAO methods, i.e.customerDAO.getById(12). The BO returns a list of CustomerVO's to the controller - The controller prepares attributes for the view (JSP) (
request.setAttribute("customers", customers);) and chooses a .jsp file to use which in turn will iterate the list and render XHTML back to the browser.
Structure (my proposal/understanding)
Presentation tier: currently using what I think is a MVC web-implementation: servlets (controllers), jsp (views) and my own implementation of OO XHTML forms (ie. CustomerForm) lies here. It should be possible to use a Swing/JavaFX/Flex GUI by switching out this presentation layer and without the need to change anything on the layers below.
Logic tier: Divided into two layers, with Business Objects (BO) on top. Responsible for business logic, but I haven't found much to put in here besides input validation since the application mostly consists of simple CRUD actions... In many cases the methods just call a method with the same name on the DAO layer.
DAO classes with CRUD methods, which again contacts the data tier below. Also has a convertToVO(ResultSet res) methods which perform ORM from the database and to (lists of) value objects. All methods take value objects as input, i.e. customerDAO->save(voter) and return the updated voter on success and null on failure.
Data tier: At the bottom data is stored in a database or as XML files. I have not "coded" anything here, except some MySQL stored procedures and triggers.
Questions (besides the one in the title):
- The M in MVC. 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? Are the models required to reside within the presentation layer when the controller/view is here? And can the form templates in the presentation layer be called models? If so; are both the forms and lists from BO to be considered as the M in MVC?
- From my understanding, in MVC the view is supposed to observe the model and update on change, but this isn't possible in a web-application where the view is a rendered XHTML page? This in turn leads me to the question: is MVC implemented differently for web-applications vs. regular desktop applications?
- I'm not using a Front Controller pattern when all HTTP requests are explicitly mapped in web.xml right? To use Front Controller I need to forward all requests to a standard servlet/controller that in turn evalutes the request and calls another controller?
- The Business Layer felt a little "useless" in my application. What do you normally put in this layer/objects? Should one always have a business layer? I know it should contain "business logic", but what is this exactly? I just perform input validation and instantiate one or more DAOs and calls the appropriate methods on them...
I realize there is MVC frameworks such as Struts for Java, but since this my first Java web-application I tried to get a deeper understanding of how things work. Looking in retrospect I hope you can answer some of the questions I stumbled upon.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这些都是非常好的模型。 我还认为 Struts 中的 ActionForm 是模型。 ActionForms 是 Struts 用于表示/建模 HTML 表单的内容。
，这是一个关于是否可以在 Web 应用程序中使用真正的 MVC 的争论问题。
这取决于应用程序的类型。 有些应用程序是数据库驱动的，本质上是数据库的 UI。 在这种情况下，只需要很少的业务逻辑。
存储过程实际上并不是数据层代码的一部分。 您应该创建由业务对象调用的数据访问对象 (DAO)。 DAO 调用存储过程。 此外，DAO 接口不应该向业务对象提供有关数据存储位置的任何提示，无论是数据库、文件系统还是来自某些 Web 服务。
Those are perfectly good models. I also consider the ActionForms in Struts to be models. ActionForms are what Struts uses to represent/model HTML forms.
Yep, and that is a matter of debate as to whether you can have true MVC with web-applications.
It depends on the type of application. Some applications are database-driven, and are essentially a UI for the database. In that case, there's very little business logic required.
The stored procedures aren't really part of the data tier code. You should be creating data access objects (DAOs) which are called by the business objects. The DAOs call the stored procedures. Further, the DAO interfaces should give no hint to the business objects as to where the data is stored, whether that be a database or file system or from some web service.
我认为您对术语感到困惑。 MVC 模式（我相信）早于您描述的经典 Web 应用程序架构。 人们曾经将其称为 Web 应用程序架构 MVC 2（模型 2 等），以将其与原始的 MVC 模式区分开来...
请参阅此链接 > http://www.javaranch.com/drive/servlet/#mvc2
HTH
I think you are getting hung up in the terminology. The MVC pattern (I believe) pre-dates the classic web app arch you describe. It use to be that people called web app arch MVC 2 (Model 2 etc.) to differentiate it from the original MVC pattern...
see this link > http://www.javaranch.com/drive/servlet/#mvc2
HTH