EF4 + STE:通过WCF服务重新连接?每一次都使用一个新的objectcontext? [英] EF4 + STE: Reattaching via a WCF Service? Using a new objectcontext each and every time?

查看:202
本文介绍了EF4 + STE:通过WCF服务重新连接?每一次都使用一个新的objectcontext?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在计划将WCF(不是ria)与实体框架4和STE(自我跟踪功能)结合使用。如果我正确地说明了这一点,我的WCF应该返回一个实体或者一组实体(例如使用LIST,而不是IQueryable)给客户端(在我的case silverlight中)



客户端那么可以更改实体或更新它。在这一点上我相信是自我追踪?这是我有点困惑,因为有很多报告的STEs没有跟踪的问题。



无论如何...然后更新我只需要发送实体到我的WCF服务另一种方法来进行更新。我应该每次创建一个新的OBJECTCONTEXT?在每个方法中?



如果我每次在我的WCF上的每个方法中创建一个新的objectcontext,那么我不需要将STE重新附加到objectcontext? p>

所以基本上这不行吗?

  using(var ctx = new MyContext())
{
ctx.Orders.ApplyChanges(order);
ctx.SaveChanges();
}

或者我应该在WCF服务的构造函数中创建一个对象上下文所以1调用和使用相同wcf实例的每个附加调用使用相同的objectcontext?



我可以在客户端的每个方法调用中创建和销毁wcf服务 - 因此每次创建一个新的objectcontext。



我知道保持objectcontext很长时间不是一个好主意。



任何见解或信息都将非常感激。



谢谢

解决方案

您正在提出几个问题,以便我们分别回答:



返回IQueryable:



您不能返回IQueryalbe。 IQueryable描述应该执行的查询。当您尝试从服务返回IQueryable时,它将在服务响应的序列化期间执行。它通常导致异常,因为ObjectContext已经关闭。



客户端跟踪



是STE可以跟踪客户端上的变化,如果客户使用STEs!与STE的组装应在服务和客户端之间共享。



共享ObjectContext



不要在更新数据的服务器环境中共享ObjectContext。始终为每个呼叫创建新的ObjectContext实例。我描述了此处的原因。



附加STE



您不需要附加STE。 ApplyChanges将为您做所有事情。另外,如果要从服务操作中恢复订单,您应该调用AcceptChanges。



在服务构造函数中创建对象上下文:



请注意,WCF有自己的规则如何处理服务实例。这些规则基于 InstanceContextMode ,并使用绑定(和您可以通过执行 IInstanceProvider 实现自己的规则)。例如,如果您使用BasicHttpBinding,默认实例将是PerCall,这意味着WCF将为每个请求创建新的服务实例。但是如果您使用NetTcpBinding,则默认实例将是PerSession,WCF会将单服务实例重用于单客户端(单客户端代理实例)的所有请求。



在客户端上重用服务代理:



这也取决于使用的绑定和服务实例。当使用面向会话的绑定时,客户端代理与单一服务实例相关。该代理上的调用方法将始终在同一服务实例上执行操作,因此服务实例可以是有状态的(可以包含调用之间共享的数据)。这通常不是一个好主意,但这是可能的。当使用面向会话的连接时,您必须处理可能出现的几个问题(更复杂)。 BasicHttpBinding不允许会话,即使使用单个客户端代理,每个呼叫都由新的服务实例处理。


I am planning to use WCF (not ria) in conjunction with Entity Framework 4 and STE (Self tracking entitites). If i understnad this correctly my WCF should return an entity or collection of entities (using LIST for example and not IQueryable) to the client (in my case silverlight)

The client then can change the entity or update it. At this point i believe it is self tracking???? This is where i sort of get a bit confused as there are a lot of reported problems with STEs not tracking..

Anyway... Then to update i just need to send back the entity to my WCF service on another method to do the update. I should be creating a new OBJECTCONTEXT everytime? In every method?

If i am creaitng a new objectcontext everytime in everymethod on my WCF then don't i need to re-attach the STE to the objectcontext?

So basically this alone wouldn't work??

using(var ctx = new MyContext())
{
    ctx.Orders.ApplyChanges(order);
    ctx.SaveChanges();
}

Or should i be creating the object context once in the constructor of the WCF service so that 1 call and every additional call using the same wcf instance uses the same objectcontext?

I could create and destroy the wcf service in each method call from the client - hence creating in effect a new objectcontext each time.

I understand that it isn't a good idea to keep the objectcontext alive for very long.

Any insight or information would be gratefully appreciated

thanks

解决方案

You are asking several questions so I will try to answer them separately:

Returning IQueryable:

You can't return IQueryalbe. IQueryable describes query which should be executed. When you try to return IQueryable from service it is being executed during serialization of service response. It usually causes exception because ObjectContext is already closed.

Tracking on client:

Yes STEs can track changes on a client if client uses STEs! Assembly with STEs should be shared between service and client.

Sharing ObjectContext:

Never share ObjectContext in server environment which updates data. Always create new ObjectContext instance for every call. I described reasons here.

Attaching STE

You don't need to attach STE. ApplyChanges will do everything for you. Also if you want to returen order back from your service operation you should call AcceptChanges on it.

Creating object context in service constructor:

Be aware that WCF has its own rules how to work with service instances. These rules are based on InstanceContextMode and used binding (and you can implement your own rules by implement IInstanceProvider). For example if you use BasicHttpBinding, default instancing will be PerCall which means that WCF will create new service instance for each request. But if you use NetTcpBinding instead, default instancing will be PerSession and WCF will reuse single service instance for all request comming from single client (single client proxy instance).

Reusing service proxy on a client:

This also depends on used binding and service instancing. When session oriented binding is used client proxy is related to single service instance. Calling methods on that proxy will always execute operations on the same service instance so service instance can be stateful (can contains data shared among calls). This is not generally good idea but it is possible. When using session oriented connection you have to deal with several problems which can arise (it is more complex). BasicHttpBinding does not allow sessions so even with single client proxy, each call is processed by new service instance.

这篇关于EF4 + STE:通过WCF服务重新连接?每一次都使用一个新的objectcontext?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