解决方案组织

Question

我在asp.net应用程序上工作了6年，但是几乎所有的应用程序都在扩展和维护现有的应用程序。我现在有必要开发一个新的应用程序，我正在抓我的头：

有很多关于软件设计原则和模式的材料，但关于组织的内容却不多。不同的层应该在单独的名称空间、文件夹或项目中吗？

我确实计划在未来创建WCF，所以将服务层作为项目是有意义的，但我不确定我应该有多少项目？默认情况下，MVC 3网站在同一个项目中有模型和控制器，将它们分离到不同的项目是否有意义？

如果有人能发布组织良好的MVC 3解决方案的屏幕截图，我会非常感激。

我知道这可能取决于个人喜好和项目规模，但我需要某种指导。我们的主要应用程序在一个庞大的solution...Please中有超过70个项目帮助我避免这种情况。

非常感谢。

Answer 1

有些人会说，70个项目并非不合理，但我的方法一直是把可能被其他1个以上项目使用的项目区分开来。

在这种情况下没有正确和错误，但是我看到人们将代码分离成没有什么价值的项目，因此，当它有意义时，您可以将代码分离到单独的文件夹(和名称空间)中，不要忘记将代码分离到单独的项目是，什么，10分钟的工作？

我要说的是，对于MVC项目来说，将模型层分离成单独的项目是很好的做法，因为持久性层，IMO，永远不应该被吸收到任何View (UI)项目中。您也可以对Controller层做同样的操作，从一开始有3个项目不会有什么坏处，但是控制器层不太可能被重用，我总是觉得View和Controller在大部分时间都是非常紧密的，因为您的Model层可以被其他网站、窗口或控制台应用程序重用。

我的0.02便士

Answer 2

我倾向于将UI代码放在单独的程序集中。因此，将有一个MVC或Web或Win程序集取决于我的实现。我将把解决方案的共享位放在一个单独的程序集中。如果真的有必要，我只会进一步除以它；否则我只会使用文件夹。

如果最终使用另一种数据存储类型，则可能需要分离数据访问。不过，我只会在有需要时才会这样做。

没有真正的需要分离出模型或控制器。对于插件体系结构，您可以考虑将控制器/模型/视图放在单独的程序集中，但这需要一些思考。

当所有东西都在同一个程序集中时，唯一需要防止的是紧耦合，因为所有东西都是可触及的。