在 DataContract 集访问器中访问 WCF 服务?
天啊,
我正在尝试弄清楚如何(如果可能的话)从 datacontract 属性的 set 访问器中访问 WCF 服务对象。
例如:
class MyService:IMyService
{
...
public string SomeMethod(int property)
...
}
[DataContract]
class MyType
{
[DataMember]
public int MyProperty
{
...
set
{
// Use a call to the already created WCF instance inside the set accessor
_otherValue = WCFInstance.SomeMethod(value);
}
}
...
}
这可能不是最佳实践,但这可能吗?在上述情况下,我可以实例化 MyService 类的一个新实例来进行调用,但是当内存中已经有一个实例正在处理 WCF 请求时,这似乎是一种浪费。
任何帮助将不胜感激。如有任何疑问或需要更多信息,请随时询问。
非常感谢, 史蒂夫
G'day,
I am trying to work out how (if it is even possible) to access the WCF Service object from within a set accessor for the datacontract property.
For instance:
class MyService:IMyService
{
...
public string SomeMethod(int property)
...
}
[DataContract]
class MyType
{
[DataMember]
public int MyProperty
{
...
set
{
// Use a call to the already created WCF instance inside the set accessor
_otherValue = WCFInstance.SomeMethod(value);
}
}
...
}
This is probably not best practice, but is this even possible? I can instantiate a new instance of the MyService class to make the call in the above situation, but it seems a waste when there is already one in memory processing the WCF request.
Any assistance would be heaps appreciated. Any questions or more information required, please feel free to ask.
Many thanks,
Steve
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我有类似的问题。我需要此功能来在客户端访问某些属性时进行某种“延迟”加载。
当您的服务客户端使用 ChannelFactory(来自 WCF)时,您必须拥有对定义 SerivceContracts 和 OperationContracts 的程序集的引用。
然后您就可以在同一个程序集中轻松实现创建服务通道的方法。
在 SerivceContract/DataContract 程序集中:
客户端:
I had a similar problem. I need this functionality for doing a kind of "lazy" loading while the client accessing some properties.
When your service client uses the ChannelFactory (from WCF) you must have a reference to the assembly that defines the SerivceContracts and the OperationContracts.
Then you can easily implement the method for creating a serivce channel in the same assembly.
In the SerivceContract/DataContract assembly:
Client-Side:
虽然我一开始就不同意这样做,但探索这个想法很有趣。
考虑到整体情况:MyType 的实例将在服务器端和客户端创建。
它们要么由代码显式创建,要么在 WCF 框架反序列化消息时创建。例如,如果您的服务采用 MyType 对象作为参数,那么您的客户端代码必须创建一个实例并将其传递给 WCF 调用。此时,WCF 框架将通过调用所有 getter 方法并写入 XML 来序列化它,然后服务器端的 WCF 框架将创建一个新副本并调用所有 set 方法反序列化期间。
在服务器端,您新反序列化的 MyType 实例可能能够通过以下代码获取服务实例:(
我不知道这是否可行,因为 set 方法将在MyType 实例正在被反序列化。此时当前 InstanceContext 可用吗?)
但在客户端,没有任何操作上下文,因此您无法调用此代码。
您可以只检查 OperationContext.Current 是否为 null。或者,您可以手动编码服务器端和客户端接口定义,以便服务器的 MyType 实现具有此额外的 setter 逻辑,而客户端的实现则没有。当然,拥有两个相应但略有不同的接口定义会带来整个维护问题。
祝你好运,我对你的冒险如何进行很感兴趣。
While I disagree with doing this in the first place, it is interesting to explore the idea.
Taking the overall picture into account: Instances of MyType would be created on the server side and on the client side.
They would either be explicitly created by code, or created when the WCF framework deserializes a message. For example, if your Service takes an object of MyType as a parameter, then your client code would have to create an instance and pass it to a WCF call. At this point, the WCF framework will serialize it by invoking all of the getter methods and writing to XML, and then the WCF framework on the server side will create a new copy and call all of the set methods during deserialization.
On the server side, your newly deserialized MyType instance might be able to get the service instance via the following code:
(I don't know if that would work, because the set methods will be called while the MyType instance is being deserialized. Is the current InstanceContext available at this point?)
But on the client side, there isn't any operation context so you cannot call this code.
You could just check if OperationContext.Current is null or not. Or you could hand-code the server side and client side interface definitions, so that the server's implementation of MyType has this extra setter logic while the client's implementation does not. Of course, having two corresponding yet slightly different interface definitions introduces a whole maintenance issue.
Good luck, I'd be interested in how your adventure works out.