编辑：感谢您的回答。他们是有帮助的。我的最后一个问题是，是否可以通过REST执行此操作？MVC与第3层接口的模型
首先，我意识到这些已经被有点在以下两个链接中回答，所以请不要将其作为副本关闭。我是合法的困惑！
据我所知，MVC设计是在3层架构的“表现”层，允许创建GUI。我明白了。然而，我感到困惑的是GUI中的数据模型应该如何与“第2层”应用程序逻辑交互。这是怎么了预想它：
所以从我收集，每当用户与GUI交互，并更新模型，是模型的责任，然后再跟的休息通过Web服务器API的架构？
您的控制器包含轻量级应用程序逻辑，这是在模型和视图之间协调工作所需的。例如，您的控制器有责任让从业务/数据源的数据，并将得到模式映射成是给你的视图一个视图模型。
视图还应包含尽可能少的逻辑。由于视图模型是专门为视图创建的，视图的唯一责任是使用视图模型的数据进行自身渲染。
您所指的模型确实是您从后端获得的结果。如果您直接访问数据库，它可能是WCF服务返回的代理实体，Web API返回的数据实体或实体框架对象（全部取决于您要使用的架构）。这个模型然后用来构建一个视图模型，你的视图用它来自我渲染。
取决于你想如何构建你的项目。
例如：有时我们不想公开我们的模型类（实体）。所以，我们创建DTO类来接收来自UI的信息，这些信息将由控制器处理，并将它们传递给将它们转换为实体的业务逻辑。它在SOA解决方案中使用了很多，我们可以揭示我们的服务。
示例：UI请求 - >具有DTO的控制器 - > BLL（转换为真实模型类） - > Repository/DAO - > DB。
关于等级的讨论与MVC的讨论确实是正交的。
MVC并没有真正谈论模型应该如何与外部服务/数据层交谈。有关于它的一些很好的讨论here。关于数据访问/持久性是否应该在您的模型层或您的控制器层中存在争议。我更喜欢它在我的模型层。
我也比较喜欢Anemic Domain Model，所以我倾向于将实际谈话放在模型的服务部分的DAO图层中，而不是域对象。但是将其放入模型对象中也很有效，您只需要使用DAO模式将持久层与业务逻辑层分开。
问题是，您的两层都需要自己的型号和他们自己的DAO层。 Presentation Tier的DAO层将与Business Tier进行交流。业务层的DAO层将与您的数据库/存储层进行对话。
这会将每层与其他层中的更改隔离开来。