In short: Trying to write a wcf service for a winform-app that invokes a stored procedure on a webserver. So far no problem - my service exposes the method "execStp(string nameOfStoredProcedure, stpParamList parameterList)"
[OperationContract]
int execStp(string stpName, srsWcfLib.Utilities.stpParamList paramList);
where stpParamList is another class holding of a third class stpParams (which basically holds a name/value pair of an SqlParameter
To add parameters to the list, I wrote a method in the second class
public void addParameter(string ParamName, object ParamValue)
{
this._Parameters.Add(new stpParam(ParamName, P开发者_JAVA技巧aramValue));
}
List<stpParam> _Parameters = new List<stpParam>();
[DataMember]
public List<stpParam> Parameters
{
get { return _Parameters; }
set { _Parameters = value; }
}
When instantiating the List-class in the win-app
stpParamList stpParams = new stpParamList();
I can access stpParams.Parameters
, but NOT stpParams.addParameter (name, value);
What am I missing (obviously)...?
Thank you, Reinhard
WCF only brings over the properties to the client, not the functions. I forget the term they use, but it is basically just a property/field dump that gets sent through.
To solve this, reference the same Entity library in the client, and under "configure WCF Service" check "reuse reference" for that library.
Erich has nailed the problem on the head: WCF is a MESSAGE based transport system, e.g. you will transfer a serialized message of your object. The server-side object with any additional functions will be serialized into XML or a binary format, sent across the wire to the client.
The client however only has the XSD (XML Schema) file exposed by your service at its disposal - it will create a client-side class that has the same "data signature" on the wire - i.e. the same fields, by the same name and type - but it cannot magically recreate any functions and/or methods your server-side code has. All it can do is deserialize the message (text or binary) back into a data-only representation of the class.
This is not a bug or a problem of a binding - this is a fundamental design choice for WCF - the only connection between the client and the server is the serialized message - anything that can be represented in XML schema. It will happily serialize and deserialize data - but it cannot move code / behavior across. You're NOT passing the actual objects by reference like with a normal function call - the WCF runtime serializes your parameters into XML and sends it across.
Now if you do control both ends of the wire, e.g. both the client and the server, there is a way around this, which violates the SOA principles a bit (but it can be useful). If you put your service contracts and data contracts into a separate assembly Contracts.dll
(a class library), and then reference it from both the server side and the client side, you can indeed actually share the common .NET type srsWcfLib.Utilities.stpParamList
with all its functionality. In those cases, however, you'll need to do a bit more work on the client side and instantiate your client proxy manually in code (rather than have Visual Studio or svcutil create the client proxy for you), since you need to reference that shared contracts assembly and use its types directly (rather than creating client-side classes).
Marc
精彩评论