MVC，MVP模式以及涉及多个项目的解决方案

Question

4

我想了解在使用MVC、MVP或其他模式来组织包含多个项目的解决方案时，常见的做法是什么。

例如：对于MVP，我可以在一个解决方案中有一个视图项目、一个Presenter项目和一个模型项目。MVC也可以有类似的解决方案布局，其中可以有多个项目形成一个解决方案。我相信MVVM解决方案也可能包含多个项目。

在使用这些解决方案时，每个项目都会生成一个独立的dll文件。因此，在按照MVP模式组织的解决方案中，Presenter项目将生成自己的.dll文件。

我想知道，在解决方案中使用这种布局方式时，有没有常见的做法，可以避免某人直接引用生成的presenter.dll或controller.dll并调用这些.dll文件中定义的方法或实例化类型的情况。

我想知道：
1）我是否正确地使用了这些模式，或者是否完全错误地组织了包含多个项目的解决方案？

2）我应该把所有的代码都放在一个项目中，并将控制器/Presenter/模型组织在文件夹中，以便为每个解决方案生成一个.exe或.dll文件。我看到这种方法的问题是，在MVP布局中，我将无法使用我的Presenter项目来拥有不同的视图（例如WebSite视图、WebService视图）。

3）在使用MVC/MVP或其他模式组织包含多个项目的解决方案时，常见的做法是什么，以便我可以控制谁调用我的代码。

- Rauland

2个回答

1

这是一个非常好的问题。我曾经使用过ASP.NET MVC框架，并且在Webforms中使用MVP，但MVC框架更胜一筹。以下文章提供了有关这两种模式或1种模式的见解，因为MVP更像是一种变体/衍生物。

如果您的应用程序或业务需求需要将MVC/MVP部分拆分为不同的项目，则可以采用这种方式。您对控制器的重复使用肯定是将其放置在不同项目中的原因。
Visual Studio或者MSBuild提供了合并程序集的功能。这不是什么需要担心的事情，因为它不会影响您的应用程序性能，但可能会给您带来开发或共享问题，这将是比拥有多个程序集更加麻烦的问题。

3./ 一种常见的做法是将模型和控制器分组到一个程序集/项目中，并将视图放在一个单独的项目中。由于视图模型通常与控制器/演示者交织在一起，因此任何希望重用控制器的系统通常都需要视图模型。

一个好的指标来判断您是否正确使用了该模式是识别您是否获得了该模式的好处。

- user181799

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- AD.Net · Accepted Answer

在之前的MVP项目中，我们按照你提到的方式进行了组织，包括视图（在Web项目中）、模型、Presenter、接口等。对于MVC，最好遵循工作室提供的默认结构，至少对于视图和控制器是这样的。