超越 Entity Framework 与 DevForce
本文展示了 DevForce 的出色之处。DevForce 依赖实体框架进行基本的对象映射和查询功能，但它提供了更多功能；包括多层应用程序的基础设施、强大的业务对象、多个数据源以及非关系型数据源。
Microsoft ADO.NET 实体框架（EF）已成为 .NET 应用程序中数据库访问的标准。它是一个健壮的对象关系映射（ORM）解决方案，将 ORM 带入主流，并通过使用 LINQ（语言集成查询）提高了生产力和类型安全。
当然，应用程序除了处理原始数据外，还有更多内容。例如封装并用业务规则管理数据的业务对象层，以及处理应用程序工作流和用户体验的层。
即使您只专注于数据管理，您仍然会发现实体框架无法满足的企业应用程序需求。其中最主要的包括：
- N 层、互联网和 Silverlight 支持。
- 对带有业务规则、验证和 MVVM 分解的业务对象层的适当支持。
- 高度响应的客户端 UI，利用缓存（和压缩）避免冗余、缓慢的网络往返。
- 集中式服务、服务器端事件以及性能、可扩展性和安全性。
- 分布式事务和映射到多个数据源的实体模型。
- POCO 支持映射到非关系型数据源。
- OData 支持向非 .NET 应用程序公开实体。
管理这些需求是在实体框架之外进行的。您可以自己编写代码，也可以使用像 DevForce 这样经过验证的工具，立即为您节省时间并避免未来的麻烦。
这就是 DevForce 这样的开发工具真正出彩的地方。DevForce 依赖实体框架进行基本的对象映射和查询功能，但它提供了更多。
N 层应用程序的基础设施
实体框架旨在用于两层部署，并未考虑任何特定的客户端场景。
DevForce 实现了一个端到端的 N 层架构，其中间层组件称为 EntityServer。EntityServer 处理来自客户端的 WCF 请求，并保护数据库免受互联网的直接访问。它负责授权、验证和执行客户端查询和保存实体的请求。它还处理其他操作，例如用户认证、订阅服务器端事件、调用自定义服务方法以及托管其他自定义服务器端逻辑（例如创建审计跟踪）。
使用 DevForce，您无需编写领域服务来描述如何执行面向数据的操作。DevForce 已与实体框架完全集成，并且已经知道如何查询、插入、更新和删除。您只需将领域模型复制到服务器，一切即可正常工作。
当然，如果您愿意，可以修改和扩展 EntityServer。您可以：
- 在实体服务管道中注入自定义行为，以添加或更改处理过程，例如指定操作授权或预处理要保存的实体。
- 使用自定义业务逻辑丰富实体类，例如 DevForce 识别并在服务器上执行的验证规则。
- 添加客户端可以调用的自定义服务方法，以在服务器上执行任意操作。
- 订阅服务器端事件，当发生感兴趣的事情时通知客户端。
- 用其他实现替换某些 DevForce 组件。
业务对象增强
实体框架代码生成器生成的实体类不适合通过互联网传输到 WPF 或 Silverlight UI 中进行展示。它们缺乏序列化支持、自我跟踪、验证以及在富互联网应用程序 (RIA) 中重要的许多其他功能。DevForce 使您的实体能够通过互联网传输，并赋予您快速实现动态验证规则、计算、状态转换、动态属性拦截和许多其他扩展的能力。
DevForce 替换了实体框架的默认代码生成器，并生成专门为 RIA 场景设计的实体类。您仍然会使用实体框架的 EDM（实体数据模型）设计器来定义驱动代码生成的概念模型，但 DevForce 扩展了 EDM 设计器以收集一些额外的代码生成信息。
[Bindable(true, BindingDirection.TwoWay)]
[Editable(true)]
[Display(Name="Company Name", AutoGenerateField=true)]
[IbVal.StringLengthVerifier(MaxValue=40, IsRequired=true,
ErrorMessageResourceName="Customer_CompanyName")]
[DataMember]
public string CompanyName {
get { return PropertyMetadata.CompanyName.GetValue(this); }
set { PropertyMetadata.CompanyName.SetValue(this, value); }
}
属性上的特性比代码行还多！
这些特性帮助实体在客户端和服务器上发挥其所需的多种作用。Bindable、Editable 和 Display 是 UI 工具的提示，影响用户控件的选择和配置。StringLengthVerifier 是一个验证规则，源自 CSDL（概念模式定义）中表达的约束。DataMember 是 WCF 标记，表示此属性的值应该被序列化。
您可以通过在 EDM 设计器中抑制它们并在 元数据伙伴类 中添加替代注释来更改或删除所有属性（除了 DataMember）。
get 和 set 的实现是委托给实体内部 PropertyMetadata 类成员的单行代码。
get { return PropertyMetadata.CompanyName.GetValue(this); }
set { PropertyMetadata.CompanyName.SetValue(this, value); }
该属性依赖于辅助方法来执行超出简单值访问的功能。实际上，每个辅助方法都建立了一个属性值管道——一个输入管道和一个输出管道——它们可以做的不仅仅是访问支持字段。setter 的入站管道可以拦截值、验证它们，并引发诸如 PropertyChanged 之类的事件。getter 的出站管道允许开发人员在值传出时拦截它们。
属性拦截、验证 和 更改通知 是 DevForce 的重要功能，它们赋予开发人员对实体在属性级别的行为进行精细控制的能力。简单的单行语法隐藏了通过自定义业务逻辑扩展属性行为的潜力——这些逻辑可能是类定义的一部分，也可能是从类外部的源动态注入的。
多个数据源
实体框架每个实体数据模型只支持一个数据库。但是许多应用程序从存储在多个数据源中的数据中提取。在 DevForce 中，您可以让单个 EntityManager 处理来自多个数据源的实体。回写这些数据源是无缝的，因为如果您愿意，DevForce 会将所有更改封装到单个分布式事务中。
如果您遇到相反的问题——数据库过大，您可以使用 DevForce 将大型数据库分解成多个更小、更易于维护和部署的模型/模块。在 Silverlight 中，DevForce 还支持多 XAP 部署，以便您可以最大限度地减少启动应用程序所需的时间，并且仅在需要时下载额外的模块。
非关系型数据源
实体框架只能将实体映射到关系数据库，但 DevForce 的 POCO (Plain Old CLR Object) 支持允许任何可以作为枚举公开的数据源用作数据源，这使开发人员能够使用统一、一致的对象模型，无论其后端存储如何。
DevForce 还可以将实体模型公开为 OData 服务，以便其他非 .NET 应用程序（如 Java、Android 或 iPhone/iPad）可以处理（甚至修改）您的实体。
结论
对于大多数 RIA 项目来说，DevForce 是一个绝佳的选择——只需查看它提供的优势。如果您想使用 DevForce 超越实体框架，请注意 DevForce 在与某些技术结合使用时，以及在具有匹配设计和开发目标的项目中工作时，效果最佳。
- 服务器端 .NET 4（必需）
- WPF 或 Silverlight 4/5 客户端
- 用于显示和输入复杂数据的多个屏幕
- 查询和保存相关实体集的面向实体的架构
- 包含三十多个实体的实体模型
- 实体框架 4 用于建模实体并持久化其数据
- 由 EF 提供程序支持的关系数据库作为主要数据存储
如果您正在处理的项目有类似的需求，您绝对应该考虑一下 DevForce。