带有 WCF 数据的 WPF 应用程序 - EF、Linq2Sql 或 WCF 数据服务 - 似乎没有一个“简单”
我正在做一些我认为很正常的事情（尽管我个人以前没有这样做过），并且我假设会有一个“无需思考”的前进方式，但我还没有找到它 - 这是真的很令人沮丧。
我将创建一个 WPF 应用程序，这是一个面向数据的业务应用程序。我的数据将来自具有标准 SQL Server 2008 数据库的远程 IIS 服务器（由我控制），因此 Web 服务/WCF 似乎是前进的方向。远程服务需要通过用户（WPF 客户端）用户名/密码登录（合理地）保证安全。
我不想使用第 3 方 ORM 产品，但我希望数据层（服务和数据库之间）能够处理非常简单的 ORM 类型功能（我真的不想手工制作数据检索和持久层）。我不太担心并发性，因为这将是一个相当简单的应用程序。
我的选择似乎是以下之一：
- ADO.NET Entity Framework over WCF
- Linq2Sql over WCF
- WCF Data Services
经过进一步调查，以上似乎都不是我在
1) ADO.NET 实体框架 - Ive 之后的“简单选择”我尝试过这个，并遇到了通过 WCF 序列化对象的各种问题。即使当我尝试生成 POCO 实体并使用它们时，我也必须使用自定义属性来装饰服务契约，只是为了让它不会一直出错，而且我似乎必须手动启动除平面对象图之外的任何东西。在我看来，EF 根本就不是为了通过服务公开而设计的。
2) Linq2Sql - 这看起来并不比 EF 好多少。我似乎不得不手动启动太多东西。我已经尝试过设计器和 SQLMetal，但似乎没有什么“能正常工作”——这一切都需要摆弄。
3) WCF 数据服务——从表面上看，这似乎是一个不错的选择，但本质上，我似乎只是在服务层上“原始”地公开了我的 SQL 数据库表。无论如何，我都不是这项技术的专家，但这似乎是一种潜在危险的方法，而且最重要的是，它似乎不支持任何类型的访问安全作为标准（你必须破解它才能要求身份验证）。
正如我所说，这种情况感觉应该有一个简单的解决方案，但我仍然摸不着头脑。我已经用 .NET 技术做了很多事情，但说实话，这个领域在我的理解中存在一些漏洞，所以如果我的任何评论或假设是天真的，我深表歉意。
当然，很可能我能做的就是在 EF 或 Linq2SQL 上进行“hacky”长途旅行，在这种情况下，我可以卷起袖子，接受这样的事实：我没有错过更多优雅的解决方案。
任何帮助/建议将不胜感激。
I am doing something I consider to be pretty normal (although I personally haven't had to do it before), and I have assumed there'd be a 'no-brainer' way forward, but Im yet to find it - which is really frustrating.
I will be creating a WPF application, which is a data-oriented business application. My data will come from a remote IIS server (that I control) that has a standard SQL server 2008 database, so Web services/WCF seem to be the way forward. The remote service needs to be secure (reasonably) via a user (of the WPF client) username/password login.
I dont want to use 3rd party ORM products, but I expect the data layer (between the service and the database) to be able to cope with very simple ORM type functionality (I really dont want to hand-craft a data retrieval and persistence layer). Im not worried about concurrency very much as this will be a fairly simple app.
My options seem to be one of the following:
- ADO.NET Entity Framework over WCF
- Linq2Sql over WCF
- WCF Data Services
On further investigation, none of the above seem to be the 'no brainer' Im after
1) ADO.NET entity Framework - Ive had a play with this and getting all sorts of issues serializing objects over WCF. Even when I try to generate POCO entities and use them, Im having to decorate service contracts with custom attributes just to get it to not error all the time, and I seem to have to hand-crank anything more than a flat object graph. It seems to me that EF simply isn't designed to be exposed via a service.
2) Linq2Sql - This doesn't seem much better than EF. I seem to have to hand-crank too much stuff. Ive tried the designer and SQLMetal but nothing seems to 'just work' - it all needs fiddling with.
3) WCF Data Services - this seems like a good option on the face of it, but essentially it seems like I'm just exposing my SQL database tables 'in the raw' over the service layer. Im not an expert in this technology by any means but it seems like a potentially dangerous approach, and on top of that it doesnt seem to support any kind of access security as standard (you have to hack it to require authentication it seems).
As I said, this scenario feels like it should have a no-brainer solution, but Im still scratching my head. Ive done lots of things with .NET technologies, but to be honest this area represents a bit of a hole in my understanding, so I apologize if any of my comments or assumptions are naive.
Of course, it may well be that the 'hacky' long-way-round on EF or Linq2SQL may be all I can do, in which case I can roll up my sleeves, and accept the fact that I haven't missed a more elegant solution.
Any help/advice will be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这有点主观，但我会提供我的意见。
首先，忘记 L2SQL - 它基本上已经过时，并且没有 EF4 的完整 POCO 支持（可以做到，但需要XML 修补或 SQLMetal 生成），这意味着序列化实体将是一场从左到右的实体克隆噩梦。
我会使用 ADO.NET 实体框架而不是 WCF，特别是实体框架 4.0。您的模型将具有丰富的灵活性（包括应用面向对象原则（例如继承）的能力）。
使用自我跟踪实体。是的，您必须装饰服务合同 - 这是设计使然，并且有很多原因。
您始终可以使用 DTO，而不是序列化实际的 EF 实体。
OData 的灵活性和简单性也非常出色。但是，如果您仅通过单个客户端应用程序使用模型，那么在我看来，专用服务层 (WCF) 是更好的方法。
This is a tad subjective, but i'll offer my opinion.
First of all, forget L2SQL - it's basically obsolete and doesn't have the full POCO support of EF4 (it can be done, but needs XML tinkering, or SQLMetal generation), which means serializaing your entities will be a left-to-right entity cloning nightmare.
I would go with ADO.NET Entity Framework over WCF, Entity Framework 4.0 specifically. You will have a wealth of flexibility in your model (including the ability to apply OO principles such as inheritance).
Use Self-Tracking-Entities. Yes, you have to decorate service contracts - this is by design, and there are many reasons for this.
You could always use DTO's, as opposed to serializing the actual EF entities.
OData is really good as well in it's flexibility and simplicity. But if your only consuming your model via a single client application, a specialized service layer (WCF) is a better approach IMO.
这可能是第一印象——但从根本上来说这是错误的。您在网络上公开的是一个模型 - 您可以完全控制进入该模型的内容，以及 WCF 数据服务的使用者如何查看和/甚至更新实体在那个模型中。
这就是实体框架发挥作用的地方（也是 Linq-to-SQL 惨败的地方）：您可以将数据库（或至少部分数据库）放入实体数据模型中，然后对其进行修改。您可以将实体名称调整为与表名称完全不同，可以添加计算属性，可以删除某些属性等等。
如果您谈论的是一个相当简单的应用程序，那么我肯定会采用这种方式：
That might be a first impression - but it's fundamentally wrong. What you're exposing over the web is a model - and you have full control over what gets into that model, and how consumers of your WCF Data Services might be able to see and/or even update entities in that model.
That's where Entity Framework comes in and shines (and where Linq-to-SQL miserably fails): you can grab your database (or at least parts of it) into an Entity Data Model, and then modify it. You can tweak your entity names to be totally different from your table names, you can add computed attributes, you can remove certain attributes and much more.
If you're talking about a fairly simple app, that's definitely the way I'd go: