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

Question

很长一段时间以来，我一直想知道社区中生活着什么；我说的是面向业务的大型 WPF/Silverlight 企业应用程序。

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

• 数据模型(通常链接到您的数据库表、Edmx/NHibarnate/.. 映射实体)
• 业务模型(包含实际业务逻辑的类)
• 传输模型(暴露给外界/客户的类 (dto))
• View 模型(您的实际 View 绑定(bind)到的类)

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

那你是做什么的？实际上，您是否对所有这些模型使用不同的类模型？我已经看到很多关于此的变体，例如:

• 数据模型 = 业务模型:数据模型首先实现代码(如 POCO 的)，并用作具有业务逻辑的业务模型
• 业务模型 = 传输模型 = View 模型:业务模型照原样暴露给客户；没有映射到 DTO，.. 发生。该 View 直接绑定(bind)到此业务模型
• 开箱即用的 Silverlight RIA 服务，公开了数据模型:数据模型 = 业务模型 = 传输模型。有时甚至传输模型 = 查看模型。
• ..

我知道“视情况而定”的答案就在这里；但是它取决于什么？您使用了哪些方法，回头看如何？

感谢分享

问候，公园

Answer 1

好问题。我从来没有编写过任何真正具有企业精神的代码，所以我的经验有限，但我会开始。

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

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

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

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

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

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