MVC 3 - 控制器和ViewModels - 哪些应该包含大多数业务逻辑？

Question

目前在我的应用程序中使用工作单元模式和通用存储库,我的所有控制器都包含所有业务逻辑.我正在将所有内容都放在使用ViewModels而不是直接模型上.

虽然这是一个好主意,但现在出现了一个可以在控制器中显着分离我的业务逻辑的问题.对于控制器和ViewModel,它应该包含大部分业务逻辑？

我尝试了几种方法让我的ViewModel实际上包含所有的业务逻辑.但是,我必须在我的ViewModel的构造函数中有一个参数,它需要一个工作单元.这是一个好主意吗？

我的代码气味告诉我它.但是,我有点担心这将与执行不需要ViewModel的操作的控制器保持一致.简单地说,不需要将Model/ViewModel传递给View的操作; 这种情况发生在重定向到其他操作的操作上.这意味着,我的业务逻辑可以保留在该操作中,也可以将该业务逻辑分离为一个函数.

这里的最佳做法是什么？

Answer 1

我不能说我的方法是最佳实践,但我更喜欢将任何业务逻辑放在单独的"服务"层中.

我倾向于使用ViewModel来存储特定视图所需的属性.如果ViewModel上有任何方法,它们可能只是检索与该视图相关的集合.

我通过尽可能地将它们限制为验证和重定向/显示视图来保持控制器的轻量级.

因此,如果我有任何复杂的逻辑,我将控制器操作调用一个单独的服务来处理该逻辑.这样,逻辑被隔离,这使得测试更容易,因为不再需要创建控制器或ViewModel来测试它.重用服务比分离ViewModel更容易.

希望这会有所帮助.祝好运.

Answer 2

对于控制器和ViewModel,它应该包含大部分业务逻辑？

没有那些.

我尝试了几种方法让我的ViewModel实际上包含所有的业务逻辑.但是,我必须在我的ViewModel的构造函数中有一个参数,它需要一个工作单元.这是一个好主意吗？

imho这是一个非常糟糕的主意.首先,你打破了几个SOLID原则.将所有代码捆绑到视图模型中会使测试变得困难.如果您想在另一个视图中使用某些业务逻辑,该怎么办？你复制了那段代码吗？

这里的最佳做法是什么？

让我们先回到MVC模式.这是一个相当广泛的定义,但知道它应该让你感觉到你应该放在哪里.

该结构的问题在于,将层特定信息"泄漏"到模式的其他部分非常容易.因此,Microsoft将ViewModels引入其MVC实现中.

通过这种方式,我们可以从视图中删除所有渲染逻辑并将其放入ViewModel中.而不是在您的视图中执行此操作:

<span>@(model.Age == 0 ? "n/a" : model.Age)</span>

你把那些代码放在ViewModel中,然后简单地调用@model.Age.这样,您就不必在使用视图模型的所有视图中复制该代码.

关于ViewModel的问题的答案是它应该只包含用于正确呈现"模型"信息的逻辑.

至于控制器,我也不会将任何业务逻辑放入其中.首先,它很难测试你的逻辑.然后你为它添加更多的职责(并通过这样做打破SRP).控制器中唯一有效的逻辑是从ViewModel获取信息并将其转换为"模型"可用的内容,反之亦然.

希望这能回答你的问题.

更新

我会创建一个单独的项目并向其添加类.然后只需从webproject添加引用并在控制器中调用这些类.

我也会开始使用控件容器的反转来自动创建为我创建的依赖项.

Autofac可以为您发现您的服务(零配置)并将自身注入MVC.

要遵循分离的界面模式,请创建以下项目:

"规范"项目可用于使测试事物更容易,并且更容易切换实现(可能只是几个类,而不一定是整个业务层).阅读"分离的接口模式"