我有一个服务层，将方法暴露给我的MVC'层'。假设我有一个方法：
Public List<StateObjects> GetStates()
然后从我的Model对象的构造函数调用该方法为可能为我的View构建一个SelectList of States？模型是否应该引用我的服务层，并且还允许我的控制器引用我的服务层？或者模型变量的填充是否应该在控制器中完成，那么控制器中的所有逻辑都是如此？
答案 0 :(得分：3)
根据应用程序的大小和范围，它可能不是一个明确的答案，但是当与服务层结合时，我倾向于使MVC的“M”更多地是视图模型。
与MVVM类似，该模型成为一个扁平对象，仅包含将显示给View的属性。控制器访问服务层，然后使用AutoMapper将域对象的属性映射到模型。
您最终得到的是精简控制器和精简模型，大多数逻辑都保留在您的服务层中。模型真正具有任何逻辑的唯一时间是将列表（例如StateObjects列表）映射到SelectLists，或者其他与视图相关的函数/计算。如果您正在进行任何类型的异步JavaScript开发，它还允许您轻松地将Model映射到JSON对象，因为模型相对平坦。
让模型直接引用您的服务层意味着如果您尝试使用某种类型的依赖注入，则必须将所有服务传递给构造函数，这会使模型的实例化变得非常痛苦。
我不知道这是否打破了MVC范式，但它在我过去所做的项目中运作良好。
答案 1 :(得分：2)
答案是：
这取决于您的应用和编码风格。
许多人练习精益模型和脂肪控制器，但是来自重度面向对象的背景，拥有胖模型和精益控制器感觉更自然。以下是我的想法：
模特应该了解自己。这意味着依赖于模型的函数属于模型。
模型应该与其他模型无关。控制器应该处理模型到模型的交互（以及不涉及实例的其他交互）。
通过这种方式，您可以拥有优雅的instance.function()和controller.staticLikeFunction()。
IMO这是最美妙的方式，因为你有一个面向对象的应用程序。
如果您的应用程序不需要面向对象的设计，那么没有意义。在这种情况下，将所有内容都放入控制器中，并将模型保持为纯数据。
答案 2 :(得分：0)
正如您所指出的，有两个真正的选择：
还有第三个选项，即在您的域层中拥有MVC的MC部分。这使得模型填充更容易，但是使用业务层所做的事情会使线条模糊一点（如果您是纯粹主义者）。实际上，在构建巨型企业模型之前，这并不重要。
我特别喜欢静态
public static MyModel FromDomainObject(DomainObject object)
模型上的方法。然后，您可以在控制器中使用它并传入操作中的域对象以获取模型，然后将其传递给视图。
重要的是确保模型中的属性不会按需填充，并且视图无法访问这些方法。实际上，您或团队将调用这些方法/属性并知道其含义，但它有助于保持关注点的分离并减少耦合。
答案 3 :(得分：0)
最好将视图模型用作模型，并保持精益。它应该只有足够的信息来与视图和控制器进行通信，而不是更多。
控制器所需的其他逻辑可以包含在类中，并由控制器实例化。这可以使您的逻辑松散耦合，从而更易于维护。你会帮自己一个忙。