带有 WCF 数据的 WPF 应用程序 - EF、Linq2Sql 或 WCF 数据服务 - 没有似乎“简单”

Question

我正在做一些我认为很正常的事情（虽然我个人以前没有必要这样做），并且我认为会有一个“不费吹灰之力”的前进方式，但我还没有找到它- 这真是令人沮丧。

我将创建一个 WPF 应用程序，它是一个面向数据的业务应用程序。我的数据将来自具有标准 SQL Server 2008 数据库的远程 IIS 服务器（由我控制），因此 Web 服务/WCF 似乎是前进的方向。远程服务需要通过（WPF 客户端的）用户名/密码登录来确保（合理地）安全。

我不想使用第 3 方 ORM 产品，但我希望数据层（在服务和数据库之间）能够处理非常简单的 ORM 类型的功能（我真的不想手工制作数据检索和持久层）。我不太担心并发，因为这将是一个相当简单的应用程序。

我的选项似乎是以下之一：

1. 基于 WCF 的 ADO.NET 实体框架
2. WCF 上的 Linq2Sql
3. WCF 数据服务

经过进一步调查，以上似乎都不是我所追求的“不费吹灰之力”

1) ADO.NET 实体框架 - 我对此进行了尝试，并遇到了通过 WCF 序列化对象的各种问题。即使当我尝试生成 POCO 实体并使用它们时，我也必须使用自定义属性来装饰服务合同，以使其始终不会出错，而且我似乎不得不手动操作任何东西，而不是平面对象图。在我看来，EF 根本不是为了通过服务公开而设计的。

2) Linq2Sql - 这似乎并不比 EF 好多少。我似乎不得不用手摇动太多东西。我已经尝试过设计器和 SQLMetal，但似乎没有什么“正常工作”——这一切都需要摆弄。

3) WCF 数据服务 - 从表面上看，这似乎是一个不错的选择，但从本质上讲，我似乎只是在服务层上“以原始方式”公开我的 SQL 数据库表。我无论如何都不是这项技术的专家，但这似乎是一种潜在的危险方法，最重要的是，它似乎不支持任何类型的访问安全作为标准（你必须破解它才能要求身份验证）。

正如我所说，这种情况感觉应该有一个不费吹灰之力的解决方案，但我仍然摸不着头脑。我已经用 .NET 技术做了很多事情，但老实说，这个领域在我的理解上有点漏洞，所以如果我的任何 cmets 或假设是幼稚的，我深表歉意。

当然，我可能只能在 EF 或 Linq2SQL 上做“hacky”，在这种情况下，我可以卷起袖子，接受我没有做的事实错过了一个更优雅的解决方案。

任何帮助/建议将不胜感激。

Answer 1

这有点主观，但我会提供我的意见。

首先，忘记 L2SQL - 它基本上已经过时并且没有 EF4 的完整 POCO 支持（可以完成，但需要 XML 修补或 SQLMetal 生成），这意味着序列化您的实体将是一个左-向右实体克隆的噩梦。

我会使用 ADO.NET Entity Framework over WCF，特别是 Entity Framework 4.0。您将在模型中拥有丰富的灵活性（包括应用 OO 原则（如继承）的能力）。

使用自我跟踪实体。是的，你必须装饰服务合同——这是设计使然，有很多原因。

您始终可以使用 DTO，而不是序列化实际的 EF 实体。

OData 在灵活性和简单性方面也非常出色。但是，如果您只通过单个客户端应用程序使用您的模型，那么专门的服务层 (WCF) 是一种更好的 IMO 方法。

Answer 2

3) WCF 数据服务 - 这看起来像 从表面上看是一个不错的选择，但是 本质上，我似乎只是 公开我的 SQL 数据库表 服务层上的原始'。

这可能是第一印象 - 但它根本上是错误的。您在网络上公开的是一个模型 - 您可以完全控制进入该模型的内容，以及您的 WCF 数据服务的消费者如何能够查看和/甚至更新实体在那个模型中。

这就是 Entity Framework 发挥作用的地方（也是 Linq-to-SQL 惨遭失败的地方）：您可以将您的数据库（或至少部分数据库）放入实体数据模型中，然后对其进行修改。您可以将实体名称调整为与表名称完全不同，可以添加计算属性，可以删除某些属性等等。

如果您谈论的是一个相当简单的应用程序，那绝对是我会采用的方式：

• 获取您的数据库并使用 EF 将其转换为实体数据模型
• 通过 WCF 数据服务公开 EDM，并定义可以只读方式查看的内容，甚至可以通过网络更新的内容