什么时候MVC模式适合？

Question

注意：我不是指任何特定框架对MVC的解释

如果我正在设计一个富客户端Silverlight应用程序，例如，它涉及相对复杂的UI行为，例如在由动态用户定义查询填充的两个GridView之间拖放行，这是否适合使用？

某些UI行为（例如在另一个有效行上删除行）也会导致应用业务规则并相应地更新模型。如果MVC不适合这种类型的应用程序;什么是构建这个的好方法？

---

编辑：重读我原来的问题，看起来有点笼统;我会把它分解成一个更直接的问题：

MVC模式不合适的用户交互粒度是否有上限？

即。一个UI，它涉及一个控制器动作，必须处理mouse_move，mouse_button_up等等......

Answer 1

您在Silverlight开发中很早就会发现的一件事就是绑定的强大功能，您会发现自己想要完全远离视图来抽象逻辑。虽然它与MVC类似，但在Silverlight中有更好的方法来处理它。因此，如果您正在构建Silverlight应用程序，那么最好不要查看MVVM Pattern。 MVVM Light Toolkit是我最喜欢的这种模式的实现之一。如果您正在构建任何Silverlight或WPF应用程序，那么绝对值得一试。

Answer 2

当您想要从基础数据的商务规则中分离UI时，MVC框架是一个很好的结果。这允许一个非常好的模块化架构，您可以在没有太多麻烦的情况下更换UI或数据层。

听起来你已经在考虑MVC，因此它应该是一个很好的选择。玩得开心！

Answer 3

如果你的应用程序模型适合MVC模型，MVC模式很有用......就这么简单。但是，如果您的用户界面是使用SørenLauesen或类似的可用性模型构建的，那么您通常会有多个控制器用于单个GUI等。此外，如果您的用户界面非常简单，MVC可能过度。在某些情况下，性能要求或程序员生产力也可能使MVC失效。

有一些应用程序，MVC是一个非常好的模型。还有一些应用程序，其中MVC根本就没有意义。

Answer 4

Somewhat related