WCF 数据服务使用来自基于 EF 的存储库的数据
我们有一个基于 EF4 / POCO 的现有存储库，并且运行良好。我们希望使用 WCF 数据服务添加一个服务层并寻求一些最佳实践建议。
到目前为止，我们已经开发了一个具有 IQueryable 属性的类，并且 getter 触发存储库的“获取所有用户”方法。到目前为止，问题有两个：
1）它需要我们修饰 poco 对象的 ID 字段，以告诉数据服务哪个字段是 id。现在这意味着我们的 POCO 对象不是“纯粹的”。
2）它无法弄清楚对象之间的关系（我猜这很明显）。
我现在已经停止了这种方法，我想也许我们应该从存储库中公开 OBjectContext 并使用 EF 的更多“自动”功能。
有人有关于将存储库模式与 WCF 数据服务一起使用的任何建议或示例吗？
We have an existing repository which is based on EF4 / POCO and is working well. We want to add a service layer using WCF Data Services and looking for some best practice advice.
So far we have developed a class which has a IQueryable property and the getter triggers the repository 'get all users' method. The problem so far have been two-fold:
1) It required us to decorate the ID field of the poco object to tell data service what field was the id. This now means that our POCO object is not 'pure'.
2) It cannot figure out the relationships between the objects (which is obvious i guess).
I've now stopped this approach and i'm thinking that maybe we should expose the OBjectContext from the repository and use more 'automatic' functionality of EF.
Has anybody got any advice or examples of using the repository pattern with WCF Data Services ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想这是一个务实的问题。装饰 POCO 会破坏其他东西吗？如果没有，也许这是最好的方法。
WCF 数据服务和 oData 相当新，我也一直在寻找指导，但它似乎有点单薄。
I guess it's a matter of being pragmatic. Does decorating the POCO break anything else? If not, perhaps it's the best way to do it.
WCF Data Services and oData are pretty new, I've also been looking for guidance and it seems a bit thin.
您能否详细说明一下您想要公开的内容以及谁将使用它？
到目前为止，我在我们的项目中看到的问题
MyDataService ：DataService 拆分逻辑，所以我们
创建了助手。我想我们可以继承存储库 - （实际上只是在我输入此内容时想到这一点！）
应该委托给帮助者（或基类）以确保
干燥。即 - 如果你的存储库已经
有 GetAllUsers，并且逻辑如下
myservice.svc/Users 不处理，
您可能需要实施查询
拦截器进行过滤 -
再次，DRY 意味着一个帮助器（或基本方法）
存储库和拦截器可以
使用。
很好地进行身份验证/
授权 - 在查询中
拦截器，这是一个很好的方法
确保您只能看到
你被允许看到的东西。
一些陷阱......
如果它是基于 Flash / Flex 的，你会
可能 Flash 有问题/
Flex 无法使用 HTTP
放置/合并或删除。你四处走走
通过使用 x-httpmethod-override
如果是 javascript / jquery, make
确保打开 json
总的来说，我真的很喜欢它，这是一种公开 API 的超级快速方式，并且只要你没有繁重的业务逻辑，它就可以很好地工作。
Can you expand a bit more on what you want to expose, and who'll be using it?
The issues I've seen so far in our project
MyDataService : DataService splits logic, so we've
created helpers. I suppose we could have inherited Repository though - (literally just thought of that as I typed this!)
should delegate to helpers (or base class) to ensure
DRY. ie - if your repository already
had GetAllUsers, and does logic that
myservice.svc/Users doesn't handle,
you may need to implement a query
interceptor to do the filtering -
again DRY means a helper (or base method) that both
the repository and interceptor can
use.
to tap in nicely to authentication /
authorisation - in a query
interceptor, it's a nice way to
ensure you're allowed to see only the
things you're allowed to see.
A couple of traps....
If it's Flash / Flex based you will
probably have issues with Flash /
Flex not being able to use HTTP
PUT/MERGE or DELETE. You get around
this by using x-httpmethod-override
If it's javascript / jquery, make
sure you turn on json
Overall, I really like it, a super fast way to expose an API, and provided you don't have heavy business logic, it works well.