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

Question

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

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

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

Answer 1

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

Answer 2

我已经发布了另外一个问题了以下的答案，尽管它可能是更合适的位置 。

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

所以我已经倾向于MVP用于复杂的网络应用程序。

Answer 3

两者都是很好的选择。

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

此外，考虑到采用MVC模式的框架数量，在MVC中与您的同事交谈，您将会使用熟悉的语言。

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

但是，如果您正在构建代表某个人或公司的应用程序，而Web上没有业务逻辑，并且您必须快速完成，那么Web窗体就是有益的。 还可以构建原型，以便在完成后显示应用程序可以执行的操作。

Answer 7

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

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

但是当你知道分配CSS和javascript时，你应该考虑ASP.NET MVC模式。

Answer 8

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