MVVM 会扼杀 Silverlight 的开发吗？ [关闭]答案

【问题标题】：Is MVVM killing silverlight development? [closed]MVVM 会扼杀 Silverlight 的开发吗？ [关闭]
【发布时间】：2011-03-03 17:17:16
【问题描述】：

这是我脑海中盘旋了一段时间的问题。前几天晚上我和一个人聊天，他告诉我他不会使用导航框架，因为他不知道它是如何与 MVVM 一起工作的。尽管我试图解释模式应该加点盐，但他不会听。

我的意思是，模式在解决某些问题时很棒。有时，模式只有一部分解决了特定问题，而其他部分则导致不同的问题。任何开发人员的目标都是结合使用模式知识和远见来构建可靠的应用程序。

我觉得 MVVM 正在成为统治它们的一种模式。由于.Net 不直接支持它，因此需要一些花哨的业务才能使其工作。我觉得人们错过了该模式的要点，即松散耦合、可测试的代码，而是跳过了障碍，错过了尝试完全遵循 MVVM 的丰富经验。

MVVM 很棒，但我希望它带有对新手的警告或免责声明，因为我担心人们会因为害怕被 mvvm 棒打而回避 Silverlight 开发。

编辑：我可以添加为编辑吗？我使用并同意 MVVM 作为我知道在我的项目中何时可行和不可行的模式。我的问题在于它所具有的包容性，好像它必须被用作开发的一部分。它被用作一个完整的特征，而不是一个模式，它是。

编辑 2：感谢到目前为止所有的 cmets，从这里浮出水面的一个问题是我直到现在还没有考虑过的问题。是否为 GUI/RIA 开发引入了更丰富更高级的框架，显示了这一代 RAD 开发的弱点。也就是说，是否缺乏与这些框架一起教授的代码设计和模式知识？我曾经要求一本关于 C# 的书（在 Pro C# 和 .Net 框架流行之前），并被告知为什么我想知道 C# 减去 winforms/asp。

当然有很多关于这些主题的书籍/知识库，但是除了超级明星和非常优秀的程序员之外，人们还在使用它们吗？

【问题讨论】：

根据我的经验，回避 Silverlight 开发的真正原因是 Silverlight 测试框架的糟糕状态。无法为给定的 Silverlight 应用干净、快速、高效地运行一套单元测试是一个巨大的障碍。
这似乎更像是对封闭思想和狭隘思维的咆哮，而不是实际的 SO 问题。我不一定不同意你的观点，但博客可能是更好的场所。
@Dana，我同意你的观点，但我觉得这已经超出了个人意见。在它开始渗透到可能不了解更多的新用户之前，可以忽略思想封闭。
@Matt +1，测试总是很重要，虽然与特异性无关，但它永远不是一个重点！
-1 我认为您的问题的标题具有煽动性。我很难在自己的应用程序中协调 MVVM 和 System.Windows.Navigation，但这并不是 Silverlight 开发注定要失败的。我认为您的核心问题与“我应该在 Silverlight 项目中使用 MVVM 吗？”重复。 stackoverflow.com/questions/375301/…

标签： silverlight design-patterns mvvm

【解决方案1】：

所以，我认为许多新的 MVVM 开发人员忘记了一些事情 - 模式可以帮助您，而不是相反。以这种方式构建软件倾向于随着您的项目变得越来越大，让您的生活更轻松，但如果它完全妨碍您完成特定任务，请退后一步并问：“在这种特定情况下， MVVM 在这里帮助我吗？”如果这能让你的生活更轻松，你可以不时“作弊”。

【讨论】：

+1 我赞同这个观点
+1 我同意，有关该主题的更多信息，请参阅我的编辑。

【解决方案2】：

实际上，我已经非常有效地将 MVVM 与带有 Windows Phone 7 框架的导航应用程序一起使用，使用命令和消息传递。但是，如果有人告诉您无需在代码隐藏中添加一些代码即可使用 Silverlight 的所有功能，那么他们就是在自欺欺人。在有帮助且有意义的地方使用模式，并在特定功能需要自定义内容时使用“非模式”。

【讨论】：

+1，我同意你的观点，这是我的观点。

【解决方案3】：

假设您的问题也适用于 WPF，我有点想知道问题是否不仅仅是 WPF/Silverlight 的大量学习曲线，甚至在您尝试 MVVM 之前。想想所有需要用 WPF 学习的新东西（我假设是 Silverlight）：XAML、依赖属性、附加属性、路由事件、路由命令、静态资源、动态资源、样式、数据模板、控件模板、数据绑定、等等，等等等等。然后考虑到微软发布这项技术时使用了一组不完整的，至少是 WPF，皮肤不好的控件，你有一种挫败感和不可避免的感觉，你正在处理一种技术，是“没有准备好迎接黄金时段”。我的意思是，在 WPF Toolkit 出现之前，甚至还没有合适的 DataGrid 控件。

一旦您了解了所有这些内容，MVVM 就是另一个障碍，但我认为这不是人们加入 WPF/Silverlight 潮流的主要障碍。也就是说，如果微软能像支持 ASP.NET MVC 那样支持它，那就太好了。就目前而言，您必须下载和使用第三方工具，例如 MVVM Foundation 和 MVVM Toolkit（顺便说一下，它们有很多重叠，应该合并到一个项目中）。

所以，我同意你的观点，但我认为 MVVM 所涉及的大部分挑战可能是由于缺乏 Microsoft 的支持，以及 WPF/Silverlight 固有的复杂性，而不是由于MVVM 模式本身。

【讨论】：

很可能就是这样。 WPF/Silverlight 本质上是复杂的。我想知道问题是否可能是对新手的模式和代码设计没有足够的重视。在我在 silverlight 上读过的书中，它都是浮华的，没有结构。
@DeanMc，评论被大力支持。重点始终是平台可以为您做什么，而不是平台可以做什么（以及如何做）。
干杯，很高兴知道人们也有同样的想法。

【解决方案4】：

顺便说一句，这里的答案很好。很好的讨论和重要的讨论。毫无疑问，学习 Silverlight 对新开发人员来说可能是令人生畏的，而 MVVM 框架无疑会使这一点更加复杂。

但是，我同意有人不理解它并不是对框架的挖掘。我仍然有开发人员告诉我，控制/依赖注入的反转太令人困惑而无法学习，但这会导致这些无效模式吗？如此多经过验证的“现场”软件依赖于这些概念的事实告诉我，即使一开始难以掌握或理解，它们也是合理的。

再一次，当我开始学习外语时，很难，但一旦我坚持下去，现在我可以说得自如了，想知道为什么开始这么难。

我想最让我害怕的趋势是这样一种观念，即由于某种原因很复杂，企业应用程序应该由不能或不会掌握复杂概念的初学者开发人员轻松构建。这就是它真正归结为的原因。你不会让医生说，“帮助，让这个脑部手术更容易，这样任何人都可以做到。”是专门的。构建伟大的软件也是专业的，这就是为什么顾问会要求他们的服务获得高额报酬：这是他们在理解构建和开发解决方案的正确方法方面所提供的价值。

如果您正在制作小行星游戏、奇幻游戏、媒体网站、YouTube 仿制品等，那么您可能不需要 MVVM，而且它是多余的。如果您正在构建一个包含一些表单和图表的小型网站，那么请按照您的喜好构建它并完成它。

如果您正在构建一个由多个动态模块组成的大型复杂网站，移动数千或数百万条记录并需要扩展到大量并发用户，那么您不能指望设计会在翻阅后弹出一本书的几页或浏览几个网站。像这样的软件很复杂，有很多活动部件，并且需要对架构有牢固的把握。

令我惊讶的是，人们大概构建了这些更复杂的应用程序，但仍然没有构建这些更复杂的应用程序。团队中有经验丰富的人吗？您是否有架构师来删除您可以使用的框架？

我的意思是，这个例子只是告诉我问题不在于 MVVM，而在于开发人员。 “因为 MVVM 而避免导航？”真的吗？ MVVM 与它有什么关系？编写导航部分，让视图模型存在于页面中。为什么我的导航必须从视图模型驱动？

