|
|
You're in the
dotnet web services
group:Returning Dataset or Datatable via Web Service
dotnet web services:
I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers. http://support.microsoft.com/kb/306134 http://msdn2.microsoft.com/en-us/library/ms996381.aspx Formerly, with classic Microsoft DNA architecture, the ADO Recordset was a primary transport medium, recommended for transmitting data between application tiers. In fact, there are whole books written on the subject. So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. In any case, what then is the recommended alternative? Manually serialize and pass the XML? So why can't this happen automatically for us, just as was the case with classic ADO recordsets? Thanks for your advice? - Joseph Geretz -
Joseph Geretz,
The error message mentioned in the microsoft site is for a different cause. You can pass DataSet / DataTable back & forth between web service. The DataSet / DataTable serialization is supported in ADO.NET 2.0. I'm not finding any restriction to use theam -- Thanks & Regards, Mark Nelson [quoted text, click to view] "Joseph Geretz" wrote:
> I'm a bit puzzled by the current recommendation not to send Datasets or > Datatables between application tiers. > > http://support.microsoft.com/kb/306134 > > http://msdn2.microsoft.com/en-us/library/ms996381.aspx > > Formerly, with classic Microsoft DNA architecture, the ADO Recordset was a > primary transport medium, recommended for transmitting data between > application tiers. In fact, there are whole books written on the subject. > > So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. In > any case, what then is the recommended alternative? Manually serialize and > pass the XML? So why can't this happen automatically for us, just as was the > case with classic ADO recordsets? > > Thanks for your advice? > > - Joseph Geretz - > >
Hi Mark,
I didn't say it wouldn't work. It does work. But it's not recommended: http://msdn2.microsoft.com/en-us/library/ms996381.aspx#asmxremotes_topic11 Avoid passing DataSets between services In our tests, choosing the way the services and callers exchange data-as DataSets or serialized structures-resulted in a much bigger performance impact than choosing any particular distributed systems technology over another. From a performance perspective, we strongly urge you to limit your use of DataSets as a data transfer mechanism to the parts of your application where they are truly needed and that you opt for [Serializable] structures wherever possible. ADO.NET DataSets provide a great way to retrieve, manipulate, sort, and shape data, store it locally for offline use, and synchronize changes back into a central database. If this is a requirement of your application, then of course, it's a valid choice to make. In the .NET Framework 1.x, DataSet values are always serialized to XML (even if you state that you want them serialized as binary or use them with ES or Remoting), and they also contain the XSD describing the data. This, of course, impacts performance. What's more, remember that DataSets are a .NET-specific technology and will significantly limit your interoperability as other platforms won't necessarily be able to serialize and parse data containing serialized DataSets. You can gain considerable performance improvements by instead exchanging serialized data structures. The built-in runtime formatting and XML serialization framework makes it easy, as shown in the tests above. - Joe Geretz - [quoted text, click to view] "Mark Nelson" <MarkNelson@discussions.microsoft.com> wrote in message news:4F9B479B-8B8D-469A-9497-EBA8FE22878B@microsoft.com... > Joseph Geretz, > > The error message mentioned in the microsoft site is for a different > cause. > You can pass DataSet / DataTable back & forth between web service. > The DataSet / DataTable serialization is supported in ADO.NET 2.0. > I'm not finding any restriction to use theam > > -- > Thanks & Regards, > Mark Nelson > > > "Joseph Geretz" wrote: > >> I'm a bit puzzled by the current recommendation not to send Datasets or >> Datatables between application tiers. >> >> http://support.microsoft.com/kb/306134 >> >> http://msdn2.microsoft.com/en-us/library/ms996381.aspx >> >> Formerly, with classic Microsoft DNA architecture, the ADO Recordset was >> a >> primary transport medium, recommended for transmitting data between >> application tiers. In fact, there are whole books written on the subject. >> >> So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. >> In >> any case, what then is the recommended alternative? Manually serialize >> and >> pass the XML? So why can't this happen automatically for us, just as was >> the >> case with classic ADO recordsets? >> >> Thanks for your advice? >> >> - Joseph Geretz - >> >> >>
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:OYwzXixVHHA.4668@TK2MSFTNGP04.phx.gbl... > I'm a bit puzzled by the current recommendation not to send Datasets or > Datatables between application tiers. Joseph, have you decided that your web service will only be consumed by .NET clients, ever? If you want to be able to take advantage of the cross-platform benefits offered by XML Web Services, then you should stop thinking about exposing classes and DataSets and DataTables. Instead, think about exposing XML. John
Isn't everything fundamentally serialized as XML anyway?
So the recommendation is basically to get a DataSet/Table on the server, manually serialize to XML, receive it on the client, and then do whatever you want with it, including de-persisting the XML into a DataSet/Table if the client is so inclined? But my fundamental question still exists: Regardless of how I define the data, the response is going to come back as XML won't it? So why would a non ..NET client have more difficulty dealing with the DataSet/Table XML as opposed to my own explicitly defined XML? - Joseph Geretz - [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:uXLqZp2VHHA.1200@TK2MSFTNGP04.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:OYwzXixVHHA.4668@TK2MSFTNGP04.phx.gbl... >> I'm a bit puzzled by the current recommendation not to send Datasets or >> Datatables between application tiers. > > > Joseph, have you decided that your web service will only be consumed by > .NET clients, ever? > > If you want to be able to take advantage of the cross-platform benefits > offered by XML Web Services, then you should stop thinking about exposing > classes and DataSets and DataTables. Instead, think about exposing XML. > > John > >
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:uQB6$G3VHHA.5108@TK2MSFTNGP06.phx.gbl... > Isn't everything fundamentally serialized as XML anyway? > > So the recommendation is basically to get a DataSet/Table on the server, > manually serialize to XML, receive it on the client, and then do whatever > you want with it, including de-persisting the XML into a DataSet/Table if > the client is so inclined? > > But my fundamental question still exists: Regardless of how I define the > data, the response is going to come back as XML won't it? So why would a > non .NET client have more difficulty dealing with the DataSet/Table XML as > opposed to my own explicitly defined XML? Joseph, This will become a lot clearer once you've had more experience with XML. We all go through the stage you're in - thinking about XML as being just a text format. It's grown way beyond that, and a lot of its power comes from this growth. One thing that's newly-enabled by XML is that the client of your web service may be running on a platform you've never heard of. Because both sides are adhering to standards, you won't actually need to know what kind of client is consuming your service. This is possible, in part, because the metadata of your service is described in WSDL and XML Schema, both of which are XML languages. Now, one aspect of the fact that you can't know who your client is, is the fact that you can't know that they will be able to process a DataSet in any sensible way. So, don't send them a DataSet. Perhaps more importantly, a DataSet is a server-side, implementation-level object. The communication between the client and server should be in terms of the business-level concepts, not in terms of how the server happened to implement the service. I don't know of many businesses for which "DataSet" is a business-level concept. You should ideally start with the business-level concept, manually create an XML Schema to describe it, manually create a WSDL file which will describe the possible interactions with the service in terms of the schema, and only _then_ go implement a service which may implement these concepts and operations in terms of DataSets. That way, you are in control of the contract - the promises made to your client by your WSDL file. John
Hi John,
[quoted text, click to view] > You should ideally start with the business-level concept, manually create > an XML Schema to describe it, manually create a WSDL file which will > describe the possible interactions with the service in terms of the > schema, and only _then_ go implement a service which may implement these > concepts and operations in terms of DataSets. I hear what you are saying, but I'm wondering why you're saying it in a dotnet.framework.webservices forum. The activities you describe, that is the hand tuning of the XML schema and the WSDL file are specifically those activities which are *not* necessary for .NET developers. We use a more RAD approach, basically relying on the IDE to perform this for us behind the scenes. The application I am currently devleoping would have two target audiences. 1. Our own client application. Our developed solution would be implemented end-to-end using Microsoft .NET technologies using the aforementioned RAD approach. 2. Other vendors in our application market space who might want to integrate with our application. Web Services would facilitate this type of integration. Certain vendors might or might not be on the .NET platform themselves. For those who are, terrific for them, they'll be able to consume our web services quite naturally with the convenience of being able to access tabular data in a very convenient format. Those who aren't should still be able to consume our Web Services, however they'll have to manually parse through tabular data themselves without the convenience of the DataTable/DataSet structure since their environments won't provide the convenience of an object representation of the DataTable/Set XML. [quoted text, click to view] > I don't know of many businesses for which "DataSet" is a business-level > concept. The DataSet/Table isn't a business level concept, however a large amount of business level data can be represented quite conveniently in DataSet/Table format. With focus on devleopment convenience (RAD) for our own application developers, I need a more compelling reason to eschew DataSet/Tables than simply the fact that it will disadvantage other non .NET consumers of our Web Service. If it will make it impossible for them to consume our Web Services, that would be a different matter. But I'm not hearing that it would be impossible for them, just marginally more inconvenient. Am I missing anything? Thanks, - Joseph Geretz - [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:%23mtilg3VHHA.4568@TK2MSFTNGP02.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:uQB6$G3VHHA.5108@TK2MSFTNGP06.phx.gbl... >> Isn't everything fundamentally serialized as XML anyway? >> >> So the recommendation is basically to get a DataSet/Table on the server, >> manually serialize to XML, receive it on the client, and then do whatever >> you want with it, including de-persisting the XML into a DataSet/Table if >> the client is so inclined? >> >> But my fundamental question still exists: Regardless of how I define the >> data, the response is going to come back as XML won't it? So why would a >> non .NET client have more difficulty dealing with the DataSet/Table XML >> as opposed to my own explicitly defined XML? > > Joseph, > > This will become a lot clearer once you've had more experience with XML. > We all go through the stage you're in - thinking about XML as being just a > text format. It's grown way beyond that, and a lot of its power comes from > this growth. > > One thing that's newly-enabled by XML is that the client of your web > service may be running on a platform you've never heard of. Because both > sides are adhering to standards, you won't actually need to know what kind > of client is consuming your service. This is possible, in part, because > the metadata of your service is described in WSDL and XML Schema, both of > which are XML languages. > > Now, one aspect of the fact that you can't know who your client is, is the > fact that you can't know that they will be able to process a DataSet in > any sensible way. So, don't send them a DataSet. > > Perhaps more importantly, a DataSet is a server-side, implementation-level > object. The communication between the client and server should be in terms > of the business-level concepts, not in terms of how the server happened to > implement the service. > > I don't know of many businesses for which "DataSet" is a business-level > concept. > > You should ideally start with the business-level concept, manually create > an XML Schema to describe it, manually create a WSDL file which will > describe the possible interactions with the service in terms of the > schema, and only _then_ go implement a service which may implement these > concepts and operations in terms of DataSets. > > That way, you are in control of the contract - the promises made to your > client by your WSDL file. > > John > >
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:uXpdYs3VHHA.4764@TK2MSFTNGP05.phx.gbl... > Hi John, > >> You should ideally start with the business-level concept, manually create >> an XML Schema to describe it, manually create a WSDL file which will >> describe the possible interactions with the service in terms of the >> schema, and only _then_ go implement a service which may implement these >> concepts and operations in terms of DataSets. > > I hear what you are saying, but I'm wondering why you're saying it in a > dotnet.framework.webservices forum. The activities you describe, that is > the hand tuning of the XML schema and the WSDL file are specifically those > activities which are *not* necessary for .NET developers. We use a more > RAD approach, basically relying on the IDE to perform this for us behind > the scenes. Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for web services. I practiced what I preached on one web service and am about to do so again on at least one more. This is called contract-first development. [quoted text, click to view] > The application I am currently devleoping would have two target audiences. > > 1. Our own client application. Our developed solution would be implemented > end-to-end using Microsoft .NET technologies using the aforementioned RAD > approach. It's not a problem if you want to tie yourself to .NET. That works very well, until the point when you decide you need to work with something that's not .NET. [quoted text, click to view] > 2. Other vendors in our application market space who might want to > integrate with our application. Web Services would facilitate this type of > integration. Certain vendors might or might not be on the .NET platform > themselves. For those who are, terrific for them, they'll be able to > consume our web services quite naturally with the convenience of being > able to access tabular data in a very convenient format. Those who aren't > should still be able to consume our Web Services, however they'll have to > manually parse through tabular data themselves without the convenience of > the DataTable/DataSet structure since their environments won't provide the > convenience of an object representation of the DataTable/Set XML. What's wrong with defining your tabular data with a schema, without relying on a DataSet? And, you may find some market resistance if you are asking partners to parse through your XML. [quoted text, click to view] >> I don't know of many businesses for which "DataSet" is a business-level >> concept. > > The DataSet/Table isn't a business level concept, however a large amount > of business level data can be represented quite conveniently in > DataSet/Table format. With focus on devleopment convenience (RAD) for our > own application developers, I need a more compelling reason to eschew > DataSet/Tables than simply the fact that it will disadvantage other non > .NET consumers of our Web Service. If it will make it impossible for them > to consume our Web Services, that would be a different matter. But I'm not > hearing that it would be impossible for them, just marginally more > inconvenient. > > Am I missing anything? Have you tried strongly-typed datasets? They're nice and RAD, but they at least define the data via XML Schema. You get to benefit from RAD, your customers benefit from a strong schema. John BTW, I presume you realize that you need to be careful when changing the structure of the data you're returning? Once you've published the WSDL, you shouldn't really be changing the structure of the returned data, at least not without a versioning mechanism. Again, you may get away with things like adding columns with some clients, but maybe not with others.
Hi John,
[quoted text, click to view] > Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for > web services. I (and some other developers on the team here) don't quite understand what you are saying. When using Visual Studio 2005 for Web Service application development, the IDE takes care of all the wire-up necessary in order to connect the client with the Web Service. This includes creating the WSDL on the server and creating the proxy class for the client which consumes the WSDL and presents a strongly typed interface to the client. Seems pretty RAD to us. [quoted text, click to view] > What's wrong with defining your tabular data with a schema, without > relying on a DataSet? There's nothing wrong with it, in general. However consider the context in particular. The data is retrieved from the database in DataTable format. At the (our) UI it's going to be bound to a data-bound widget (very convenient, for us at least) in DataTable format. Given that this is the case, I'm going to need a compelling reason to persist this into a secondary XML format, and then to convert it back from secondary XML format into a DataTable at the UI. And to do this again, when modified data is sent back to the server. It'll cut down development expense significantly to just leave this in its native format and to let the Framework take care of everything for us. [quoted text, click to view] > And, you may find some market resistance if you are asking partners to > parse through your XML. But if we sent back a list of information (as opposed to scalar data item or items) in XML format, that's exactly what the consumer would need to do in order to process each row. This is unavoidable for any service which returns a list or array of data. So why would our own hand-coded XML list representation be more convenient than the native DataSet XML representation? Tabular data representation is tabular data representation. What's the difference whose XML format it is encoded in? [quoted text, click to view] > Have you tried strongly-typed datasets? They're nice and RAD, but they at > least define the data via XML Schema. You get to benefit from RAD, your > customers benefit from a strong schema. Excellent suggestion, I will look into this - thanks! [quoted text, click to view] > BTW, I presume you realize that you need to be careful when changing the > structure of the data you're returning? Remember, you're talking to an ex-COM (hey, I like that term - you heard it here first! ;-). Keeping an interface constant (or should I say coMstant?) is second nature to guys like me! At the end of the day, the vast majority of our Web Services are going to be consumed by our own application. In this context, RAD development is of benefit to us. We can always see our way going forward to provide alternate service methods which could be consumed by eventual partners. Even if our own in-house services aren't suitable, having the application engineered on the Web Services platform is going to give us a tremendous boost when it comes to providing services to even non-.NET clients. Thanks for your advice, - Joseph Geretz - [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message
news:eAjicA4VHHA.4260@TK2MSFTNGP06.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:uXpdYs3VHHA.4764@TK2MSFTNGP05.phx.gbl... >> Hi John, >> >>> You should ideally start with the business-level concept, manually >>> create an XML Schema to describe it, manually create a WSDL file which >>> will describe the possible interactions with the service in terms of the >>> schema, and only _then_ go implement a service which may implement these >>> concepts and operations in terms of DataSets. >> >> I hear what you are saying, but I'm wondering why you're saying it in a >> dotnet.framework.webservices forum. The activities you describe, that is >> the hand tuning of the XML schema and the WSDL file are specifically >> those activities which are *not* necessary for .NET developers. We use a >> more RAD approach, basically relying on the IDE to perform this for us >> behind the scenes. > > > Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for > web services. I practiced what I preached on one web service and am about > to do so again on at least one more. This is called contract-first > development. > > >> The application I am currently devleoping would have two target >> audiences. >> >> 1. Our own client application. Our developed solution would be >> implemented end-to-end using Microsoft .NET technologies using the >> aforementioned RAD approach. > > It's not a problem if you want to tie yourself to .NET. That works very > well, until the point when you decide you need to work with something > that's not .NET. > >> 2. Other vendors in our application market space who might want to >> integrate with our application. Web Services would facilitate this type >> of integration. Certain vendors might or might not be on the .NET >> platform themselves. For those who are, terrific for them, they'll be >> able to consume our web services quite naturally with the convenience of >> being able to access tabular data in a very convenient format. Those who >> aren't should still be able to consume our Web Services, however they'll >> have to manually parse through tabular data themselves without the >> convenience of the DataTable/DataSet structure since their environments >> won't provide the convenience of an object representation of the >> DataTable/Set XML. > > > What's wrong with defining your tabular data with a schema, without > relying on a DataSet? > > And, you may find some market resistance if you are asking partners to > parse through your XML. > >>> I don't know of many businesses for which "DataSet" is a business-level >>> concept. >> >> The DataSet/Table isn't a business level concept, however a large amount >> of business level data can be represented quite conveniently in >> DataSet/Table format. With focus on devleopment convenience (RAD) for our >> own application developers, I need a more compelling reason to eschew >> DataSet/Tables than simply the fact that it will disadvantage other non >> .NET consumers of our Web Service. If it will make it impossible for them >> to consume our Web Services, that would be a different matter. But I'm >> not hearing that it would be impossible for them, just marginally more >> inconvenient. >> >> Am I missing anything? > > Have you tried strongly-typed datasets? They're nice and RAD, but they at > least define the data via XML Schema. You get to benefit from RAD, your > customers benefit from a strong schema. > > John > > > BTW, I presume you realize that you need to be careful when changing the > structure of the data you're returning? Once you've published the WSDL, > you shouldn't really be changing the structure of the returned data, at
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:OcR0TV4VHHA.3652@TK2MSFTNGP04.phx.gbl... > Hi John, > >> Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for >> web services. > > I (and some other developers on the team here) don't quite understand what > you are saying. When using Visual Studio 2005 for Web Service application > development, the IDE takes care of all the wire-up necessary in order to > connect the client with the Web Service. This includes creating the WSDL > on the server and creating the proxy class for the client which consumes > the WSDL and presents a strongly typed interface to the client. Seems > pretty RAD to us. Microsoft has sold you a bicycle with training wheels on it. Those wheels are not welded on. Take them off. When Microsoft first introduced .NET, Web Services were a large part of the marketing message. In order to encourage developers to jump onto the Web Services bandwagon, Microsoft did a number of things which I believe were not good ideas in the long run. They introduced a way to create a web service that screen-scrapes HTML, for instance. This is a very bad way to create an application, but makes perfect sense back in 2001, when it was a useful way to get developers to start using .NET. Similarly, they introduced the ability to "magically" create web services simply by putting a [WebMethod] attribute on the public methods to be exposed. "Look how easy it is!", they said. But this is not a best practice, and it leads to many of the mistakes that you and others are making. It is only because of the "magic" going on behind the scenes that newcomers like yourself can actually ask about how to make the client use the same class as the server. The question actually makes no sense at all, but because you're using the training wheels, and thinking that's how bicycles are made, you have the illusion that the two classes should be the same and that there's simply some setting you need to change to make them be the same. I have similarly heard of a developer who, when he couldn't add a web reference via http://somewhere/something.asmx?WSDL complained that the service didn't work, and that there was a connectivity problem. There wasn't. The "documentation" protocol was deliberately disabled. He thought that "?WSDL" was some standard. BTW, the client absolutely does _not_ get a strongly-typed interface! The interface exposed by the server is interpreted by .NET to produce a WSDL file which the client interprets to produce proxy classes unrelated to the original classes. If you want strongly-typed, you should use .NET Remoting, or WCF. The proxy classes are only a convenience. [quoted text, click to view] >> What's wrong with defining your tabular data with a schema, without >> relying on a DataSet? > > There's nothing wrong with it, in general. However consider the context in > particular. The data is retrieved from the database in DataTable format. That is an implementation detail. What happens when your implementation changes? [quoted text, click to view] > At the (our) UI it's going to be bound to a data-bound widget (very > convenient, for us at least) in DataTable format. Again, an implementation detail. Your widget will no doubt like you just as well if you bind it to a custom object exposing strongly-typed properties. Data binding is not unique to DataTables and DataSets. [quoted text, click to view] > Given that this is the case, I'm going to need a compelling reason to > persist this into a secondary XML format, and then to convert it back from > secondary XML format into a DataTable at the UI. And to do this again, > when modified data is sent back to the server. It'll cut down development > expense significantly to just leave this in its native format and to let > the Framework take care of everything for us. Absolutely. And you will be tied to the framework. If that's part of your requirement, then you're all set. Many people developing Web Services are interested in at least the possibility that some client other than .NET will use their service. [quoted text, click to view] >> And, you may find some market resistance if you are asking partners to >> parse through your XML. > > But if we sent back a list of information (as opposed to scalar data item > or items) in XML format, that's exactly what the consumer would need to do > in order to process each row. Absolutely not! Why would they need to do any parsing if you've given them a schema? They'll no doubt do the same thing that you would do - run their equivalent of XSD.EXE to produce classes from the schema! No parsing (manual) required. [quoted text, click to view] >This is unavoidable for any service which returns a list or array of data. >So why would our own hand-coded XML list representation be more convenient >than the native DataSet XML representation? Tabular data representation is >tabular data representation. What's the difference whose XML format it is >encoded in? > >> Have you tried strongly-typed datasets? They're nice and RAD, but they at >> least define the data via XML Schema. You get to benefit from RAD, your >> customers benefit from a strong schema. > > Excellent suggestion, I will look into this - thanks! > >> BTW, I presume you realize that you need to be careful when changing the >> structure of the data you're returning? > > Remember, you're talking to an ex-COM (hey, I like that term - you heard > it here first! ;-). Keeping an interface constant (or should I say > coMstant?) is second nature to guys like me! That's what I thought. I'd just point out to you, that the namespace is somewhat equivalent to the IID - if you change the interface, you need to change the namespace. [quoted text, click to view] > At the end of the day, the vast majority of our Web Services are going to > be consumed by our own application. In this context, RAD development is of > benefit to us. We can always see our way going forward to provide > alternate service methods which could be consumed by eventual partners. > Even if our own in-house services aren't suitable, having the application > engineered on the Web Services platform is going to give us a tremendous > boost when it comes to providing services to even non-.NET clients. Just keep in mind that the web services platform doesn't include the training wheels. In fact, you'll find that the aftermarket assumes you've taken the training wheels off! John
Hi John,
A lot of what you are saying makes sense. It's the same philosophy which has led many of my fellow VB6 developers toward exploration of Windows internals. It's useful to have this knowledge for application when necessary; But by no means have we discarded VB6 in favor of Visual C++ and MFC for Windows application development. [quoted text, click to view] > Microsoft has sold you a bicycle with training wheels on it. Those wheels > are not welded on. Take them off. Basically, what you see as 'training wheels' I (and others I am sure, as well) see as valuable aids toward rapid application development. [quoted text, click to view] > you and others are making. It is only because of the "magic" going on > behind the scenes that newcomers like yourself can actually ask about how > to make the client use the same class as the server. The question actually > makes no sense at all, but because you're using the training wheels, and > thinking that's how bicycles are made, you have the illusion that the two > classes should be the same and that there's simply some setting you need > to change to make them be the same. Although, to be sure I am not averse to 'taking off the training wheels when necessary'. I am assuming that you allude to my advice to Josh in his topic 'Sharing web-service class between two local assemblies'? Please take a look at my latest reply, where I demonstrate that, contrary to your assertion, this is indeed possible with just a bit of simple hand-tuning of the 'magically' generated proxy class. As you can see, I am not averse to 'taking off the training wheels' when necessary. Newcomers like myself? (shrug - whatever...) - Joseph Geretz - [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message
news:upzFbR7VHHA.4260@TK2MSFTNGP06.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:OcR0TV4VHHA.3652@TK2MSFTNGP04.phx.gbl... >> Hi John, >> >>> Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for >>> web services. >> >> I (and some other developers on the team here) don't quite understand >> what you are saying. When using Visual Studio 2005 for Web Service >> application development, the IDE takes care of all the wire-up necessary >> in order to connect the client with the Web Service. This includes >> creating the WSDL on the server and creating the proxy class for the >> client which consumes the WSDL and presents a strongly typed interface to >> the client. Seems pretty RAD to us. > > Microsoft has sold you a bicycle with training wheels on it. Those wheels > are not welded on. Take them off. > > When Microsoft first introduced .NET, Web Services were a large part of > the marketing message. In order to encourage developers to jump onto the > Web Services bandwagon, Microsoft did a number of things which I believe > were not good ideas in the long run. They introduced a way to create a web > service that screen-scrapes HTML, for instance. This is a very bad way to > create an application, but makes perfect sense back in 2001, when it was a > useful way to get developers to start using .NET. > > Similarly, they introduced the ability to "magically" create web services > simply by putting a [WebMethod] attribute on the public methods to be > exposed. "Look how easy it is!", they said. > > But this is not a best practice, and it leads to many of the mistakes that > you and others are making. It is only because of the "magic" going on > behind the scenes that newcomers like yourself can actually ask about how > to make the client use the same class as the server. The question actually > makes no sense at all, but because you're using the training wheels, and > thinking that's how bicycles are made, you have the illusion that the two > classes should be the same and that there's simply some setting you need > to change to make them be the same. > > I have similarly heard of a developer who, when he couldn't add a web > reference via http://somewhere/something.asmx?WSDL complained that the > service didn't work, and that there was a connectivity problem. There > wasn't. The "documentation" protocol was deliberately disabled. He thought > that "?WSDL" was some standard. > > BTW, the client absolutely does _not_ get a strongly-typed interface! The > interface exposed by the server is interpreted by .NET to produce a WSDL > file which the client interprets to produce proxy classes unrelated to the > original classes. If you want strongly-typed, you should use .NET > Remoting, or WCF. The proxy classes are only a convenience. > > >>> What's wrong with defining your tabular data with a schema, without >>> relying on a DataSet? >> >> There's nothing wrong with it, in general. However consider the context >> in particular. The data is retrieved from the database in DataTable >> format. > > That is an implementation detail. What happens when your implementation > changes? > >> At the (our) UI it's going to be bound to a data-bound widget (very >> convenient, for us at least) in DataTable format. > > Again, an implementation detail. Your widget will no doubt like you just > as well if you bind it to a custom object exposing strongly-typed > properties. Data binding is not unique to DataTables and DataSets. > >> Given that this is the case, I'm going to need a compelling reason to >> persist this into a secondary XML format, and then to convert it back >> from secondary XML format into a DataTable at the UI. And to do this >> again, when modified data is sent back to the server. It'll cut down >> development expense significantly to just leave this in its native format >> and to let the Framework take care of everything for us. > > Absolutely. And you will be tied to the framework. If that's part of your > requirement, then you're all set. Many people developing Web Services are > interested in at least the possibility that some client other than .NET > will use their service. > >>> And, you may find some market resistance if you are asking partners to >>> parse through your XML. >> >> But if we sent back a list of information (as opposed to scalar data item >> or items) in XML format, that's exactly what the consumer would need to >> do in order to process each row. > > Absolutely not! Why would they need to do any parsing if you've given them > a schema? They'll no doubt do the same thing that you would do - run their > equivalent of XSD.EXE to produce classes from the schema! No parsing > (manual) required. > >>This is unavoidable for any service which returns a list or array of data. >>So why would our own hand-coded XML list representation be more convenient >>than the native DataSet XML representation? Tabular data representation is >>tabular data representation. What's the difference whose XML format it is >>encoded in? >>
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:%23qlUYhIWHHA.5108@TK2MSFTNGP06.phx.gbl... > Hi John, > > A lot of what you are saying makes sense. It's the same philosophy which > has led many of my fellow VB6 developers toward exploration of Windows > internals. It's useful to have this knowledge for application when > necessary; But by no means have we discarded VB6 in favor of Visual C++ > and MFC for Windows application development. > >> Microsoft has sold you a bicycle with training wheels on it. Those wheels >> are not welded on. Take them off. > > Basically, what you see as 'training wheels' I (and others I am sure, as > well) see as valuable aids toward rapid application development. > >> you and others are making. It is only because of the "magic" going on >> behind the scenes that newcomers like yourself can actually ask about how >> to make the client use the same class as the server. The question >> actually makes no sense at all, but because you're using the training >> wheels, and thinking that's how bicycles are made, you have the illusion >> that the two classes should be the same and that there's simply some >> setting you need to change to make them be the same. > > Although, to be sure I am not averse to 'taking off the training wheels > when necessary'. I am assuming that you allude to my advice to Josh in his > topic > 'Sharing web-service class between two local assemblies'? Please take a > look at my latest reply, where I demonstrate that, contrary to your > assertion, this is indeed possible with just a bit of simple hand-tuning > of the 'magically' generated proxy class. As you can see, I am not averse > to 'taking off the training wheels' when necessary. > > Newcomers like myself? (shrug - whatever...) Joseph, as I replied in that thread, you've just given some very bad advice. The edited proxy class will be destroyed as soon as an Update Web Reference is done, if not before. John
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:%23qlUYhIWHHA.5108@TK2MSFTNGP06.phx.gbl... > Hi John, > Newcomers like myself? (shrug - whatever...) BTW, I meant newcomers to .NET. You obviously have a lot of experience in VB6 and COM, and I'm afraid it's not serving you well. John
[quoted text, click to view]
> The edited proxy class will be destroyed as soon as an Update Web > Reference is done, if not before. And I've responded in place. Of course, this is the obvious caveat. The proposed solution requires direct involvement in the construction of the proxy whenever the proxy is created; that is, during initial reference and any subsequent update of the reference. Implementing this solution requires that one unbolt the 'training wheels'. In general, this is an approach which you favor, no? [quoted text, click to view] > Joseph, as I replied in that thread, you've just given some very bad > advice. What I did was present the facts, not simply make unsubstantiated assertions. I will allow others to choose, depending upon their particular circumstances, whether or not this can be implemented successfully for them. - Joseph Geretz - [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:%23jdLxMOWHHA.1200@TK2MSFTNGP02.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:%23qlUYhIWHHA.5108@TK2MSFTNGP06.phx.gbl... >> Hi John, >> >> A lot of what you are saying makes sense. It's the same philosophy which >> has led many of my fellow VB6 developers toward exploration of Windows >> internals. It's useful to have this knowledge for application when >> necessary; But by no means have we discarded VB6 in favor of Visual C++ >> and MFC for Windows application development. >> >>> Microsoft has sold you a bicycle with training wheels on it. Those >>> wheels are not welded on. Take them off. >> >> Basically, what you see as 'training wheels' I (and others I am sure, as >> well) see as valuable aids toward rapid application development. >> >>> you and others are making. It is only because of the "magic" going on >>> behind the scenes that newcomers like yourself can actually ask about >>> how to make the client use the same class as the server. The question >>> actually makes no sense at all, but because you're using the training >>> wheels, and thinking that's how bicycles are made, you have the illusion >>> that the two classes should be the same and that there's simply some >>> setting you need to change to make them be the same. >> >> Although, to be sure I am not averse to 'taking off the training wheels >> when necessary'. I am assuming that you allude to my advice to Josh in >> his topic >> 'Sharing web-service class between two local assemblies'? Please take a >> look at my latest reply, where I demonstrate that, contrary to your >> assertion, this is indeed possible with just a bit of simple hand-tuning >> of the 'magically' generated proxy class. As you can see, I am not averse >> to 'taking off the training wheels' when necessary. >> >> Newcomers like myself? (shrug - whatever...) > > Joseph, as I replied in that thread, you've just given some very bad > advice. The edited proxy class will be destroyed as soon as an Update Web > Reference is done, if not before. > > John > >
[quoted text, click to view]
> BTW, I meant newcomers to .NET. You obviously have a lot of experience in > VB6 and COM, and I'm afraid it's not serving you well. When faced with a set of inconvenient facts and ideas, the last refuge is always an attempt to discredit their presenter. Thanks John, for demonstrating that for us. - Joseph Geretz - [quoted text, click to view] "John Saunders" <john.saunders at trizetto.com> wrote in message news:OQ7rVNOWHHA.4764@TK2MSFTNGP05.phx.gbl... > "Joseph Geretz" <jgeretz@nospam.com> wrote in message > news:%23qlUYhIWHHA.5108@TK2MSFTNGP06.phx.gbl... >> Hi John, >> Newcomers like myself? (shrug - whatever...) > > > BTW, I meant newcomers to .NET. You obviously have a lot of experience in > VB6 and COM, and I'm afraid it's not serving you well. > > John > >
[quoted text, click to view]
"Joseph Geretz" <jgeretz@nospam.com> wrote in message news:eLzdooPWHHA.4844@TK2MSFTNGP03.phx.gbl... >> BTW, I meant newcomers to .NET. You obviously have a lot of experience in >> VB6 and COM, and I'm afraid it's not serving you well. > > When faced with a set of inconvenient facts and ideas, the last refuge is > always an attempt to discredit their presenter. How is thiis an attempt to discredit you? I just got through praising your experience! I have experience in both sets of technology, and can see from your posts over the past few weeks that you are attempting to apply your experience in COM to the problem at hand. Unfortunately, in my opinion, there is such a huge gap between the world of COM and the modern world, that I believe you'd be better served by ignoring your experience and starting from scratch. I had the benefit of learning .NET back in 2001. The gap between COM and ..NET 1.0 was large, but many resources were focused on bridging that gap. The gap between COM and .NET 2.0 (and 3.0!) is much larger, and Microsoft no longer spends quite as much time bridging the gap. This is why you might be better off jumping the gap, rather than trying to use the bridge. Good luck, in any case. John
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 |