模型应该只是数据结构吗？服务(数据访问、业务逻辑)位于 MVC 中的什么位置？
假设我有一个显示客户订单列表的 View 。我有一个 Controller 类来处理 View 控件(按钮等)上的点击。
Controller 是否应该启动数据访问代码？想想按钮点击，重新加载订单查询。或者这应该通过模型层吗？
任何示例代码都很棒!
最佳答案
一般我实现MVC如下:
View - 从 Controller 接收数据并生成输出。一般只有显示逻辑应该出现在这里。例如，如果您想利用现有网站并制作它的移动/iPhone 版本，您应该能够通过替换 View (假设您想要相同的功能)来做到这一点。
模型 - 将对数据的访问包装在模型中。在我的应用程序中，所有 SQL 都位于模型层中，不允许在 View 或 Controller 中直接访问数据。正如 Elie 在另一个答案中指出的那样，这里的想法是(至少部分地)将您的 Controller / View 与数据库结构的变化隔离开来。模型也是实现逻辑的好地方，例如每当字段更改时更新“最后修改”日期。如果您的应用程序的主要数据源是外部 Web 服务，请考虑是否将其包装在模型类中。
Controller - 用于将模型和 View 粘合在一起。在这里实现应用程序逻辑、验证表单、将数据从模型传输到 View 等。
例如，在我的应用程序中，当请求页面时， Controller 将从模型中获取所需的任何数据，并将其传递给 View 以生成用户看到的页面。如果该页面是一个表单，则可以提交表单， Controller 处理验证，创建必要的模型并使用它来保存数据。
如果您遵循此方法，模型最终会非常通用且可重用。您的 Controller 具有可管理的大小和复杂性，因为数据访问和显示已分别移至模型和 View ，并且您的 View 应该足够简单，以便设计人员(经过一些培训)可以理解它们。
关于c# - MVC : View and Model Interaction Regarding Data Access, 等，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/329891/