|
|
You're in the
dotnet web services
group:How to return a user-defined data type object from a webservice?
dotnet web services:
In my solution I have 3 projects: 1. A class library. Let's name it CL (let's also name the namespace as "CL"). This class library defines a type like this: [SerializableAttribute()] public class Person { //default constructor private string m_firstName; private string m_lastName; public string FirstName { get { return m_firstName; } set {m_firstName = value; } } public string LastName { get { return m_lastName; } set {m_lastName = value; } } } 2. A webservice that references CL (described above). The webservice defines and implements a web method like: [WebMethod] public CL.Person GetPerson() { CL.Person person = new Person(); //read person from database return person; } 3. A client winforms application that references the class library decribed above, instantiates a proxy to the webservice and calls the web method GetPerson like this: private void FetchPerson() { //proxy gets created CL.Person person = proxy.GetPerson(); } The compiler will generate a compiler error like this: Cannot implicitly convert type 'WinFormClientApp.MyWebService.Person' to 'CL.Person' Where do I go wrong? How to "transport" more complex objects between client and the webserver. I understand how serialization works and I think the serialization should implicitly work when returning such complex types. Maybe I missed something. Should I explicitly use soap serialization and deserialization? Hope not. Please help.
[quoted text, click to view]
On 29 Feb, 22:57, nano2k <adrian.rot...@ikonsoft.ro> wrote: > Hi > > In my solution I have 3 projects: > > 1. A class library. Let's name it CL (let's also name the namespace as > "CL"). > This class library defines a type like this: > > [SerializableAttribute()] > public class Person { > =A0 //default constructor > =A0 private string m_firstName; > =A0 private string m_lastName; > > =A0 public string FirstName { > =A0 =A0 get { return m_firstName; } > =A0 =A0 set {m_firstName =3D value; } > =A0 } > > =A0 public string LastName { > =A0 =A0 get { return m_lastName; } > =A0 =A0 set {m_lastName =3D value; } > =A0 } > > } > > 2. A webservice that references CL (described above). > The webservice defines and implements a web method like: > > [WebMethod] > public CL.Person GetPerson() { > =A0 CL.Person person =3D new Person(); > =A0 //read person from database > =A0 return person; > > } > > 3. A client winforms application that references the class library > decribed above, instantiates a proxy to the webservice and calls the > web method GetPerson like this: > > private void FetchPerson() { > =A0 //proxy gets created > =A0 CL.Person person =3D proxy.GetPerson(); > > } > > The compiler will generate a compiler error like this: > Cannot implicitly convert type 'WinFormClientApp.MyWebService.Person' > to 'CL.Person' > > Where do I go wrong? How to "transport" more complex objects between > client and the webserver. > I understand how serialization works and I think the serialization > should implicitly work when returning such complex types. Maybe I > missed something. > Should I explicitly use soap serialization and deserialization? Hope > not. > > Please help. > Thanks.
[quoted text, click to view]
"nano2k" <adrian.rotaru@ikonsoft.ro> wrote in message news:e44dea5c-53db-4e3a-b73f-fc0148296ca7@o77g2000hsf.googlegroups.com... > Hi > > In my solution I have 3 projects: > > 1. A class library. Let's name it CL (let's also name the namespace as > "CL"). .... > Where do I go wrong? How to "transport" more complex objects between > client and the webserver. > I understand how serialization works and I think the serialization > should implicitly work when returning such complex types. Maybe I > missed something. > Should I explicitly use soap serialization and deserialization? Hope > not. You went wrong in not understanding web services. Web Services don't "transport" complex types. They transport XML. In order to keep you from having to deal with XML, .NET allows the service to "return" a complex type, CL.Person. .NET then takes care of serializing that complex type into XML. On the client side, in order to keep the client from having to deal with XML, .NET creates proxy classes. In particular, it creates a WebReferenceName.Person class. That is whtat the proxy GetPerson method returns, not CL.Person. So, long story short, your client should never reference the class library "CL". -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
Thanks, John.
On 2 Mar, 03:07, "John Saunders [MVP]" <john.saunders at trizetto.com> [quoted text, click to view] wrote:
> "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > news:e44dea5c-53db-4e3a-b73f-fc0148296ca7@o77g2000hsf.googlegroups.com... > > > Hi > > > In my solution I have 3 projects: > > > 1. A class library. Let's name it CL (let's also name the namespace as > > "CL"). > ... > > Where do I go wrong? How to "transport" more complex objects between > > client and the webserver. > > I understand how serialization works and I think the serialization > > should implicitly work when returning such complex types. Maybe I > > missed something. > > Should I explicitly use soap serialization and deserialization? Hope > > not. > > You went wrong in not understanding web services. Web Services don't > "transport" complex types. They transport XML. In order to keep you from > having to deal with XML, .NET allows the service to "return" a complex typ= e, > CL.Person. .NET then takes care of serializing that complex type into XML.= > On the client side, in order to keep the client from having to deal with > XML, .NET creates proxy classes. In particular, it creates a > WebReferenceName.Person class. That is whtat the proxy GetPerson method > returns, not CL.Person. > > So, long story short, your client should never reference the class library= > "CL". > -- > --------------------------------------------------------------------------= -=AD----- > John Saunders | MVP - Windows Server System - Connected System Developer
Anyway,
Passing DataSet or XmlNode objects works by itself. How can I enable my Person class to act like the above ones? Thanks. [quoted text, click to view] On 2 Mar, 08:44, nano2k <adrian.rot...@ikonsoft.ro> wrote:
> Thanks, John. > > On 2 Mar, 03:07, "John Saunders [MVP]" <john.saunders at trizetto.com> > wrote: > > > > > "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > >news:e44dea5c-53db-4e3a-b73f-fc0148296ca7@o77g2000hsf.googlegroups.com...= > > > > Hi > > > > In my solution I have 3 projects: > > > > 1. A class library. Let's name it CL (let's also name the namespace as= > > > "CL"). > > ... > > > Where do I go wrong? How to "transport" more complex objects between > > > client and the webserver. > > > I understand how serialization works and I think the serialization > > > should implicitly work when returning such complex types. Maybe I > > > missed something. > > > Should I explicitly use soap serialization and deserialization? Hope > > > not. > > > You went wrong in not understanding web services. Web Services don't > > "transport" complex types. They transport XML. In order to keep you from= > > having to deal with XML, .NET allows the service to "return" a complex t= ype, > > CL.Person. .NET then takes care of serializing that complex type into XM= L. > > On the client side, in order to keep the client from having to deal with= > > XML, .NET creates proxy classes. In particular, it creates a > > WebReferenceName.Person class. That is whtat the proxy GetPerson method > > returns, not CL.Person. > > > So, long story short, your client should never reference the class libra= ry > > "CL". > > -- > > ------------------------------------------------------------------------= ---=AD=AD----- > > John Saunders | MVP - Windows Server System - Connected System Developer= - Ascunde citatul - > > - Afi=BAare text =EEn citat -
[quoted text, click to view]
"nano2k" <adrian.rotaru@ikonsoft.ro> wrote in message Anyway,news:e6603399-aff7-4e0e-b6aa-d66db798e4b6@41g2000hsc.googlegroups.com... Passing DataSet or XmlNode objects works by itself. How can I enable my Person class to act like the above ones? ========= You don't want to. Really. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
On 3 Mar, 14:34, "John Saunders [MVP]" <john.saunders at trizetto.com> [quoted text, click to view] wrote: > "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > news:e6603399-aff7-4e0e-b6aa-d66db798e4b6@41g2000hsc.googlegroups.com... > Anyway, > > Passing DataSet or XmlNode objects works by itself. > How can I enable my Person class to act like the above ones? > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > You don't want to. Really. > -- > --------------------------------------------------------------------------= -=AD----- > John Saunders | MVP - Windows Server System - Connected System Developer Sorry, but why?
[quoted text, click to view]
"nano2k" <adrian.rotaru@ikonsoft.ro> wrote in message news:35fd1af1-4792-47a3-a0af-a03f77292227@u72g2000hsf.googlegroups.com... On 3 Mar, 14:34, "John Saunders [MVP]" <john.saunders at trizetto.com> [quoted text, click to view] wrote: > "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > news:e6603399-aff7-4e0e-b6aa-d66db798e4b6@41g2000hsc.googlegroups.com... > Anyway, > > Passing DataSet or XmlNode objects works by itself. > How can I enable my Person class to act like the above ones? > > ========= > You don't want to. Really. > -- > -------------------------------------------------------------------------------- > John Saunders | MVP - Windows Server System - Connected System Developer Sorry, but why? Just for the record. = I pretty much told you why before. It's just not how Web Services works. The paradigm of Web Services is all about interoperability between client and server by using industry-standard protocols (HTTP) and data formats (XML). You are asking how you can use the above to pass data specific to a particular platform (Microsoft .NET). There is no provision for that in the Web Services standards. If you read those standards, you'll find mention of the use of standards (XML Schema) to describe the structure of the data to be exchanged. Nowhere in any of those standards is there an ability for you to specify a particular data type from a particular platform. This is in contrast to .NET Remoting, which is platform-specific, and which actually transmits the full typename and assembly name of the types of the data being transferred. This permits the client to receive instances of the precise type sent by the server. There is no provision for anything like this in Web Services. Now, I'm only just recently getting up to speed on WCF, but it looks like when you create a Service Reference (the WCF equivalent of a Web Reference), you have the ability to tell WCF to try to reuse datatypes if the types are declared in particular assemblies. This may give you what you're looking for, as long as you are in a controlled environment where you can be certain that the type that WCF will choose for you is compatible with the type being sent by the server. An example of such an environment is when the server and all of its clients are in the same .NET solution. Tihs may be acceptable for "internal" web services, which are only ever meant to be used by well-known clients. It cannot work in the general case. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
On 5 Mar, 00:46, "John Saunders [MVP]" <john.saunders at trizetto.com>
[quoted text, click to view] wrote: > "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > news:35fd1af1-4792-47a3-a0af-a03f77292227@u72g2000hsf.googlegroups.com... > > On 3 Mar, 14:34, "John Saunders [MVP]" <john.saunders at trizetto.com> > wrote: > > > "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > >news:e6603399-aff7-4e0e-b6aa-d66db798e4b6@41g2000hsc.googlegroups.com... > > Anyway, > > > Passing DataSet or XmlNode objects works by itself. > > How can I enable my Person class to act like the above ones? > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > You don't want to. Really. > > -- > > ------------------------------------------------------------------------= ---=AD=AD----- > > John Saunders | MVP - Windows Server System - Connected System Developer= > > Sorry, but why? > Just for the record. > =3D > I pretty much told you why before. It's just not how Web Services works. > > The paradigm of Web Services is all about interoperability between client > and server by using industry-standard protocols (HTTP) and data formats > (XML). You are asking how you can use the above to pass data specific to a= > particular platform (Microsoft .NET). There is no provision for that in th= e > Web Services standards. If you read those standards, you'll find mention o= f > the use of standards (XML Schema) to describe the structure of the data to= > be exchanged. Nowhere in any of those standards is there an ability for yo= u > to specify a particular data type from a particular platform. > > This is in contrast to .NET Remoting, which is platform-specific, and whic= h > actually transmits the full typename and assembly name of the types of the= > data being transferred. This permits the client to receive instances of th= e > precise type sent by the server. There is no provision for anything like > this in Web Services. > > Now, I'm only just recently getting up to speed on WCF, but it looks like > when you create a Service Reference (the WCF equivalent of a Web Reference= ), > you have the ability to tell WCF to try to reuse datatypes if the types ar= e > declared in particular assemblies. This may give you what you're looking > for, as long as you are in a controlled environment where you can be certa= in > that the type that WCF will choose for you is compatible with the type bei= ng > sent by the server. An example of such an environment is when the server a= nd > all of its clients are in the same .NET solution. Tihs may be acceptable f= or > "internal" web services, which are only ever meant to be used by well-know= n > clients. It cannot work in the general case. > -- > --------------------------------------------------------------------------= -=AD----- > John Saunders | MVP - Windows Server System - Connected System Developer Thanks John. I understand and aggree entirely. But my app is ment to work ONLY on .NET platforms. It is not a public web site or smtg like that. It's an "internal" application for a company that will use the app inside its own VPN. More than that, I'm being asked to secure the entire system so that the webservice will only work with the designated client (also developed by me). So I find myself in this particular case, not in the general case. I assure you I understand how interoperatibility works and its demands. Anyway, your input was very good for me, but what do you say about my particular situation? Creating standard XML schemas for each type I want to "transport" would be a waiste of time, as I am 100% SURE my webservice will only be accessible from a .NET client.
What John is saying is all true, but it's a bit of an ivory tower
approach. Sometimes we developers have to bend the rules because it's the easiest way to get the job done! Anyway, I'm guessing that you have shared code between your server and your client (probably using the same class code, shared in VSS). If that's the case, what you're up against is simply the fact that the object coming from the server via the web service is in a different namespace from the object you want to use in your client. There are a variety of ways of getting around this problem. For example, you can use reflection and generics to change the namespace of the object in question. Here's a code sample that will simply copy everything from one object to another, assuming all their public properties are identical: // the idea for this came from http://www.eggheadcafe.com/tutorials/aspnet/a4264125-fcb0-4757-9d78-ff541dfbcb56/net-reflection--copy-cl.aspx private static T SetProperties<T, U>(U fromRecord, T toRecord) { foreach (PropertyInfo fromField in fromRecord.GetType().GetProperties()) { if (fromField.Name != "Id") { foreach (PropertyInfo toField in toRecord.GetType().GetProperties()) { if (fromField.Name == toField.Name) { toField.SetValue(toRecord, fromField.GetValue(fromRecord, null), null); break; } } } } return toRecord; } Hope that helps! Brad. On Wed, 5 Mar 2008 07:19:31 -0800 (PST), nano2k [quoted text, click to view] <adrian.rotaru@ikonsoft.ro> wrote:
>On 5 Mar, 00:46, "John Saunders [MVP]" <john.saunders at trizetto.com> >wrote: >> "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message >> >> news:35fd1af1-4792-47a3-a0af-a03f77292227@u72g2000hsf.googlegroups.com... >> >> On 3 Mar, 14:34, "John Saunders [MVP]" <john.saunders at trizetto.com> >> wrote: >> >> > "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message >> >> >news:e6603399-aff7-4e0e-b6aa-d66db798e4b6@41g2000hsc.googlegroups.com... >> > Anyway, >> >> > Passing DataSet or XmlNode objects works by itself. >> > How can I enable my Person class to act like the above ones? >> >> > ========= >> > You don't want to. Really. >> > -- >> > -------------------------------------------------------------------------------- >> > John Saunders | MVP - Windows Server System - Connected System Developer >> >> Sorry, but why? >> Just for the record. >> = >> I pretty much told you why before. It's just not how Web Services works. >> >> The paradigm of Web Services is all about interoperability between client >> and server by using industry-standard protocols (HTTP) and data formats >> (XML). You are asking how you can use the above to pass data specific to a >> particular platform (Microsoft .NET). There is no provision for that in the >> Web Services standards. If you read those standards, you'll find mention of >> the use of standards (XML Schema) to describe the structure of the data to >> be exchanged. Nowhere in any of those standards is there an ability for you >> to specify a particular data type from a particular platform. >> >> This is in contrast to .NET Remoting, which is platform-specific, and which >> actually transmits the full typename and assembly name of the types of the >> data being transferred. This permits the client to receive instances of the >> precise type sent by the server. There is no provision for anything like >> this in Web Services. >> >> Now, I'm only just recently getting up to speed on WCF, but it looks like >> when you create a Service Reference (the WCF equivalent of a Web Reference), >> you have the ability to tell WCF to try to reuse datatypes if the types are >> declared in particular assemblies. This may give you what you're looking >> for, as long as you are in a controlled environment where you can be certain >> that the type that WCF will choose for you is compatible with the type being >> sent by the server. An example of such an environment is when the server and >> all of its clients are in the same .NET solution. Tihs may be acceptable for >> "internal" web services, which are only ever meant to be used by well-known >> clients. It cannot work in the general case. >> -- >> -------------------------------------------------------------------------------- >> John Saunders | MVP - Windows Server System - Connected System Developer > >Thanks John. >I understand and aggree entirely. >But my app is ment to work ONLY on .NET platforms. It is not a public >web site or smtg like that. >It's an "internal" application for a company that will use the app >inside its own VPN. >More than that, I'm being asked to secure the entire system so that >the webservice will only work with the designated client (also >developed by me). > >So I find myself in this particular case, not in the general case. I >assure you I understand how interoperatibility works and its demands. > >Anyway, your input was very good for me, but what do you say about my >particular situation? Creating standard XML schemas for each type I >want to "transport" would be a waiste of time, as I am 100% SURE my >webservice will only be accessible from a .NET client. >
[quoted text, click to view]
"nano2k" <adrian.rotaru@ikonsoft.ro> wrote in message Thanks John.news:761ec758-2131-4592-9f5a-1d457a8ec7e0@c33g2000hsd.googlegroups.com... I understand and aggree entirely. But my app is ment to work ONLY on .NET platforms. It is not a public web site or smtg like that. It's an "internal" application for a company that will use the app inside its own VPN. More than that, I'm being asked to secure the entire system so that the webservice will only work with the designated client (also developed by me). So I find myself in this particular case, not in the general case. I assure you I understand how interoperatibility works and its demands. Anyway, your input was very good for me, but what do you say about my particular situation? Creating standard XML schemas for each type I want to "transport" would be a waiste of time, as I am 100% SURE my webservice will only be accessible from a .NET client. PS: I should have been more specific on this on my first post, my bad. ========== If you're doing .NET to .NET, then you shouldn't be using Web Services - you should be using .NET Remoting, or WCF with the NetDataContractSerializer. These cover the case I mentioned, where it's important to be using the correct version of the correct type. They both communicate the actual .NET type name across the channel. If, for some political reason you feel you must stick to ASMX web services, then you can do something like have a translation layer than receives the proxy type, then uses it to fill in an instance of the "real" type. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view]
"Bradley Plett" <plettb@newsgroup.nospam> wrote in message news:p28us3pka1v47mj23pg8njg36ldsgok4va@4ax.com... > What John is saying is all true, but it's a bit of an ivory tower > approach. Sometimes we developers have to bend the rules because it's > the easiest way to get the job done! > > Anyway, I'm guessing that you have shared code between your server and > your client (probably using the same class code, shared in VSS). If > that's the case, what you're up against is simply the fact that the > object coming from the server via the web service is in a different > namespace from the object you want to use in your client. There are a > variety of ways of getting around this problem. For example, you can > use reflection and generics to change the namespace of the object in > question. Here's a code sample that will simply copy everything from > one object to another, assuming all their public properties are > identical: Sorry, Bradley, you're wrong. It's not that the classes are in different namespaces. They're different classes that happen to have a lot of names in common. Try returning a custom type that has a non-default constructor, or methods, or indexers. None of them will show up in the proxy classes because none of them are described by XML Schema or WSDL. Remember: they're _proxy_ classes. They are stand-ins for the real classes, which never leave the server to travel over the wire. They only exist in order to stand as proxy for the real classes, handling serialization and deserialization. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
Yes, I understand that they're different classes and different
objects. That is, after all, the implication of different namespaces. I also understand that there can be issues around the constructor and any hidden data, but pragmatically the solution I suggested will handle the majority of the situations common programmers deal with between server-side and client-side objects. :-) Sure, remoting might be a preferable solution to maintain the full, true object, but sometimes remoting is overkill and I think sometimes we tend to over-think/over-analyze and ignore simple solutions which may be less elegant and less pure, but do the job. Brad. On Wed, 5 Mar 2008 22:11:52 -0500, "John Saunders [MVP]" [quoted text, click to view] <john.saunders at trizetto.com> wrote:
>"Bradley Plett" <plettb@newsgroup.nospam> wrote in message >news:p28us3pka1v47mj23pg8njg36ldsgok4va@4ax.com... >> What John is saying is all true, but it's a bit of an ivory tower >> approach. Sometimes we developers have to bend the rules because it's >> the easiest way to get the job done! >> >> Anyway, I'm guessing that you have shared code between your server and >> your client (probably using the same class code, shared in VSS). If >> that's the case, what you're up against is simply the fact that the >> object coming from the server via the web service is in a different >> namespace from the object you want to use in your client. There are a >> variety of ways of getting around this problem. For example, you can >> use reflection and generics to change the namespace of the object in >> question. Here's a code sample that will simply copy everything from >> one object to another, assuming all their public properties are >> identical: > >Sorry, Bradley, you're wrong. It's not that the classes are in different >namespaces. They're different classes that happen to have a lot of names in >common. Try returning a custom type that has a non-default constructor, or >methods, or indexers. None of them will show up in the proxy classes because >none of them are described by XML Schema or WSDL. > >Remember: they're _proxy_ classes. They are stand-ins for the real classes, >which never leave the server to travel over the wire. They only exist in >order to stand as proxy for the real classes, handling serialization and
Good point - it is worth understanding, that's for sure!
The sample I gave was not intended to modify the proxy class. I never do that either, since regeneration, for me, is a fairly common task. The sample I gave was intended either in an inherited class or as a utility function. Brad. On Thu, 6 Mar 2008 10:49:36 -0500, "John Saunders [MVP]" [quoted text, click to view] <john.saunders at trizetto.com> wrote:
>"Bradley Plett" <plettb@newsgroup.nospam> wrote in message >news:gl5vs319lq7ae3jrnnjdsm20unj0ps3q1j@4ax.com... >> Yes, I understand that they're different classes and different >> objects. That is, after all, the implication of different namespaces. >> I also understand that there can be issues around the constructor and >> any hidden data, but pragmatically the solution I suggested will >> handle the majority of the situations common programmers deal with >> between server-side and client-side objects. :-) >> >> Sure, remoting might be a preferable solution to maintain the full, >> true object, but sometimes remoting is overkill and I think sometimes >> we tend to over-think/over-analyze and ignore simple solutions which >> may be less elegant and less pure, but do the job. > >Brad, in answering newsgroup and forum posts on this topic, I have found >many people who do expect the code they wrote in their server-side classes >to appear on the client side. In my opinion, that's because .NET makes it so >easy to call a "web method". After all, it's a _method_, isn't it? > >The problem is that this totally obscures what's actually happening, so many >people never even learn that there is something different happening at all. >I recommend naming web references with the word "Proxy" in the name, so >that, maybe, some new developer will at least wonder "proxy for what"? It >would also make it easier for me, when they ask "where's my indexer", to >answer, "remember, it's only a proxy class". They could then say, "oh, so >_that's_ why it's called Proxy". > >;-) > >Also, Brad, if you're going to suggest that people modify the proxy class, >you should remind them that the class will be overwritten whenever "Update >Web Reference" is used. For that reason, I _never_ suggest modifying
[quoted text, click to view]
"Bradley Plett" <plettb@newsgroup.nospam> wrote in message news:gl5vs319lq7ae3jrnnjdsm20unj0ps3q1j@4ax.com... > Yes, I understand that they're different classes and different > objects. That is, after all, the implication of different namespaces. > I also understand that there can be issues around the constructor and > any hidden data, but pragmatically the solution I suggested will > handle the majority of the situations common programmers deal with > between server-side and client-side objects. :-) > > Sure, remoting might be a preferable solution to maintain the full, > true object, but sometimes remoting is overkill and I think sometimes > we tend to over-think/over-analyze and ignore simple solutions which > may be less elegant and less pure, but do the job. Brad, in answering newsgroup and forum posts on this topic, I have found many people who do expect the code they wrote in their server-side classes to appear on the client side. In my opinion, that's because .NET makes it so easy to call a "web method". After all, it's a _method_, isn't it? The problem is that this totally obscures what's actually happening, so many people never even learn that there is something different happening at all. I recommend naming web references with the word "Proxy" in the name, so that, maybe, some new developer will at least wonder "proxy for what"? It would also make it easier for me, when they ask "where's my indexer", to answer, "remember, it's only a proxy class". They could then say, "oh, so _that's_ why it's called Proxy". ;-) Also, Brad, if you're going to suggest that people modify the proxy class, you should remind them that the class will be overwritten whenever "Update Web Reference" is used. For that reason, I _never_ suggest modifying generated code. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
Thanks John and Brad
John, Never dealed with .NET Remoting or WCF. Any good and easy to digest resources on these? Thanks. On 5 Mar, 23:29, "John Saunders [MVP]" <john.saunders at trizetto.com> [quoted text, click to view] wrote:
> "nano2k" <adrian.rot...@ikonsoft.ro> wrote in message > > news:761ec758-2131-4592-9f5a-1d457a8ec7e0@c33g2000hsd.googlegroups.com... > Thanks John. > I understand and aggree entirely. > But my app is ment to work ONLY on .NET platforms. It is not a public > web site or smtg like that. > It's an "internal" application for a company that will use the app > inside its own VPN. > More than that, I'm being asked to secure the entire system so that > the webservice will only work with the designated client (also > developed by me). > > So I find myself in this particular case, not in the general case. I > assure you I understand how interoperatibility works and its demands. > > Anyway, your input was very good for me, but what do you say about my > particular situation? Creating standard XML schemas for each type I > want to "transport" would be a waiste of time, as I am 100% SURE my > webservice will only be accessible from a .NET client. > > PS: I should have been more specific on this on my first post, my bad. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > If you're doing .NET to .NET, then you shouldn't be using Web Services - y= ou > should be using .NET Remoting, or WCF with the NetDataContractSerializer. > These cover the case I mentioned, where it's important to be using the > correct version of the correct type. They both communicate the actual .NET= > type name across the channel. > > If, for some political reason you feel you must stick to ASMX web services= , > then you can do something like have a translation layer than receives the > proxy type, then uses it to fill in an instance of the "real" type. > -- > --------------------------------------------------------------------------= -=AD----- > John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view]
"nano2k" <adrian.rotaru@ikonsoft.ro> wrote in message Thanks John and Bradnews:90f357ed-dd41-4d69-8c26-261da38d0be7@x41g2000hsb.googlegroups.com... John, Never dealed with .NET Remoting or WCF. Any good and easy to digest resources on these? Thanks. ============= I have been working seriously with WCF only for the past few weeks. Nonetheless, I'm willing to make a suggestion. Try the Web Services Software Factory: Modeling Edition at http://www.codeplex.com/servicefactory. This is what I've been reviewing for the past week or so, and have mostly decided that I'll recommend it as the way for my company to go forward with web services. As it relates to your situation, I think it will be helpful. WCF makes a strong distinction between the types sent out on the wire, and the types used in the Business Logic Layer, and the Data Access Layer below that. WSSF:ME goes further by requiring you to design your wire formats in an abstract way, and then by helping you create translation methods for translating between the layers. At the same time, it permits the client and server both to work with these "data contract" types in useful ways. You can specify, for instance, that the server will treat a particular collection as an array, but the client will treat it as a List<T>, or a Dictionary<string, T>. Give it a look. -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view] "Bradley Plett" <plettb@newsgroup.nospam> wrote in message news:gl5vs319lq7ae3jrnnjdsm20unj0ps3q1j@4ax.com... > Sure, remoting might be a preferable solution to maintain the full, > true object, but sometimes remoting is overkill and I think sometimes > we tend to over-think/over-analyze and ignore simple solutions which > may be less elegant and less pure, but do the job. > > Brad. That was said beautifully!!
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 |