来一个。如果它那么复杂，我认为它与模式无关，而与开发人员有关的一切只是不了解开发。不要责怪模式。也许他们需要坚持使用更简单的应用程序。以我的经验，了解该模式的人对软件的理解程度足够高，以至于他们知道何时以及何时不使用该模式。

我知道有很多动作可以将其归结为“普通消费者”并使其变得简单，但我认为这就像试图说“微积分是找到曲线下面积的错误方法，因为它太难了学习。”虽然 MVVM 不像微积分那么复杂，但构建复杂的软件是一项复杂的工作，我认为您永远不会简化它或将其归结为一个简单的公式（也不应该）。如果您在使用 MVVM 时遇到困难，请不要使用它 - 找一些更简单、更容易的东西。如果您的项目足够复杂而无法使用它，但您仍然没有掌握它，请聘请能做到的人，让他们进行探索并向他们学习。

不，我不想让 Microsoft 告诉我使用什么模式，我也不认为这是他们的责任。我是一名专业人士，我有责任花时间学习和了解我正在构建的内容，以便以最佳方式为客户构建它。 Microsoft 不一定知道我的客户做什么或需要什么，那么他们怎么可能告诉我使用什么模式呢？像 Prism 这样的项目之所以很棒，是因为它们是一种折衷方案：它们提供指导并分享如何完成某事的“最佳实践”，而不会强迫开发人员实施。

【讨论】：

【解决方案5】：

我正在将 MVVM 用于 Windows Phone 7 应用程序。我真的很喜欢它的想法，但是要让它运行起来需要太多的 hack、wordarounds 和 3rd 方工具。

Silverlight 的每一个版本都在变得更好，但我仍然认为这项技术是“最前沿的”。

【讨论】：

这是我对它的感觉。我想挫败感来自于为了集成目的而等待下一个版本的黑客代码，当然，如果 SL 团队决定将 MVVM 集成到 Silverlight 中。

【解决方案6】：

Why can't you?

不，MVVM 只是众多模式之一，坦率地说，甚至不是最流行的模式之一。损害 Silverlight 发展的因素是 a) Flash b) 不是 Flash c) 以 Microsoft 为中心 d) 学习曲线。

此外，WPF 似乎并没有真正流行起来这一事实并没有多大帮助。

【讨论】：

我不会说 WPF 没有流行起来，任何认为它会在一夜之间取代 winforms 的人都是天真的。你说 MVVM 不是一种流行的模式，你相信吗？就 WPF/Silverlight 而言，我认为它是最受欢迎的。
我不知道...你一夜之间认为什么？ WPF 于 2006 年发布，这并不完全是“一夜之间”。
为大型跨国公司工作我的观点是，WPF 不会起飞，直到大型公司从 IE 6/7 和 windows 2000/nt 转移，这可能需要一段时间，但这当然是一个论据另一个话题。
对不起-1，但我完全不同意。正如 DeanMc 所指出的，MVVM 可能是最流行的表示模式。而且我完全相信，如果想要创建一个中等规模的 silverlight/wpf 应用程序，使用 mvvm 是不可避免的。 Flash 不会伤害 Silverlight。 Silverlight 正在伤害 Flash。
@dean：如果你不放下，我会的。您正在增加显示模型所需的代码量。这是一个有效的模式，但它似乎是当你别无选择时你所能达到的“核”选项。问题是构建 WPF 数据绑定的方式，你真的没有任何其他选择。一个需要大量样板来完成任何事情的框架设计得很糟糕，但显然让设计师在同一个代码文件上工作比为开发人员设计一个好的 api 更重要。我发现令人惊讶的是很少有人抱怨它

【解决方案7】：

有人在弄清楚如何将导航框架与 MVVM 一起使用时遇到问题 => 有人不使用导航框架 => MVVM 正在扼杀导航框架 => MVVM 正在扼杀 Silverlight 开发。

你会说这个推理链几乎没有缺陷吗？

【讨论】：

不不，你误解了我的意思。我的观点是，人们正在使用 MVVM 并回避开箱即用的对 MVVM 不友好的东西。导航框架只是一个需要“玩”才能使用 MVVM 的示例。