在MVC文件夹结构中，通用的类文件应该放在哪里？例如，我有一个类确定要使用正确的DataContext，这样我就不需要在每个控制器中重新发明轮子。它应该放在控制器文件夹中吗，即使它不是控制器？它应该与模型一起，因为它与数据库相关，即使它不是模型？可能是Views\Shared文件夹？或者Content是那种东西的综合文件夹？我确信我可以把它放在任何地方，但我想知道“正确”的位置是哪里。
6个回答
9
它不是一个控制器、内容或视图，因此不要使用这些。它听起来最接近于您的模型，所以您可以将其放在模型下的名为“Helpers”或“Utility”的子文件夹中，或者添加另一个顶级文件夹称为“Services”，并将其放在那里。那是我放置所有应用逻辑、控制器和模型之间的中间人的地方。
- John Sheehan
2
你把所有的应用程序逻辑都放在了表现层项目里？听起来很糟糕... - Jason Bunting
1对于小型项目，我把它们放在那里。如果服务将被重复使用，它们会获得自己的项目。 - John Sheehan
3
如果您查看Rob的MVC商店：单独的类库项目（例如Commerce.MVC.Data），请注意：
- dmajkic
1
这不是关于Rob在做什么，而是更多——它只是一种分离责任的标准方法等等。数据访问不应该存在于应用程序的演示层中，除非我们谈论的是单页面应用程序，在那种情况下这样做就没有太多意义。 - Jason Bunting
0
如果它本身可能有用（考虑围绕它构建的命令行工具），请将其放在Models文件夹中。如果它仅作为控制器的辅助程序使用，请将其放在Controllers文件夹中。
- mouviciel
0
这真的取决于它的功能，如果它访问数据，应该放在数据访问层中，否则可以将其放在控制器文件夹中。
- Al Katawazi
0
dmajkic，
为什么要将它分离到自己的区域？如果它是BLL代码，应该放在控制器文件夹中；如果它是DAL相关项，应该放在模型中。我可以理解，如果一个项目变得非常庞大，你想创建一些子文件夹，这不应该成为问题。但是把代码放在另一个层次中真的有违MVC的初衷，不是吗？
- Al Katawazi
2
1不，MVC是一种视图模式。它与表示层相关。控制器应仅包含表示逻辑。控制器类中不应有业务逻辑。dmajkic建议将该类放在单独的项目中，而不是单独的层中。 - liammclennan
@liammclennan - 没错，我不知道Al在吸什么，但也许他应该戒掉。 - Jason Bunting
0
拥有一个独立的DataAccess程序集，将该类设为internal并称其为DataContextFactory。
- Andrei Rinea
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接