WPF/Silverlight 企业应用程序架构..你做什么？

Question

我想知道社区里生活着什么已经有一段时间了； 我说的是大型的、面向业务的 WPF/Silverlight 企业应用程序。

理论上，有不同的模型在起作用：

• 数据模型（通常链接到数据库表、Edmx/NHibarnate/.. 映射实体）
• 业务模型（包含实际业务逻辑的类）
• 传输模型（暴露给外界的类（dto）） /client）
• 视图模型（您的实际视图绑定到的类）

很明显，这种分离具有明显的优势； 但它在现实生活中有效吗？这是维护的噩梦吗？

那么你做什么呢？ 在实践中，您是否对所有这些模型使用不同的类模型？ 我见过很多变体，例如：

• 数据模型 = 业务模型：数据模型首先实现代码（如 POCO 的），并用作带有业务逻辑的业务模型
• 业务模型 = 传输模型 = 视图模型：商业模式向客户公开；没有映射到 DTO，.. 发生。该视图直接绑定到此业务模型
• Silverlight RIA 服务，开箱即用，并公开数据模型：数据模型 = 业务模型 = 传输模型。有时甚至传输模型 = 视图模型。
• ..

我知道“这取决于”答案就在这里； 但这取决于什么？ 您使用过哪些方法，您如何看待这些方法？

感谢分享，

问候， 科恩

Answer 1

好问题。我从来没有编写过任何真正有进取心的东西，所以我的经验有限，但我会开始。

我当前的（WPF/WCF）项目使用数据模型=业务模型=传输模型=视图模型！
没有数据库后端，因此“数据模型”实际上是序列化为 XML 的业务对象。

我使用了 DTO，但很快发现整理工作极其困难，而且我内心一直存在的过早优化者不喜欢涉及不必要的复制。这可能会再次困扰我（例如，通信序列化有时与持久序列化有不同的需求），但到目前为止，这并不是什么大问题。

我的业务对象和视图对象都需要值更改的推送通知，因此使用相同的方法 (INotifyPropertyChanged) 实现它们是有意义的。这有一个很好的副作用，即我的业务对象可以直接绑定到 WPF 视图中，尽管使用 MVVM 意味着 ViewModel 可以在需要时轻松提供包装器。

到目前为止，我还没有遇到任何重大障碍，并且维护一组对象使事情变得美好而简单。我不敢想象如果我把所有四个“模型”分开，这个项目会有多大。

我当然可以看到拥有单独对象的好处，但对我来说，直到它真正成为一个问题之前，它似乎是浪费精力和复杂化。

正如我所说，这一切的规模都相当小，设计用于在几十台 PC 上运行。我有兴趣阅读真正的企业开发人员的其他回复。

Answer 2

这种分离根本不是一场噩梦，事实上，自从使用 MVVM 作为设计模式以来，我非常支持它的使用。我最近是一个团队的一员，我使用 MVVM 编写了一个相当大的产品的 UI 组件，该组件与处理所有数据库调用等的服务器应用程序进行交互，可以诚实地说这是我从事过的最好的项目之一。

该项目有一个

• 数据模型（不支持 InotifyPropertyChanged 的​​基本类）、
• 视图模型（支持 INPC、关联视图的所有业务逻辑）、
• 视图（仅 XAML）、
• 传输模型（仅调用数据库的方法）

我已将传输模型分类作为一件事，但实际上它是由多层构建的。

我还有一系列 ViewModel 类，它们是 Model 类的包装器，用于添加附加功能或更改数据的呈现方式。这些都支持 INPC，并且是我的 UI 绑定的。

我发现 MVVM 方法非常有用，而且老实说它使代码保持简单，每个视图都有一个相应的视图模型来处理该视图的业务逻辑，然后有各种底层类被视为模型。

我认为通过像这样分离代码可以让事情更容易理解，每个视图模型都不会有混乱的风险，因为它只包含与其视图相关的东西，我们在视图模型之间共有的任何东西都是通过继承来处理的减少重复代码。

当然，这样做的好处是代码立即变得更易于维护，因为对数据库的调用是在我的应用程序中通过对服务的调用来处理的，这意味着只要数据返回并且所需的参数保持不变，UI 永远不需要知道这一点。 UI 也是如此，没有代码隐藏的 UI 意味着可以很容易地调整 UI。

缺点是，遗憾的是，无论出于何种原因，你都必须在代码后面做一些事情，除非你真的想坚持使用 MVVM 并找出一些过于复杂的解决方案，所以在某些情况下，很难或不可能坚持真正的 MVVM 实现（在我们公司，我们认为这没有隐藏代码）。

