有关控制器和模型的MVC初学者需要专家的声音

如何解决有关控制器和模型的MVC初学者需要专家的声音

|| 我对MVC很陌生。我有以下问题，请帮助我澄清这些问题，非常感谢。 Q1。我应该在哪里填充视图模型？例如我的视图模型很大，并且包含很多下拉列表框，多选择列表和其他一些复杂对象。我目前通过将模型传递给构造函数，将它们填充到视图模型自身中，并在构造函数中加载所有对象数据。我还看到我的大学在控制器内部填充了viewmodel。所以现在让我感到困惑，因为很多人建议保持控制器小而纤细。 Q2。我们使用linq2sql作为数据访问层，是否应该在我的viewmodel中使用表实体而不是创建单独的模型类？专家说这很不好，但是如果创建单独的模型类，我基本上会重复它们，并且每次我要保留数据时我都需要将这些值复制到linq 2sql实体，这不是那么有趣，太多了工作。     

解决方法

           很多人建议保持控制器的体积小而纤细。 是。人们的意思是，除了模型<->视图映射之外，控制器不应包含任何逻辑。对于模型，我的意思是MVC中的\“ M \”。   Q2。我们使用linq2sql作为数据访问层，是否应该在我的viewmodel中使用表实体而不是创建单独的模型类？专家说这很不好，但是如果创建单独的模型类，我基本上会重复它们，并且每次我要保留数据时我都需要将这些值复制到linq 2sql实体，这不是那么有趣，太多了工作。 不，你不应该。在这里阅读我的答案：ASP.NET MVC在哪里放置自定义验证属性 使用映射框架进行模型-> viewmodel转换。 更新：   据我了解，您建议将视图模型组装在控制器内部（我的意思是调用业务层或存储库以获取我的数据），并使用控制器调用处理数据的业务逻辑，对吗？ 是。控制器实际上是您的业务层/存储库和视图之间的粘合剂。视图（和视图模型）应该对它们一无所知，而业务层/存储库应该对控制器/视图一无所知。 控制器就是为此目的而创建的。在用户界面层和较低层之间创建一个抽象。因此，控制器中应该存在的唯一代码就是要使其成为可能（并因此遵循“单一责任原则”） 如果您开始将该逻辑添加到视图模型中，则会开始在较低层和用户界面层之间添加耦合。因此，在较低层中进行任何更改也会影响您的所有视图模型（而不仅仅是控制器     ,        您的viewmodel应该是poco，并且最肯定不应该处理模型的映射。如果您不想在控制器中将模型映射到视图模型，建议您使用automapper之类的工具。这很容易。 从模型映射到视图模型后，需要在控制器中设置任何需要设置的额外属性，例如列表。 如我之前所述，绝对不要将您的视图模型绑定到当前的orm或表结构。您永远都不知道可能需要重构什么，并且如果您可以通过自动映射器映射来处理它而不是更改视图和视图模型，那么您已经节省了很多时间。