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

Question

我们正在使用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个文件夹数据（EF edmx文件等），域（实体，存储库），服务（Web服务访问），演示文稿（web ui等）。但是在Presentation下，创建ASP.NET MVC2项目显然创建了它自己的Models文件夹等，它在这个提议的结构中似乎不太合适。我也错过了一个业务层（或者这个位于域中？）。

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

由于

Answer 1

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

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

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

Answer 2

我认为在这个早期阶段考虑项目结构（和名称空间）是正确的。虽然jfar的观点很好，但是在第一次发布之前，您经常会重新设计项目和名称空间吗？即使是你所建议的东西也比把所有东西扔进同一个项目更好 - 当然？

Answer 3

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

所以 - 如果您的应用程序无法使用依赖倒置这样的花哨技术进行正确分层，则不会整洁且可测试 - 如果您将臭味代码放在一个或几百个文件夹中也无关紧要。您将无法从sql迁移到Azure，从mvc迁移到silverlight。

Answer 4

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

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

现在组织几乎不重要，你有这么少的文件很容易浏览洗脱。一旦你进入了6个月，当你需要开始考虑组织时，你有1000个文件。

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

Answer 5

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

http://tekpub.com/production/starter

HTH