这些控制器到底是什么？我们被要求用Java为学校项目构建一个ATM，我们的设计的一部分是：
我对吗，我们的帐户是模型，界面是视图，用户是控制者？
非常感谢您解决我的问题！
答案 0 :(得分：3)
您说：“帐户是模型” 。其实不，不是。
domain model（也称为模型层或 model ）不是单个组件，而是由多个组件组成的层。它抽象了一个现实生活的过程和所需的资源。换句话说，它为业务逻辑建模（由数据，尤其是行为表示）。
模型层可以是应用程序的一部分，也可以被多个应用程序共享。
每个模型组件都有一定的作用。它可以是entity（例如域对象），value object，service，data mapper抽象，{{3} }抽象，是外部服务（例如电子邮件或付费服务）的抽象等。抽象是指接口或抽象类。具体的实现不应成为域模型的一部分，而应作为基础结构构造使用不同的外部空间模型。
因此，您的User，Account和Atm类只是模型的组成部分。更确切地说，它们是实体。
另一方面，控制器和视图是 UI层的组成部分。
控制器（应）负责仅将用户请求的执行推迟（例如调度）到模型层。更准确地说，是repository-它被定义为领域模型的边界层，并由其 service 组件表示。因此，某个服务实例将作为依赖项注入到控制器中。控制器将当前的用户输入（数据）传递给它，并调用它的某种方法，其中定义了所需的用户请求处理步骤。服务实例与其他模型层对象一起执行所有这些步骤，以使用用户输入更新模型。考虑到调度任务，控制器方法因此应该比较细小，包含1-3行代码。
视图（应该）从域模型中获取（更新）数据-通过自身查询（例如，从其中提取数据）并显示。与控制器类似，视图通过某些服务组件与模型进行通信。
我用动词“应该” 来强调一个事实，即UI层有不同的实现模型。一个实现可以使用如上所述的控制器和视图-原始MVC设计。另一实施方式将不仅使用控制器（通过服务）来更新模型，而且还通过控制器（通过服务）来查询模型，以便将接收到的数据传递给视图以显示给用户。或者实现甚至根本不使用服务，从而迫使处理用户请求的步骤必须在控制器和/或视图中定义。等等。因此，由您自己决定如何选择实现 UI层。
请注意，您还可以像模型组件一样命名控制器和/或视图（User，Account，Atm等）。但是，然后您必须使用service layer来区分它们-推荐的方法。在Java中，名称空间由程序包管理。
一些具有更多详细信息的资源（主要是与Web MVC相关的示例，以PHP为例）：
答案 1 :(得分：0)
在这种情况下，控制器将通过接口接收用户的请求并调用服务以执行任何操作，调用数据库层以获取数据并填充到模型中，将模型与视图集成以创建所需的视图，并将组合后的视图返回给用户。用户和帐户将有所不同，但相关实体在数据库中具有各自的表示形式。
答案 2 :(得分：0)
您没有完全正确，但是不用担心-当您首先知道它们为什么存在时，弄清楚它们是什么实际上并不复杂。
这里是：
重要的是要理解那些MVC图中的箭头呈圆圈显示数据流。当您绘制显示 dependency 的图表时，视图和控制器取决于模型。该模型不依赖于视图。
现在我们将模型定义为“ 模型不是用户界面”，显然，用户界面由视图和控制器组成。
我们将它们分开，然后将用户置于它们之间：
VIEW ：这是用户界面的一部分，向用户显示 信息。它确定用户将看到，听到的声音等。它从模型中获取信息，并向用户提供信息。
CONTROLLER ：这是用户界面的一部分，用于从用户那里获取信息 并实施他想要执行的操作。
典型示例是视图创建按钮，然后控制器处理点击。视图和控制器之间的分隔以及用户（和时间）之间的分隔是MVC的全部目的。除通过模型外，它们不使用软件进行连接。
MVC的基本假设是：我们可以将视图代码与控制器代码分开，因为它们在不同的时间运行。视图代码在模型更改后运行，然后用户可以对这些更改采取行动，而控制器代码在用户决定采取行动后运行。
重要的是要了解这永远不会完全准确。 MVC过于简化，实际上控制器代码和视图代码之间始终存在不通过模型的连接。但是我们尝试。 MVC框架或应用程序中的大多数设计工作都是试图管理和正确设计它们在其中作弊的方式。