总之，我认为，如果您正确地使用继承，坚持设计模式并强制执行编码标准，那么这种方法会非常有效，如果您开始偏离，那么事情就会开始变得混乱。

Answer 3

多层不会导致维护噩梦，而且层数越少，维护起来就越容易。我将尝试解释原因。

1) 传输模型不应与数据模型相同

例如，您的 ADO.Net 实体数据模型中有以下实体：

Customer
{
    int Id
    Region Region
    EntitySet<Order> Orders
}

并且您希望从 WCF 服务返回它，因此您像这样编写代码：

dc.Customers.Include("Region").Include("Orders").FirstOrDefault();

还有一个问题：服务的使用者如何确保 Region 和 Orders 属性不为 null 或空？如果 Order 实体有一个 OrderDetail 实体的集合，它们也会被序列化吗？有时您可能会忘记关闭延迟加载，整个对象图将被序列化。

还有一些其他情况：

• 您需要组合两个实体并将它们作为单个对象返回。

• 您只想返回实体的一部分，例如 File 表中除二进制数组类型的 FileContent 列之外的所有信息。

• 您想要从表中添加或删除某些列，但您不想向现有应用程序公开新数据。

所以我认为您确信自动生成的实体不适合 Web 服务。
这就是为什么我们应该创建这样的传输模型：

class CustomerModel
{
    public int Id { get; set; }
    public string Country { get; set; }
    public List<OrderModel> Orders { get; set; }
}

并且您可以自由更改数据库中的表，而不影响 Web 服务的现有使用者，并且您可以更改服务模型而不更改数据库。

为了使模型转换过程更容易，您可以使用 AutoMapper 库。

2) 建议视图模型不应与传输模型相同。

虽然您可以将传输模型对象直接绑定到视图，但这只是一种“一次性”关系：模型不会反映在视图中，反之亦然。
大多数情况下，视图模型类会向模型类添加以下功能：

• 使用 INotifyPropertyChanged 接口通知属性更改

• 有关使用 ObservableCollection 类的集合更改的通知

• 验证属性

• 对视图事件的反应（使用命令或数据绑定和属性设置器的组合）

• 属性转换，类似于 {Binding Converter...}，但在视图模型一侧

同样，有时您需要组合多个模型以在单个视图中显示它们。最好不要依赖于服务对象，而是定义自己的属性，这样，如果模型的结构发生更改，视图模型将是相同的。

我总是使用上述 3 层来构建应用程序，并且效果很好，因此我建议每个人都使用相同的方法。

Answer 4

我们使用的方法类似于 Purplegoldfish 发布的方法，但有一些额外的层。我们的应用程序主要与 Web 服务通信，因此我们的数据对象不绑定到任何特定的数据库。这意味着数据库架构更改不一定会影响 UI。

我们有一个由以下子层组成的用户界面层：

1. 数据模型：这包括支持更改通知的纯数据对象。这些是专门用于 UI 的数据模型，因此我们可以灵活地设计它们以满足 UI 的需求。当然，其中一些对象并不简单，因为它们包含操纵其状态的逻辑。此外，由于我们使用大量数据网格，因此每个数据模型负责提供可绑定到网格的属性列表。

2. 视图：我们的视图的 XAML 定义。为了满足一些复杂的要求，在某些情况下我们不得不诉诸代码隐藏，因为坚持仅使用 XAML 方法太乏味了。

3. ViewModels：这是我们为视图定义业务逻辑的地方。这些人还可以访问由下面描述的数据访问层中的实体实现的接口。

4. Module Presenter：这通常是负责初始化模块的类。它的任务还包括注册与该模块关联的视图和其他实体。

然后我们有一个数据访问层，其中包含以下内容：

1. 传输对象：这些通常是由 Web 服务公开的数据实体。其中大部分是自动生成的。

2. 数据适配器，例如 WCF 客户端代理和任何其他远程数据源的代理：这些代理通常实现一个或多个向 ViewModel 公开的接口，并负责异步对远程数据源进行所有调用，将所有响应转换为 UI根据需要等效数据模型。在某些情况下，我们使用 AutoMapper 进行翻译，但所有这些都专门在这一层完成。
   我们的分层方法有点复杂，应用程序也是如此。它必须处理不同类型的数据源，包括 Web 服务、直接数据库访问和其他类型的数据源（例如 OGC Web 服务）。