新的Web应用程序应该遵循MVC还是MVP模式？

Question

请注意，我不是要求选择哪个（MVC或MVP），而是应该将其中一个用于Web应用程序。

我意识到将旧应用程序从其当前设计转换为MVC或MVP模式可能需要做太多工作。但是，对于一个新的应用程序呢？看来这些是最流行的架构模式，那么应该选择其中一种吗？如果没有，还有其他什么模式？

如果你不熟悉MVC和/或MVP，一个很好的问题是。它有很多很好的答案，包括各个网站的链接，每个网站都打破了每个网站。

Answer 1

MVP / MVC在Web应用程序中运行良好，因为HTTP动词+ URL组合是确定要采取哪种操作的非常好的方法。有理由不使用它，例如你的团队有很多其他框架的经验，但我通常会推荐一个MVP / MVC框架。您的申请将以更高的质量更快地完成。

Answer 2

两者都是不错的选择。

我会选择MVC，因为它有更广泛的采用，更易于理解和使用前端（HTML / CSS）开发人员。

另外，考虑到采用MVC模式的框架数量，在MVC中与你的同事交谈，你会说一个熟悉的语言。

Answer 3

我已针对其他问题发布了以下答案，但可能更合适此处。

MVC 适用于普通服务器端脚本。在MVC中，开发人员总是试图让控制器非常精简。主要控制器只是选择合适的模型并反映在视图上。但是在今天的Web应用程序中，View部分发生了根本性的变化，变得非常复杂，足以产生一个庞大而又凌乱的控制器。所以现在我们需要一个新的位置来放置用户界面的复杂控制逻辑。这里是 MVP 的 P ，即演示者。因此，演示者负责控制特定用户界面组件的逻辑。不要担心控制器仍然在这里，名为应用程序控制器。最终负责在相对较大的应用程序组件之间切换。所以 MVP 也可以说 MVPC（!!）。顺便说一句，这是我理解MVP的方式，显然不是任何基本规则。

因此，对于复杂的网络应用，我已经倾向于 MVP 。

Answer 4

您的问题是“我应该使用其中一种设计模式”。

我不得不说这实际上取决于你的项目范围。在一个与预算较多的大型组织中与其他系统相互依赖的大型项目中，我认为它们绝对值得考虑。

我认为这些模式经常在较小的项目上被过度使用，因为它们可能会增加不必要的复杂性和成本。

松散耦合的要点是，您可以在以后更改数据库或UI，或重新使用业务逻辑。很多时候，这种情况从未发生过您必须意识到这些模式中的任何一个都需要更长的时间来实现并使代码复杂化。因此，我强烈建议您真正考虑这一点并权衡您的选择。通过使用非常简单的架构来完成工作并降低复杂性，您通常可以更快地提供更好的解决方案！

Answer 5

这取决于您使用的框架。只需使用它支持的内容。 我见过的大多数Web框架都使用前端控制器模式，并将其称为MVC或MVP。

Answer 6

我认为你应该这样做。它们更难实现，尤其是在MS世界中，因为他们尽一切努力推动Web窗体并更轻松地构建Web应用程序。 点击 使用它们你编程很简单，你觉得你做了很多工作。但是，在您的网站变大之后，它们会变得越来越难以维护。 点击 使用MVC和MVP可以分离模型（表示您正在使用的域的基本类），控制器和视图。最棒的是，您可以在移动应用程序或Windows应用程序等其他应用程序中重用您的模型。然后，它们与数据库有更多共同之处，因此您必须编写更少的代码。你只需要编写控制器和视图。 点击 我是新手，但我看到了好处，因为当我不得不在一个地方改变某些东西时别的东西会崩溃（所以你也必须考虑松散的耦合并编写单元测试）。在Web窗体中编写测试是不可能的。 点击 点击 但是，如果您正在构建代表某个人或公司的应用程序，而Web上没有业务逻辑，并且您必须快速完成，那么Web窗体就是有益的。还有用于构建原型，以便您可以在完成后显示应用程序将能够执行的操作。

Answer 7

我喜欢这两种模式。我最好的做法是选择一种模式，这种模式总是优于NO模式。

我已经在这两种模式上开发了很多应用程序，我个人的感觉是，当你是RAD开发人员并且你对CSS＆amp; javascript（主要是winforms开发人员想要创建一个webapp，没有冒犯;-)）你应该使用MVP模式，因为这很容易与Web应用程序项目一起使用。

但是当你知道分配CSS＆amp; javascript然后你应该考虑ASP.NET MVC模式。

Answer 8

我更喜欢MVC模式，因为松耦合。模型，视图和控制器之间有明确的分离，通过隔离它更适合测试驱动开发或单元测试。