我们正处于将一个相当大的“旧版”3 层客户端-服务器应用程序转移/更新到新版本的早期设计/准备阶段。我们正在考虑在 Winforms 上进行 WPF，因为这似乎是微软推动未来发展的方向，我们希望最大化应用程序的生命周期/跨度。也就是说，在重写期间，我们希望对我们的数据访问/表示模型进行尽可能多的更改，以尽可能多地提高性能。
我一直在做一些研究，但我发现的绝大多数讨论 WPF 的资源只关注简单的数据跟踪应用程序或关注非常基本的 UI 设计/控件。甚至讨论数据表示的少数项目都相当深入。
【问题讨论】：
标签： c# .net sql wpf data-access-layer
考虑使用 MVVM 模式。
【讨论】：
VS2010 团队保留了一篇关于在切换到 WPF 时获得良好性能的博客。
他们有一个系列，WPF in Visual Studio，提供了一些建议（尤其是second part）。
【讨论】：
近 2 年以来，我一直在开发大型企业级 WPF 应用程序。与任何 UI 开发一样，了解您正在使用的特定技术的最佳 UI 设计模式非常重要。根据我使用 WPF 的经验，Model-View-ViewModel 设计模式是最流行的。一旦您了解了 WPF 的数据绑定功能，就很容易理解为什么像 M-V-VM 这样的模式如此被接受。即使您不逐字遵循 M-V-VM 模式（或其变体），也要了解该模式所针对的全局解决方案。基本上，将您的 UI/XAML 文件（视图）保存在一个单独的文件中，并将所有代码隐藏/逻辑（视图模型）保存在另一个文件中。 View 只是对 ViewModel 中的变化做出反应。
保持 ViewModel 独立，您将获得多项好处。
易于为 ViewModel 对象创建自动化测试，因为其中没有图形组件。它只是一个带有方法/属性的对象。
更容易在开发人员之间拆分工作（例如，一个开发人员构建 View，而另一个开发人员构建 ViewModel）。
在 ViewModel 中使用多线程要容易得多，因为它从不直接与 UI 控件交互。如果您曾尝试在后台线程上更新文本框，您就会明白我的意思。
根据我的经验，以下是 WPF 与窗口窗体的一些优缺点：
优点：
为最终用户提供更好的 UI 外观和体验。 WPF 允许您最终控制任何 UI 元素的外观。 （例如，每行包含一个图片/按钮/文本的列表框）。
数据绑定非常棒。绑定 XAML 文件中的 UI 控件以指向 ViewModel 类上的特定属性，一切正常。 UI 只是响应 ViewModel 的任何属性更改。彻底分离！如果您希望多个窗口/用户控件同时显示相同的信息并自动保持同步，您将真正看到这样做的好处。
我在 MSDN 上读到的所有内容都表明，与旧的 Window 窗体相比，Microsoft 将更多的资源投入到 WPF 中。
缺点：
大学习曲线。如果没有 WPF 经验的开发人员需要几个月的时间才能制作出一些复杂的 UI，请不要感到惊讶。这是一项全新的技术，会有一个学习曲线。
Microsoft 尚未开发一些常见的用户控件（例如屏蔽文本框、数据网格）。但是，Visual Studio 2010 确实带有数据网格，并且运行良好。此外，市场上有大量的第三方控件。
我能想到的最好的资源：
“C# 2008 中的 Pro WPF”- 这本书很棒。它有1000多页。它几乎涵盖了 WPF 的所有领域。像参考书一样使用它。通过易于理解的示例直截了当。
链接到 Josh Smith 关于模型-视图-视图模型模式的文章：http://msdn.microsoft.com/en-us/magazine/dd419663.aspx#id0090016
就像我之前提到的，不要太拘泥于某人的 M-V-VM 模式版本。更重要的是，了解 WPF 如何让您轻松创建 ModelView 并让 View 自动响应更改。
祝你好运！如果你能克服那该死的学习曲线，你就不会后悔 WPF。
【讨论】：
尽量减少水下时间的一般建议：
尽快学习数据绑定。在您制作的每个原型中使用数据绑定。即使您正在做的只是玩弄面板布局或网格拆分器的工作方式：在您的窗口中放置一个XmlDataProvider，创建 XML 测试数据并绑定到它。如果您使用 Kaxaml 进行原型设计，这将特别有用。我不知道一旦 VS 2010 在你手中会有多重要，但如果你使用 VS 2008，Kaxaml 是无价的。
阅读 Bea Stollnitz 在 how to debug data binding in WPF. 上的文章 设置 VS 环境，以便在测试 UI 时始终可以看到“输出”窗口。
从一开始就使用 MVVM 和数据模板。假设不存在代码隐藏，并且 UI 和数据模型之间进行互操作的唯一方法是通过数据绑定和命令。你会很快从这个位置后退，但如果你让自己从跳跃中学习这一点，你会发现你所做的一切都更容易。
假设您的应用程序需要能够在 36 英寸宽屏显示器和手机上运行。您会使用固定字体大小并按像素进行测量吗？您不会。
了解Grid 的共享大小范围和星号大小。这两件事意味着您将使用Grid everywhere。 “我怎样才能让这个元素使用屏幕上剩余空间的一半？”这个问题的答案。是：带有Grid。 （但是，“我怎样才能让这个元素使用屏幕上的所有剩余空间？”这个问题的答案是：DockPanel。）
请注意 WPF 不是成熟的技术这一事实及其影响。并不是说它有问题（不是，尽管有错误）或功能不足（同样，有问题，但通常不是关键问题）：而是 WPF 中有很多操作方法在我们真正知道什么是可维护的，什么是不可维护之前写的文章和博客文章。验证是一个很好的例子。您可以找到关于如何设置验证规则并将它们附加到绑定的无穷无尽的解释。您可能不太容易找到稍后写的关于为什么在大多数实际场景中要使用IDataErrorInfo 的帖子。比平时更犹豫是否接受你找到的第一个答案。
如果您认为可组合性和依赖注入是晦涩难懂的架构——宇航员概念，在现实世界的软件开发中几乎没有应用，那就直截了当。
不要担心依赖属性有多复杂。他们可以做很多事情，但实际上，您首先需要考虑的只是更改通知和值继承。更改通知需要一个属性设置器来做某事；这是内置在SetValue 中的。值继承需要一个属性 getter 来做某事；这是内置在GetValue 中的。属性值可以是本地的或继承的，这意味着它们不是存储在字段中，而是存储为字典条目；如果给定的属性没有本地值（即DependencyObject 的字典中没有该属性的值），DependencyObject 会查找父级以获取其值。术语非常冗长，但想法非常简单。
【讨论】：
我发现这个资源提供了几个很好的例子。
微软多合一代码框架
微软多合一代码框架 描绘框架和骨架 微软开发技术 通过三个典型的示例代码 流行的编程语言（视觉 C#、VB.NET、Visual C++）。每个样品 是经过精心挑选、组成和 记录以证明一个 常见问题、测试或使用 基于我们支持的编码方案 在 MSDN 新闻组和 论坛。如果你是一个软件 开发者，你可以填充骨架 用血液、肌肉和灵魂。如果你 是软件测试人员或支持人员 像我们这样的工程师，您可以扩展 示例代码有点适合您的 具体的测试场景或参考您的 客户到这个项目，如果 客户的问题恰逢 我们收集了什么。
今天是 2010 年 3 月 12 日。该项目 有超过 360 个代码示例 涵盖 24 微软开发 Azure、Windows 7 和 Silverlight 3. 集合增长 每周六个样品。你可以找到 最新的样品清单 多合一代码框架示例 目录。
【讨论】：