构建新的大型 ASP.NET MVC2 plus EF4 VS2010 解决方案的最佳实践？答案

【问题标题】：Best practice for structuring a new large ASP.NET MVC2 plus EF4 VS2010 solution?构建新的大型 ASP.NET MVC2 plus EF4 VS2010 解决方案的最佳实践？
【发布时间】：2010-10-07 08:04:44
【问题描述】：

我们正在使用 Microsoft ASP.NET MVC2 和 Entity Framework 4 构建一个新的 Web 应用程序。虽然我确信我的问题没有一个正确答案，但我们正在努力就 VS2010 解决方案结构达成一致。

该应用程序将使用 SQL Server 2008 以及未来可能的 Azure 云版本。我们将 EF4 与 T4 POCO（模型优先）一起使用，并访问许多第三方 Web 服务。我们还将连接到许多外部消息传递系统。 UI 基于带有 jQuery 的标准 ASP.NET (MVC)。将来我们可能会提供 Silverlight/WPF 版本 - 以及移动版本。

简单地说，我们从 VS2010 空白解决方案开始——然后呢？我建议了 4 个文件夹 Data（EF edmx 文件等）、Domain（实体、存储库）、Services（Web 服务访问）、Presentation（Web ui 等）。然而，在 Presentation 下，创建 ASP.NET MVC2 项目显然会创建它自己的 Models 文件夹等，而且它似乎不太适合这个提议的结构。我还缺少一个业务层（或者它是否位于域中？）。

我再次确信没有一种正确的方法可以做到这一点，但我非常感谢您对此的看法。

谢谢

【问题讨论】：

致回答者...有人可以具体说明他们生成 edmx 文件的位置吗？你是放在 asp.net mvc 项目中还是放在单独的类库中？
好的，我在上面找到了一个问题：stackoverflow.com/questions/2795607/…

标签： asp.net-mvc entity-framework visual-studio-2010 asp.net-mvc-2 entity-framework-4

【解决方案1】：

Jfar 是正确的。此时，您的解决方案采用什么结构并不重要。稍后您将有足够的时间重新安排解决方案。我已经完成了许多小型 MVC 应用程序和一个大型 MVC 应用程序，我仍在不断改进我更喜欢如何构建项目/解决方案。

就结构化和 MVC 项目而言，唯一真正重要的文件夹是 Views。我已经开始脱离 /Controllers 和 /ViewModels 文件夹结构，并按域概念对事物进行分组。如果 Student 是您的域概念之一，我将在域项目、MVC Views 文件夹、服务项目等中有一个 Student 文件夹。所有域类、视图模型、控制器等都在同一文件夹名称（在不同的项目中）。这样，如果您想修改学生相关的代码，您总是可以直接知道去哪里。

此外，我们有一个托管视图的 Web 项目和一个包含控制器的单独的类库项目。我的大多数解决方案都有 12-30 个项目。

【讨论】：

“另外，我们有一个托管视图的 Web 项目和一个包含控制器的单独的类库项目。”你觉得这很好吗？控制器使用 system.web、system.web.mvc、路由和类似的命名空间，这些命名空间最有可能在 Web 项目中找到。我只是更喜欢在不引用 system.web 或 system.web.mvc 的情况下拥有类库，我总是努力实现这一点。 “我的大多数解决方案都有 12-30 个项目。”嗯？再说一遍，这真的有必要吗？
不，没有必要将所有内容拆分到单独的项目中，但这对 TDD 来说非常好。在每次测试迭代期间，您将事物混搭得越多，构建所需的时间就越长，这意味着生产力会降低。 30 个项目解决方案包括一个传统的 WebForms 应用程序、新的 MVC 组件、两个后台服务、三个独立的域、两个不同的数据访问策略（NH 和 L2S），以及所有测试和设置项目。这是一个遗留的混乱。如果我们可以从头开始，我们会把它全部分开，但现在最容易将它们保持在一起。
另外，有时我们的项目只有一个类，但它是我们自己的代码和第三方库之间的垫片。我们宁愿写一个包装接口，以便我们以后可以换出库。将垫片放在另一个项目中会迫使我们写入接口。例如，我们的许多项目都需要流市场报价，所以我们写信给 IStreamingQuotesProvider，然后我们有 shims 可以与 DTN、ProphetX 和 BarChart 一起使用，因为不同的部门有不同的订阅，但它们都使用共享域。
跟进：我不再做大规模的解决方案了。我们仍然有 shims，但感谢 nuget，我们将这些版本分开保存，并在内部将我们的 shims 作为 nuget 包发布。此外，现在有了更快的硬件，我不再觉得在做 TDD 时需要把事情分开。

【解决方案2】：

我相信您在这个早期阶段考虑项目结构（和命名空间）是正确的。尽管 jfar 的观点很好，但在首次发布之前，您多久可以奢侈地重组您的项目和命名空间？即使是你建议的东西也比把所有东西都放在同一个项目中要好 - 当然？

【讨论】：

【解决方案3】：

想要添加 - 您如何组织您的文件夹/解决方案并不重要，重要的是您如何组织您的代码。

所以 - 如果您的应用无法使用依赖反转等花哨的技术正确分层，则不会整洁和可测试 - 将臭代码放在一个或一百个文件夹中都没关系。您将无法从 sql 迁移到 Azure，从 mvc 迁移到 silverlight。

【讨论】：

【解决方案4】：

什么对您和您的团队有意义？

代码所在的文件夹没有任何意义（除了次要的命名空间生成），可以通过拖放轻松更改。

现在组织几乎不重要，您的文件太少了，很容易浏览解决方案。 6 个月后，当您拥有 1000 多个文件时，您就需要开始考虑组织了。

对于我自己的个人项目，我将所有内容都转储到一个项目中，在工作中我有 17 个项目解决方案和 50 个文件夹。代码就是代码。

【讨论】：

【解决方案5】：

您可以观看 Rob Conery 的视频，了解如何构建 MVC 项目： http://blog.wekeroad.com/2010/04/19/tekpub-starter

http://tekpub.com/production/starter

HTH

【讨论】：