DataSets in Web services are a product of the devil and all the world's evil
(No, in fact, I don’t believe in it, but it’s a good title, isn’t it? DataSets have a right to exist, but not as external business objects or Web services contracts).
Barry Gervin (Barry Gervin) commented on my "hitting the DataSets" and that I did not explain my point of view. In his post, Barry commented on Harry Pierson’s statement that you cannot use DataSets in Web services because they are incompatible with platforms other than .NET. To this, Barry replied: “This is not true. DataSet is just XML. ”Well, of course, this is XML, but with the same success I can say that any sentence is a set of ASCII characters and everyone should understand: Le" DataSet "n'est pas votre ami si vous faites des Services de Web. Well, maybe Barry will be able to understand, but personally I am not a connoisseur of French. ;)
DataSets are a fruit bowl, but not the fruit itself. Do you really want to get a vase instead of fruit?
A DataSet is an object, isn't it? But this is not a Domain object, this is not an “apple” or “orange” - it is an object of the “DataSet” type. A DataSet is a vase (which knows what lies in it). A DataSet is an object that knows how to store columns and lines . This is an object that knows a lot about the database . But I do not want to get a vase. I want to get Domain-objects, such as "apples".
“Use typed DataSets,” you say. “This is the same as the objects and look - it will somehow work!”
')
No! Typed DataSets are not Domain objects. Typed DataSets are just a vase with a picture of an apple on it. “Look, here is an INSIDE apple - we broke it up into columns!” DataSets (including typed ones) are a very bad replacement for a good domain model.
Barry made very good arguments for DataSets on his site, but I will not analyze them all now on the subject of whether I agree with each of these points or not. I just note that all these arguments are true for DataSets in the Data Access Layer, but not in the Business Object Layer. In addition, I understand the utility of DataSets in the classic (Intranet) client-server WinForms application, with a large number of DataBindings.
Returning DataSets as public Web services results is POOR.
So why don't we get the DataSet back from the web service? DataSets, as well as their XML serialization, include a bunch of information that has very little relevance to the domain model. DataSets can be deltas (DiffGrams), they may or may not include a data schema. In any case, they represent a "data set". These are always objects of the same type - DataSet. But there are many programming languages (the same Java, for example) that do not support this type of data. DataSets by their nature are late-bound objects. Even typed DataSets constantly convert value types between SqlDataTypes and regular CLR types when calling Rows [“Apple”]. DataSets are a class equivalent to a Variant class, whose objects can be of any type and serializable to XML. Returning DataSet type objects in a public Web service is likely to discourage and confound a Java programmer and give him an extra argument against .NET.
To be completely honest, I would develop a system where the DataSets would have a place, only if I was sure of their exceptional value for my architecture. In short, guys, always report on the consequences of your decisions.
This is my first translation, made primarily for “improving my English skills,” so I’m happy to accept all the critical comments on the quality of translation. Some things did not translate literally, but I hope the essence is conveyed correctly.
Personally, I myself do not fully share the opinion of the author, so it would be interesting to hear the opinions of others on this topic.
Barry Gervin (Barry Gervin) commented on my "hitting the DataSets" and that I did not explain my point of view. In his post, Barry commented on Harry Pierson’s statement that you cannot use DataSets in Web services because they are incompatible with platforms other than .NET. To this, Barry replied: “This is not true. DataSet is just XML. ”Well, of course, this is XML, but with the same success I can say that any sentence is a set of ASCII characters and everyone should understand: Le" DataSet "n'est pas votre ami si vous faites des Services de Web. Well, maybe Barry will be able to understand, but personally I am not a connoisseur of French. ;)
DataSets are a fruit bowl, but not the fruit itself. Do you really want to get a vase instead of fruit?
A DataSet is an object, isn't it? But this is not a Domain object, this is not an “apple” or “orange” - it is an object of the “DataSet” type. A DataSet is a vase (which knows what lies in it). A DataSet is an object that knows how to store columns and lines . This is an object that knows a lot about the database . But I do not want to get a vase. I want to get Domain-objects, such as "apples".
“Use typed DataSets,” you say. “This is the same as the objects and look - it will somehow work!”
')
No! Typed DataSets are not Domain objects. Typed DataSets are just a vase with a picture of an apple on it. “Look, here is an INSIDE apple - we broke it up into columns!” DataSets (including typed ones) are a very bad replacement for a good domain model.
Barry made very good arguments for DataSets on his site, but I will not analyze them all now on the subject of whether I agree with each of these points or not. I just note that all these arguments are true for DataSets in the Data Access Layer, but not in the Business Object Layer. In addition, I understand the utility of DataSets in the classic (Intranet) client-server WinForms application, with a large number of DataBindings.
Returning DataSets as public Web services results is POOR.
So why don't we get the DataSet back from the web service? DataSets, as well as their XML serialization, include a bunch of information that has very little relevance to the domain model. DataSets can be deltas (DiffGrams), they may or may not include a data schema. In any case, they represent a "data set". These are always objects of the same type - DataSet. But there are many programming languages (the same Java, for example) that do not support this type of data. DataSets by their nature are late-bound objects. Even typed DataSets constantly convert value types between SqlDataTypes and regular CLR types when calling Rows [“Apple”]. DataSets are a class equivalent to a Variant class, whose objects can be of any type and serializable to XML. Returning DataSet type objects in a public Web service is likely to discourage and confound a Java programmer and give him an extra argument against .NET.
To be completely honest, I would develop a system where the DataSets would have a place, only if I was sure of their exceptional value for my architecture. In short, guys, always report on the consequences of your decisions.
This is my first translation, made primarily for “improving my English skills,” so I’m happy to accept all the critical comments on the quality of translation. Some things did not translate literally, but I hope the essence is conveyed correctly.
Personally, I myself do not fully share the opinion of the author, so it would be interesting to hear the opinions of others on this topic.
Source: https://habr.com/ru/post/148637/
All Articles