注：我不是指MVC的任何特定框架的解释什么时候MVC模式合适？
如果我设计的实例的富客户端Silverlight应用程序，涉及相对复杂的UI行为，如两者之间拖放行由动态用户定义的查询填充GridViews，这将是一个适当的模式使用？
某些UI行为（例如在另一个有效行上放置一行）也会导致应用业务规则，并相应更新模型。如果MVC不适合这种类型的应用程序;什么是构建这个的好方法？
编辑： 重读我原来的问题，似乎有点一般;我将它分解成更直接的问题：
是否有用户互动的情况MVC模式是不恰当的粒度上限？
即，一个涉及控制器操作的UI需要处理mouse_move，mouse_button_up等等的东西...
在Silverlight开发很早就会发现的一件事是绑定的力量，您会发现自己希望将您的逻辑完全从视图中抽象出来。虽然它与MVC类似，但在Silverlight中有更好的方式来处理它。正因为如此，如果你正在构建一个Silverlight应用程序，那么最好查看MVVM Pattern。 MVVM Light Toolkit是我最喜欢的这种模式的实现之一。如果您正在构建任何Silverlight或WPF应用程序，绝对值得一看。
当你想要从底层数据的商业规则中分离UI时，MVC框架是一个很好的选择。这允许一个非常好的模块化体系结构，您可以在没有太多麻烦的情况下更换UI或数据层。
听起来像你已经在MVC方面思考，因此它应该是一个很好的选择。玩得开心！
感谢您的回答克雷格，我只是澄清我的问题有点滑稽 – gn22 2009-12-09 23:34:29
如果您的应用程序模型符合MVC模型，MVC模式非常有用...就是这么简单。但是，如果您的用户界面是使用SørenLauesen或类似的可用性模型构建的，那么您通常会为单个GUI使用多个控制器。另外，如果您的用户界面非常简单，那么MVC可能会过度杀伤。性能要求或编程人员的生产力在某些情况下也会使MVC的用处变得更小。
有一些应用程序，MVC是一个非常好的模型。还有一些应用程序，MVC根本没有意义。
够我竟是朝MVVM移动不知道，这是一个明确的应用模式。感谢您的高举。 – gn22 2009-12-10 17:18:56