ASP.NET MVC 最佳实践答案

【问题标题】：ASP.NET MVC Best PracticesASP.NET MVC 最佳实践
【发布时间】：2009-07-18 02:07:45
【问题描述】：

我来自世界的 WPF 方面，我已经习惯使用 MVVM 模式。我正在尝试学习 MVC，并且在尝试了解我的边界在 MVC 中的位置时遇到了一些困难。这是我的场景：

我有 3 个对象，Parent、Child 和 GrandChild。这些是自定义对象，不使用 MVC 中的内置模型内容。我对验证的东西有很好的处理。我很好地掌握了如何获取和填充我的对象。但是，我正在努力寻找如何处理控制器的最佳实践。我的控制器应该负责什么？例如，我是否应该拥有一个了解如何对父、子和孙子进行 CRUD 的控制器？还是应该分开？如果他们应该分开，我应该怎么做，当我在看父母时，我想看到一个孩子的列表。

【问题讨论】：

标签： c# asp.net asp.net-mvc design-patterns

【解决方案1】：

Controller 仅用于控制请求-响应的流程。因此，在您的示例中，控制器永远不应该知道如何对它们进行 CRUD。 CRUD 逻辑应该包装在模型的 Repository 类中。

看看官方书呆子晚餐的例子，我个人最喜欢这个part。

【讨论】：

我必须为我的表述不够清楚而道歉，但我的真正意思是我的模型正在执行 CRUD，而控制器正在与我的模型交谈。很抱歉造成混乱。
这取决于你的商业模式有多复杂。对于简单的应用程序，控制器可以将存储库类指示为 CRUD。正如你从书呆子晚餐中看到的，即使是对输入逻辑的验证也最好在外部控制器中实现。我认为对于更复杂的业务模型，控制器最好只处理将数据“传递”到业务层类。

【解决方案2】：

Nerd Dinner 应用是一个简洁的示例。我同意将 CRUD 推送到存储库，并且通常仅将控制器用于控制流。

但是，根据我使用 ASP.NET MVC 的经验（对或错），控制器最终会在传递给视图之前对数据进行大量重新排列，反之亦然，当接受对象模型作为来自形成帖子。但同样，它只是在 View 需要和 Model 需要之间进行转换。

【讨论】：

对，控制器充当视图和模型之间的桥梁。确保视图和模型不相互依赖，我喜欢 Nerdinner 的一个有趣的观点是控制器类也不应该依赖于实际的视图。