asp.net-mvc - ASP.NET MVC - 可以有副业表示逻辑吗？

Question

在您阅读的有关 ASP.NET MVC 的大多数文档中，整个“关注点分离”都被大力插入。依赖注入(inject)/控制反转、单元测试、将“逻辑”排除在 View 之外等。

但这打算推进多远？如果特定任务需要超出 View /模型/持久性的“三层”方法的额外逻辑，这是不好的做法吗？

例如，我有一个包含四个单独项目的解决方案。

Project.Web (ASP.NET MVC) [ References Data.dll, Models.dll ]
Project.Data (Fluent nHibernate Mapping) [ References Models.dll ]
Project.Models (POCO, Helpers, Factories, etc)
Project.Tests (Unit Testing)

到目前为止，这对我很有帮助。但是我的一些 MVC View 需要一些非常抽象的逻辑，所以我需要参与 Models并安排 View Model持久化在数据库中。

这在我的 Data 中不会发生部分，因为这将处理它的可重用性，并且流程中包含业务逻辑。它不可能完全发生在我的 Models部分，因为这需要它了解 Data部分，它没有。而且我不想把它放在 Web部分，因为我不希望那里有数据访问代码。

问题

我添加一个 Project.Presentation 是否严重违规？引用 Data.dll 的项目和 Models.dll构建我需要的东西？此外，抛开项目问题不谈，这总体上是一种不好的方法，还是你们很多人发现自己有时不得不做的事情？我的一部分感觉如果我不得不求助于这个，那么我只是构建了我的软件错误 - 但同时我非常有信心我做得相当好，它太抽象而无法制作原始的无需中间人安排的 HTML 解释。

Answer 1

根据我的经验，单一职责是编写您希望尽早且经常更改的代码的好方法。和 Jan 一样，我在谁做什么、什么时候做什么之间也有明确的界限。您执行得越多，更换系统的一部分就越容易。我最近使用 EF4.1 删除了 linq2sql，并且由于 SRP，一旦我的测试通过了我的新 EF4 层，其他一切都正常工作。

也就是说，我通常让单元测试决定这些东西在哪里——它是我的 SRP 驱动程序以及提出基本问题“必须 =class/service= 知道 =something else= 才能完成它的工作？”如果答案是否定的，它会转到其他地方——如果是，它是一个依赖项。现在，如果它变得痛苦，这就是它告诉我“这很愚蠢”(see this question for the stupid)的方式，我试图强制某些东西而不是让它适应它必须的方式。

关于你的核心问题:你已经清楚地发现了你的代码中的一个差距——它必须知道两件事(数据和模型)，我同意，它应该是它自己的东西并被移除。我将其称为“DomainService”或者可能只是 DTO，但演示文稿感觉它不仅仅是准备数据。 (我认为 View 会处理演示文稿......也许你是指演示者？)。我也反对你认为你做“错事”的看法——不，你正在学习以不同的方式编写代码并让它不断发展，正是 正如它应该。 :-)