我想知道在使用MVC，MVP或任何其他模式时我们可以组织包含多个项目的解决方案的常见做法。
例如：对于MVP，我可以在解决方案中拥有一个视图项目，一个演示者项目和一个模型项目。还有一个类似于MVC的解决方案布局，我可以在其中创建几个项目来构建解决方案。我相信这也可能是MVVM解决方案的情况，它可以包含几个项目。
在处理这些解决方案时，每个项目都会生成一个单独的dll。因此，对于以MVP模式组织的解决方案，演示者项目将生成它自己的.dll。
我想知道在一个解决方案中使用这种布局时的常见做法，我们有多个项目，并避免有人可能直接添加引用，例如，生成presenter.dll或controller.dll和调用方法，在这些.dll中定义的instatiate类型。
我想知道：
1）我是正确使用这些模式还是通过组织包含多个项目的解决方案而完全错误？
2）我是否应该在一个项目中拥有所有代码并在文件夹中组织控制器/演示者/模型，以便为每个解决方案生成一个.exe或.dll。我用这种方法看到的问题是，对于MVP布局，我会错过能够使用我的演示者项目获得不同的视图。 （例如WebSite视图，WebService视图）。
3）使用MVC / MVP或任何其他模式时我们可以组织包含多个项目的解决方案，这样我可以控制谁调用我的代码。
答案 0 :(得分：1)
在之前的MVP项目中，我们像您提到的那样组织了视图（在Web项目中），模型，演示者，接口等。对于MVC，您最好遵循工作室给出的默认结构，至少视图和控制器。
答案 1 :(得分：1)
这是一个很好的问题顺便说一句。我使用过ASP.NET MVC框架并将MVP与webforms一起使用，MVC框架名列前茅。以下文章提供了关于模式或1模式的见解，因为MVP更多是变体/衍生物。
http://haacked.com/archive/2008/06/16/everything-you-wanted-to-know-about-mvc-and-mvp-but.aspx
如果您的应用程序或业务需求要求将您的MVC / MVP部件拆分为不同的项目，那么这就是您的选择。您对控制器的重复使用肯定是将其置于不同项目中的原因。
Visual Studio或MSsbuild提供了合并程序集的功能。这不是令人担忧的事情，因为这不会影响您的应用程序的性能，但另一方面可能会让您发展或分享问题，而这些问题将更多地是具有多个程序集的债务。
< / LI> 3. /通常的做法是将模型和控制器分组到一个装配/项目中，并将视图放在一个单独的项目中。由于View Models通常与控制器/演示者交织在一起，因此任何希望重用控制器的系统通常都需要视图模型。是否正确使用模式的一个很好的指标是确定您是否从模式中获益。