MVC中的模型与第3层接口

Question

编辑：谢谢你的回答。他们很有帮助。我的最后一个问题是，是否可以通过REST执行此操作？

首先，我意识到这些已经在以下两个链接中已经有点回答了，所以请不要将其作为副本关闭。我有理由感到困惑！

MVC vs. 3-tier architecture?

MVC Vs n-tier architecture

根据我的理解，MVC设计适用于＆＃34;演示＆＃34; 3层架构中的层，以允许GUI创建。我明白了。然而，我感到困惑的是GUI中的数据模型应该如何与＆＃34;第2层＆＃34;应用逻辑。这就是我设想的方式：

因此，从我收集的内容来看，每当用户与GUI交互并更新模型时，模型是否有责任通过Web服务器API与架构的其余部分进行交流？

Answer 1

取决于您希望如何构建项目。

例如：有时我们不想公开我们的模型类（实体）。因此，我们创建DTO类以从UI接收信息，这些信息将由控制器处理并将它们传递给将其转换为实体的业务逻辑。它在SOA解决方案中使用了很多，我们可以在其中公开我们的服务。

示例：UI请求 - ＆gt;具有DTO的控制器 - ＆gt; BLL（转换为真实的模型类） - ＆gt;存储库/ DAO - ＆gt; DB。

Answer 2

层的讨论与 MVC 的讨论完全正交。

MVC并没有真正谈论该模型应该如何与外部服务/数据层进行通信。有关它的一些很好的讨论here。关于数据访问/持久性是否应该在您的模型层或控制器层中存在争议。我更喜欢它在我的模型层中。

我也更喜欢Anemic Domain Model，所以我倾向于将实际的谈话放在模型的服务部分中的DAO层，而不是域对象。但是将它放入模型对象中效果也很好，您只想将持久层与业务逻辑层分离为DAO模式。

关键是，你的两个层都需要自己的 Model 和他们自己的DAO层。 Presentation Tier的DAO层将与业务层进行通信。业务层的DAO层将与您的数据库/存储层进行通信。

这将每个层与其他层中的更改隔离开来。

Answer 3

您的控制器包含轻量级应用程序逻辑，用于协调模型和视图之间的工作。例如，控制器有责任从服务/数据源获取数据，并将生成的模型映射到视图模型，是视图。

视图也应包含尽可能少的逻辑。由于视图模型是专门为视图创建的，因此视图的唯一责任是使用视图模型的数据呈现自身。

您所指的模型确实是您从后端获得的结果。它可以是WCF服务返回的代理实体，Web API返回的数据实体或实体框架对象（如果直接访问数据库）（全部取决于您要使用的体系结构）。然后，此模型用于构建视图模型，视图用于渲染自身。