|
|
You're in the
dotnet web services
group:Exposing a private instance field in SOAP
dotnet web services:
table. PrimaryKeys can only be created and the class only implements .ToString(). The PrimaryKey class internally stores the data as either a int or a Guid depending on the structure of the database. If we simply used int to represent a primary key, rather than this PrimaryKey class then programmers could do things like performing mathematically operations on the primary key which should be best avoided since this is not the nature of primary keys. The PrimaryKey class works really well except when it comes to exposing it through SOAP. Because the class contains no public fields and no public properties then SOAP/WSDL does not expose any insights into the class. When an instance of the PrimaryKey class flows through SOAP and turns up at the client I can't actually do anything with it since I can't get any data out of it and cast it into the client's PrimaryKey class. Ideally I would to put an attribute around the 'private int primaryKey' field of the PrimaryKey class (that internally records the value of the primary key) so that it can be exposed to SOAP and SOAP alone. Is this possible? I have studied the SOAP attributes and nothing seems available. Are there any work arounds? One idea I had was to drop the .ToString() method and just have a .Value property. I would only implement the Get and not the Set but evidently SOAP/WSDL needs both a Get and a Set before it is exposed to SOAP. Thanks in advance Dave A
Thanks. I appreciate the effort that you put into that great answer.
There has to be a solution though. I am going to keep thinking about it and if I come up with something then I will post back what I find. [quoted text, click to view] "Sami Vaaraniemi" <samivanospam@pleasejippii.fi> wrote in message news:eLVnOQbZFHA.3712@TK2MSFTNGP09.phx.gbl... > I'm afraid there's no simple and easy answer to this issue. As you've > noticed, the XML serializer serializes only public fields and read-write > properties. The data format is customizable to some extent, but all > private state and behavior associated with your classes is lost. > > That said, it is possible to hack around this issue. You can edit the > consumer-side proxy, remove the data classes generated along with the > proxy and have the proxy refer to the original class(es). This does allow > you to share the same type between the web service and the consumer and > thus share behavior, but private state is still lost. > > The bottom line is that if you really want to share objects between a > service and its consumers, then you might want to consider using a > distributed object technology such as .NET Remoting. Web Services merely > pass XML documents back and forth, and trying to share types or behavior > will run into issues. > > Regards, > Sami > > > "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message > news:OohQNL%23YFHA.1044@TK2MSFTNGP10.phx.gbl... >>I have a class called 'PrimaryKey' that represents the primary key of a >>table. >> >> PrimaryKeys can only be created and the class only implements >> .ToString(). >> The PrimaryKey class internally stores the data as either a int or a Guid >> depending on the structure of the database. >> >> If we simply used int to represent a primary key, rather than this >> PrimaryKey class then programmers could do things like performing >> mathematically operations on the primary key which should be best avoided >> since this is not the nature of primary keys. >> >> The PrimaryKey class works really well except when it comes to exposing >> it >> through SOAP. Because the class contains no public fields and no public >> properties then SOAP/WSDL does not expose any insights into the class. >> >> When an instance of the PrimaryKey class flows through SOAP and turns up >> at the client I can't actually do anything with it since I can't get any >> data out of it and cast it into the client's PrimaryKey class. >> >> Ideally I would to put an attribute around the 'private int primaryKey' >> field of the PrimaryKey class (that internally records the value of the >> primary key) so that it can be exposed to SOAP and SOAP alone. >> >> Is this possible? I have studied the SOAP attributes and nothing seems >> available. Are there any work arounds? >> >> One idea I had was to drop the .ToString() method and just have a .Value >> property. I would only implement the Get and not the Set but evidently >> SOAP/WSDL needs both a Get and a Set before it is exposed to SOAP. >> >> Thanks in advance >> Dave A >> >> >> >> >> >> >> > > >
I knew there had to be an answer and there is!
It just barely works with .NET 1.x - http://dotnetified.com/PermaLink.aspx?guid=E86B447E-AA95-49B6-909F-CDA36ACF481F And it fully works with .NET 2.0 -http://weblogs.asp.net/cweyer/archive/2004/08/02/205798.aspx Dave A ('Exposing private members using SOAP and XML Serialization' - that is there for google) [quoted text, click to view] "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message news:%23DC1iJcZFHA.1512@TK2MSFTNGP10.phx.gbl... > Thanks. I appreciate the effort that you put into that great answer. > > There has to be a solution though. I am going to keep thinking about it > and if I come up with something then I will post back what I find. > > "Sami Vaaraniemi" <samivanospam@pleasejippii.fi> wrote in message > news:eLVnOQbZFHA.3712@TK2MSFTNGP09.phx.gbl... >> I'm afraid there's no simple and easy answer to this issue. As you've >> noticed, the XML serializer serializes only public fields and read-write >> properties. The data format is customizable to some extent, but all >> private state and behavior associated with your classes is lost. >> >> That said, it is possible to hack around this issue. You can edit the >> consumer-side proxy, remove the data classes generated along with the >> proxy and have the proxy refer to the original class(es). This does allow >> you to share the same type between the web service and the consumer and >> thus share behavior, but private state is still lost. >> >> The bottom line is that if you really want to share objects between a >> service and its consumers, then you might want to consider using a >> distributed object technology such as .NET Remoting. Web Services merely >> pass XML documents back and forth, and trying to share types or behavior >> will run into issues. >> >> Regards, >> Sami >> >> >> "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message >> news:OohQNL%23YFHA.1044@TK2MSFTNGP10.phx.gbl... >>>I have a class called 'PrimaryKey' that represents the primary key of a >>>table. >>> >>> PrimaryKeys can only be created and the class only implements >>> .ToString(). >>> The PrimaryKey class internally stores the data as either a int or a >>> Guid >>> depending on the structure of the database. >>> >>> If we simply used int to represent a primary key, rather than this >>> PrimaryKey class then programmers could do things like performing >>> mathematically operations on the primary key which should be best >>> avoided >>> since this is not the nature of primary keys. >>> >>> The PrimaryKey class works really well except when it comes to exposing >>> it >>> through SOAP. Because the class contains no public fields and no public >>> properties then SOAP/WSDL does not expose any insights into the class. >>> >>> When an instance of the PrimaryKey class flows through SOAP and turns up >>> at the client I can't actually do anything with it since I can't get any >>> data out of it and cast it into the client's PrimaryKey class. >>> >>> Ideally I would to put an attribute around the 'private int primaryKey' >>> field of the PrimaryKey class (that internally records the value of the >>> primary key) so that it can be exposed to SOAP and SOAP alone. >>> >>> Is this possible? I have studied the SOAP attributes and nothing seems >>> available. Are there any work arounds? >>> >>> One idea I had was to drop the .ToString() method and just have a .Value >>> property. I would only implement the Get and not the Set but evidently >>> SOAP/WSDL needs both a Get and a Set before it is exposed to SOAP. >>> >>> Thanks in advance >>> Dave A >>> >>> >>> >>> >>> >>> >>> >> >> >> > >
I'm afraid there's no simple and easy answer to this issue. As you've
noticed, the XML serializer serializes only public fields and read-write properties. The data format is customizable to some extent, but all private state and behavior associated with your classes is lost. That said, it is possible to hack around this issue. You can edit the consumer-side proxy, remove the data classes generated along with the proxy and have the proxy refer to the original class(es). This does allow you to share the same type between the web service and the consumer and thus share behavior, but private state is still lost. The bottom line is that if you really want to share objects between a service and its consumers, then you might want to consider using a distributed object technology such as .NET Remoting. Web Services merely pass XML documents back and forth, and trying to share types or behavior will run into issues. Regards, Sami [quoted text, click to view] "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message news:OohQNL%23YFHA.1044@TK2MSFTNGP10.phx.gbl... >I have a class called 'PrimaryKey' that represents the primary key of a >table. > > PrimaryKeys can only be created and the class only implements .ToString(). > The PrimaryKey class internally stores the data as either a int or a Guid > depending on the structure of the database. > > If we simply used int to represent a primary key, rather than this > PrimaryKey class then programmers could do things like performing > mathematically operations on the primary key which should be best avoided > since this is not the nature of primary keys. > > The PrimaryKey class works really well except when it comes to exposing it > through SOAP. Because the class contains no public fields and no public > properties then SOAP/WSDL does not expose any insights into the class. > > When an instance of the PrimaryKey class flows through SOAP and turns up > at the client I can't actually do anything with it since I can't get any > data out of it and cast it into the client's PrimaryKey class. > > Ideally I would to put an attribute around the 'private int primaryKey' > field of the PrimaryKey class (that internally records the value of the > primary key) so that it can be exposed to SOAP and SOAP alone. > > Is this possible? I have studied the SOAP attributes and nothing seems > available. Are there any work arounds? > > One idea I had was to drop the .ToString() method and just have a .Value > property. I would only implement the Get and not the Set but evidently > SOAP/WSDL needs both a Get and a Set before it is exposed to SOAP. > > Thanks in advance > Dave A > > > > > > >
Indeed, you can serialize a private field as shown in the article by
overriding the serialization for the object. You could also do this with a wrapper class and a bit of reflection. However, (I think) in the consumer the field now becomes public in the generated class so the behavior (encapsulation) is lost. The consumer will be able to access the PrimaryKey value directly which is what I believe you wanted to avoid. Regards, Sami [quoted text, click to view] "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message news:OIHCKeeZFHA.2128@TK2MSFTNGP15.phx.gbl... >I knew there had to be an answer and there is! > > It just barely works with .NET 1.x - > http://dotnetified.com/PermaLink.aspx?guid=E86B447E-AA95-49B6-909F-CDA36ACF481F > > And it fully works with .NET > 2.0 -http://weblogs.asp.net/cweyer/archive/2004/08/02/205798.aspx > > Dave A > > ('Exposing private members using SOAP and XML Serialization' - that is > there for google) > > "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message > news:%23DC1iJcZFHA.1512@TK2MSFTNGP10.phx.gbl... >> Thanks. I appreciate the effort that you put into that great answer. >> >> There has to be a solution though. I am going to keep thinking about it >> and if I come up with something then I will post back what I find. >> >> "Sami Vaaraniemi" <samivanospam@pleasejippii.fi> wrote in message >> news:eLVnOQbZFHA.3712@TK2MSFTNGP09.phx.gbl... >>> I'm afraid there's no simple and easy answer to this issue. As you've >>> noticed, the XML serializer serializes only public fields and read-write >>> properties. The data format is customizable to some extent, but all >>> private state and behavior associated with your classes is lost. >>> >>> That said, it is possible to hack around this issue. You can edit the >>> consumer-side proxy, remove the data classes generated along with the >>> proxy and have the proxy refer to the original class(es). This does >>> allow you to share the same type between the web service and the >>> consumer and thus share behavior, but private state is still lost. >>> >>> The bottom line is that if you really want to share objects between a >>> service and its consumers, then you might want to consider using a >>> distributed object technology such as .NET Remoting. Web Services merely >>> pass XML documents back and forth, and trying to share types or behavior >>> will run into issues. >>> >>> Regards, >>> Sami >>> >>> >>> "Dave A" <dave@sigmasolutionsdonotspamme.com.au> wrote in message >>> news:OohQNL%23YFHA.1044@TK2MSFTNGP10.phx.gbl... >>>>I have a class called 'PrimaryKey' that represents the primary key of a >>>>table. >>>> >>>> PrimaryKeys can only be created and the class only implements >>>> .ToString(). >>>> The PrimaryKey class internally stores the data as either a int or a >>>> Guid >>>> depending on the structure of the database. >>>> >>>> If we simply used int to represent a primary key, rather than this >>>> PrimaryKey class then programmers could do things like performing >>>> mathematically operations on the primary key which should be best >>>> avoided >>>> since this is not the nature of primary keys. >>>> >>>> The PrimaryKey class works really well except when it comes to exposing >>>> it >>>> through SOAP. Because the class contains no public fields and no >>>> public >>>> properties then SOAP/WSDL does not expose any insights into the class. >>>> >>>> When an instance of the PrimaryKey class flows through SOAP and turns >>>> up >>>> at the client I can't actually do anything with it since I can't get >>>> any >>>> data out of it and cast it into the client's PrimaryKey class. >>>> >>>> Ideally I would to put an attribute around the 'private int primaryKey' >>>> field of the PrimaryKey class (that internally records the value of the >>>> primary key) so that it can be exposed to SOAP and SOAP alone. >>>> >>>> Is this possible? I have studied the SOAP attributes and nothing seems >>>> available. Are there any work arounds? >>>> >>>> One idea I had was to drop the .ToString() method and just have a >>>> .Value >>>> property. I would only implement the Get and not the Set but evidently >>>> SOAP/WSDL needs both a Get and a Set before it is exposed to SOAP. >>>> >>>> Thanks in advance >>>> Dave A >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |