带有WCF数据的WPF应用程序-EF、Linq2Sql或WCF数据服务-似乎没有'；简单'； 我正在做一些我认为很正常的事情（虽然我以前还没做过），我认为有一种“无脑子”的方法，但我还没找到它，这真的很令人沮丧。

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

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

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

WCF上的ADO.NET实体框架

基于WCF的Linq2Sql

WCF数据服务

在进一步的调查中，以上这些似乎都不是我想要的“无脑者”

1） ADO.NET实体框架——我玩过这个游戏，在WCF上序列化对象会遇到各种各样的问题。即使当我尝试生成POCO实体并使用它们时，我也必须用自定义属性来修饰服务契约，以使其不总是出错，而且我似乎必须手动创建平面对象图以外的任何东西。在我看来，EF根本不是设计用来通过服务公开的

2） Linq2Sql—这似乎并不比EF好多少。我似乎不得不处理太多的事情。我试过设计师和SQLMetal，但似乎没有什么能“正常工作”——这一切都需要摆弄

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

正如我所说的，这个场景似乎应该有一个更简单的解决方案，但我仍然挠头。我用.NET技术做了很多事情，但老实说，这一领域在我的理解上有点漏洞，所以如果我的任何评论或假设都是幼稚的，我很抱歉

当然，很可能EF或Linq2SQL上的“黑客”长途跋涉就是我所能做的，在这种情况下，我可以卷起袖子，接受我没有错过更优雅解决方案的事实

---

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

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

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

我将使用ADO.NET实体框架，特别是实体框架4.0。您的模型将具有丰富的灵活性（包括应用OO原则（如继承）的能力）

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

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

OData的灵活性和简单性也非常好。但是，如果您仅通过单个客户端应用程序使用模型，那么专用服务层（WCF）是更好的方法

3） WCF数据服务-这看起来像 从表面上看，这是个不错的选择，但是 基本上，我只是 在中公开我的SQL数据库表 服务层上的原始数据

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

这就是Entity Framework出现并大放异彩的地方（也是Linq to SQL严重失败的地方）：您可以将数据库（或至少部分数据库）抓取到实体数据模型中，然后对其进行修改。您可以调整实体名称，使其与表名称完全不同，可以添加计算属性，可以删除某些属性，等等

如果你说的是一个相当简单的应用程序，我肯定会这么做：

• 抓取数据库并使用EF将其转换为实体数据模型
• 公开EDM over WCF数据服务，并定义哪些内容是只读的，哪些内容甚至可以在线更新

---

我同意，对于任何新的应用程序，EF都是必经之路，而不是L2S。但是L2S确实支持POCO（它从一开始就支持POCO）。只是谷歌“LINQ to SQL POCO”。@Steven-不知道这一点。再说一次，我已经有一段时间没碰L2了——我是EF的粉丝。：）是的，看来自我追踪实体可能是前进的方向。我发现了一个很好的运行（见链接），并会给他们一个尝试-谢谢