无法理解MVC的控制器部分 [英] Can’t understand controller part of MVC

查看:86
本文介绍了无法理解MVC的控制器部分的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这些控制器到底是什么?我们被要求在学校项目中用Java构建一个ATM,我们的设计的一部分是:

What exactly are those controllers? We were asked to build an ATM in Java for school project, and part of our design is:

  1. 我们拥有存储大多数信息的帐户
  2. 我们有一些用户可以为自己的帐户进行操作并存储一些次要信息. (此外,我们还有atm类来存储用户并进行一些顶级更改)
  3. 我们有userInterface来捕获输入并使用控制器.
  1. We have accounts that stores most of informations
  2. We have users that can make operations for their own accounts and stores some minor informations. (Also we have atm class to store users and make some toplevel changes)
  3. We have userInterface to catch inputs and use controllers.

我对吗,我们的帐户是模型,界面是视图,用户是控制者?

Am I right that our accounts are models, interfaces are views and users are controllers?

非常感谢您解决我的问题!

Thanks a lot to address my problem,!

推荐答案

您说:帐​​户是模型" .其实不,不是.

You say: "accounts are models". Actually no, they are not.

域模型(也称为模型层,或模型)不是单个组件,而是一个由多个组件组成的层.它抽象了一个现实生活的过程和所需的资源.换句话说,它为业务逻辑(由数据,尤其是行为表示)建模.

A domain model (also called model layer, or model) is not a single component, but a layer, composed of multiple components. It abstracts a real-life process and the needed resources. In other words, it models a business logic (represented by data and, especially, behavior).

模型层可以是应用程序的一部分,也可以被多个应用程序共享.

The model layer can be part of an application, or can be shared by multiple applications.

每个模型组件都有一定的作用.它可以是实体(例如,域对象),值对象存储库抽象,外部服务的抽象(例如电子邮件或付费服务)等.抽象是指接口或抽象类.具体的实现不应成为域模型的一部分,而应作为基础结构构造使用不同的外部空间模型.

Each of the model components has a certain role. It can be an entity (e.g. a domain object), a value object, a service, a data mapper abstraction, a repository abstraction, an abstraction of an external service (like an email or paying service), etc. By abstractions, I mean interfaces or abstract classes. The concrete implementations should not be part of the domain model, but of a different, external space vis-à-vis model, serving as infrastructure constructs.

因此,您的UserAccountAtm类只是模型的组成部分.更确切地说,它们是实体.

So, your User, Account and Atm classes are just components of the model. More exactly, they are entities.

另一方面,控制器视图 UI层的组成部分.

On the other hand, the controllers and the views are components of the UI layer.

控制器(应)负责仅将用户请求的执行推迟(例如调度)到模型层.更准确地说,是服务层-定义为域模型的边界层,由其 service 组件表示.因此,某个服务实例将作为依赖项注入到控制器中.控制器将当前的用户输入(数据)传递给它,并调用它的某种方法,其中定义了所需的用户请求处理步骤.服务实例与其他模型层对象一起执行所有这些步骤,以使用用户输入更新模型.考虑到调度任务,控制器方法因此应该比较细小,包含1-3行代码.

The controllers (should) take the responsibility of only deferring (e.g. dispatching) the execution of the user request to the model layer. More precisely, to the service layer - which is defined as a boundary layer of the domain model and is represented by its service components. So, a certain service instance is injected into the controller as dependency. The controller passes it the current user input (data) and calls a certain method of it, in which the required user request processing steps are defined. The service instance, in conjunction with other model layer objects, performs all these steps to update the model with the user input. Having the dispatching task in mind, a controller method should therefore be slim, containing 1-3 lines of code.

视图(应该)从域模型中获取(更新)数据-通过查询自身(例如,从中提取数据)来 并显示它.与控制器类似,视图通过某些服务组件与模型进行通信.

The views (should) obtain (the updated) data from the domain model - by querying it (e.g. by pulling data from it) itself - and display it. Analog to the controllers, the views communicate with the model through certain service component(s).

我用动词应该" 来强调一个事实,即UI层有不同的实现模型.一个实现可以使用如上所述的控制器和视图-原始MVC设计.另一实施方式将不仅使用控制器来更新模型(通过服务),而且还使用控制器来查询模型(通过服务),以便将接收到的数据传递给视图以显示给用户.或者实现甚至根本不使用服务,从而迫使处理用户请求的步骤必须在控制器和/或视图中定义.等等.因此,由您自己决定如何选择实现 UI层.

I used the verb "should" to emphasize the fact, that there are different implementation models of the UI layer. An implementation could use the controllers and the views as described above - the original MVC design. Another implementation would use the controllers not only to update the model (through services), but also to query it (through services), in order to pass the received data to the view for displaying to the user. Or an implementation could even not use services at all, forcing the steps of processing the user request to be defined in the controllers and/or the views. And so on. So, it's up to you, how you choose to implement the UI layer.

请注意,您也可以像模型组件一样命名控制器和/或视图(UserAccountAtm等).但是,然后您必须使用命名空间来区分所有命名空间-推荐的使用方式.在Java中,名称空间由程序包管理.

Note that you can also have controllers and/or views named like the model components (User, Account, Atm, etc). But then you must use namespaces to differentiate between all of them - the recommended way to go. In Java, namespaces are managed by packages.

一些具有更多详细信息的资源(主要是与Web MVC相关,并带有PHP的示例):

Some resources with more details (mainly web MVC related, with examples in PHP):

  • How should a model be structured in MVC
  • PHP - Structuring a Slim3 web application using MVC and understanding the role of the model
  • MVC, controller - use cases
  • GeeCON 2014: Sandro Mancuso - Crafted Design
  • MVC, Delivery Mechanism and Domain Model
  • Catalog of Patterns of Enterprise Application Architecture

这篇关于无法理解MVC的控制器部分的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