MVC通用类位置答案

【问题标题】：MVC general class locationMVC通用类位置
【发布时间】：2009-02-03 15:38:46
【问题描述】：

在MVC文件夹结构中，通用类文件应该放在哪里？例如，我有一个类可以确定要使用的正确 DataContext，因此我不会在每个控制器中重新发明轮子。即使它不是控制器，它是否应该存在于 Controllers 文件夹中？是否应该与模型一起使用，因为它与数据库相关，即使它不是模型？可能是 Views\Shared 文件夹？或者 Content 是那种东西的包罗万象的文件夹？我确信我可以把它放在任何地方，但我想知道“正确”的地方在哪里。

【问题讨论】：

标签： c# .net asp.net-mvc solution

【解决方案1】：

它不是控制器、内容或视图，所以不要使用它们。它听起来与您的模型最密切相关，因此您可以将它放在模型中名为“Helpers”或“Utility”之类的子文件夹下。或者，您可以添加另一个名为 Services 的顶级文件夹并将其放在那里。这就是我放置所有应用程序逻辑的地方，即控制器和模型之间的中间人。

【讨论】：

你把你所有的应用程序逻辑都放在了表现层项目中？听起来很可怕....
对于小项目，我把它放在那里。如果这些服务将被重用，它们将获得自己的项目。

【解决方案2】：

如果您查看 Rob 的 MVC Storefront：独立类库项目（如 Commerce.MVC.Data）

【讨论】：

这与 Rob 的工作无关，它不仅如此 - 它只是一种职责分离等的标准方法。除非我们谈论的是单页应用程序，否则数据访问在应用程序的表示层中没有任何意义。

【解决方案3】：

如果它本身有用（想想围绕它构建的命令行工具），请将它放在 Models 文件夹中。如果只是作为控制器的助手，放在Controllers文件夹中。

【讨论】：

【解决方案4】：

这真的取决于它做什么，如果它访问数据它应该在数据访问层，否则你可以把它放在控制器文件夹中。

【讨论】：

【解决方案5】：

有一个单独的 DataAccess 程序集，使该类成为内部类并将其命名为 DataContextFactory。

【讨论】：

【解决方案6】：

dmajkic，

为什么要把它分成自己的区域？如果它的 BLL 代码应该在控制器文件夹中，如果它的 DAL 相关项它应该在模型中。我可以理解如果一个项目变得庞大并且您想要创建一些子文件夹，那应该不是问题。但是将代码放在另一层确实违背了 MVC 的目的，你不觉得吗？

【讨论】：

没有。 MVC 是一种视图模式。它与表示层有关。控制器应该只包含表示逻辑。控制器类中不应该有业务逻辑。 dmajkic 说要将课程放在单独的项目中，而不是单独的层。
@liammclennan - 没错，我不知道 Al 在抽什么烟，但也许他应该戒烟。