编辑：感谢您的回答。他们很有帮助。我的最后一个问题是，是否可以通过 REST 做到这一点？
首先，我知道以下两个链接已经有些回答了这些问题，因此请不要将其关闭为重复。我很困惑！
据我了解，MVC 设计是针对 3 层架构中的“表示”层，以允许创建 GUI。我明白了。但是，我感到困惑的是 GUI 中的数据模型应该如何与“第 2 层”应用程序逻辑进行交互。这就是我的设想：
因此，据我所知，每当用户与 GUI 交互并更新模型时，模型是否有责任通过 Web 服务器 API 与架构的其余部分进行对话？
【问题讨论】：
标签： web-services rest design-patterns model-view-controller architecture
您的控制器包含轻量级应用程序逻辑，需要它来协调模型和视图之间的工作。例如，您的控制器有责任从服务/数据源获取数据，并将生成的模型映射到视图模型授予您的视图。
视图还应包含尽可能少的逻辑。由于视图模型是专门为视图创建的，因此视图的唯一职责是使用视图模型的数据呈现自己。
您所指的模型确实是您从后端返回的结果。如果您直接访问数据库，它可能是 WCF 服务返回的代理实体、Web API 返回的数据实体或实体框架对象（这一切都取决于您要使用的架构）。然后使用此模型构建视图模型，您的视图使用该模型来呈现自身。
【讨论】：
取决于您希望如何构建项目。
例如：有时我们不想公开我们的模型类（实体）。因此，我们创建 DTO 类来接收来自 UI 的信息，这些信息将由控制器处理并将它们传递给将它们转换为实体的业务逻辑。它在 SOA 解决方案中被大量使用，我们可以在其中公开我们的服务。
示例：UI 请求 -> 带有 DTO 的控制器 -> BLL（转换为真实模型类）-> Repository/DAO -> DB。
【讨论】：
tiers 的讨论实际上与 MVC 的讨论是正交的。
MVC 并没有真正讨论模型应该如何与外部服务/数据层对话。对此有一些很好的讨论here。关于数据访问/持久性是否应该在您的模型层或控制器层中存在争议。我更喜欢在我的模型层中使用它。
我也更喜欢Anemic Domain Model，所以我倾向于将与DAO 层的实际对话放在模型的服务部分，而不是域对象中。但是将其放入模型对象也很有效，您只需使用 DAO 模式将持久层与业务逻辑层分开即可。
关键是，您的两个层都需要自己的 Model 和自己的 DAO 层。表示层的 DAO 层将与业务层对话。业务层的 DAO 层将与您的数据库/存储层对话。
这将每个层与其他层的更改隔离开来。
【讨论】：