webservices_从WebServices返回数据集是Satan的产物，它代表了世界上真正邪恶的一切...-优快云博客

webservices

(Nah, I don't really believe that, but it's a good title, no? DataSets have there place, just not as publically visible Business Objects or from publically accessible WebServices.)

(不，我真的不相信，但这是一个好标题，不？数据集在那里，只是不像公共可见的Business Objects或公共可访问的WebServices。)

Barry Gervin commented on my "quick bash at DataSets" and that I didn't explain my reasonining. In his post, Barry commented on Harry Pierson's statement that one shouldn't use DataSets in a Web Service because they aren't compatible with non .NET Platforms. Barry says, "This isn't true. A DataSet is just XML." Well, of course it's XML, but if I say, hey take this sentence, it's in the ASCII character set (who care's if it isn't English) Le "DataSet" n'est pas votre ami si vous faites des Services de Web. Well, Barry can understand that, but I no hablo French. ;)

巴里·格文(Barry Gervin)对我的“对DataSet的快速抨击”发表了评论，并且我没有解释我的推理。在他的帖子中，Barry评论了Harry Pierson的声明，即不应在Web Service中使用DataSet，因为它们与非.NET平台不兼容。 Barry说：“事实并非如此。DataSet只是XML。” 好吧，当然是XML，但是如果我说，这句话，是在ASCII字符集中(如果不是英语，请注意) “数据集”非常有用，而且服务于Web 。 好吧，Barry可以理解，但是我没有法语。 ;)

DataSets are bowls, not fruit. Do you really want to return bowls?

数据集是碗，而不是水果。 您真的要归还碗吗？

A DataSet is an object, right? But it's not a Domain Object, it's not an "Apple" or "Orange" - it's an object of type "DataSet." A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It's an object that knows a LOT about the Database. But I don't want to return bowls. I want to return Domain Objects, like "Apples."

数据集是一个对象，对不对？但这不是域对象，不是“ Apple”或“ Orange”-它是“ DataSet”类型的对象。 DataSet是一个碗(知道后备数据存储的碗)。数据集是一个知道如何保留行和列的对象。这是一个了解很多有关数据库的对象。但是我不想归还碗。我想返回域对象，例如“苹果”。

"Use Strongly Typed DataSets," you say. "They are the same as Objects, and look how intellisquish works now!"

您说：“使用强类型数据集。” “它们与对象相同，现在看看智能化是如何工作的！”

No, they still aren't Domain Objects, a Strongly Typed DataSet is just a bowl with a picture of an Apple on it. "Look there's an Apple INSIDE - we've broken it down into columns!" DataSets are a shoddy replacement for a good Domain Model (and that includes Strongly Typed DataSets).

不，它们仍然不是域对象，强类型数据集只是上面有苹果图片的碗。 “看里面有一个Apple INSIDE-我们把它分成几列！” 数据集是好的域模型(包括强类型数据集)的伪劣替代品。

Barry has a very good argument for the use of DataSets on his site, and I won't go through his list agreeing and disagreeing with various points. I will say this, however, it seems that his arguments support the use of DataSets in a Data Access Layer - not in a Business Object Layer. THAT I would support. Additionally I understand the usefulness of DataSets in a classic (intranet) Client-Server WinForms app with lots of DataBinding.

Barry对于在他的网站上使用DataSet有一个很好的论据，我不会遍历他的列表来同意和反对不同的观点。但是，我要说的是，似乎他的论点支持在数据访问层中而不是在业务对象层中使用数据集。我会支持的。此外，我了解具有大量数据绑定的经典(内部网)客户端-服务器WinForms应用程序中数据集的有用性。

Returning DataSets from a publically accessible Web Service is a BAD IDEA^©.

从公共可访问的Web服务返回数据集是BAD IDEA ^© 。

Now, why shouldn't we return DataSets from WebServices? DataSets and their serialized XML format includes a pile of information that has little to do with the Domain Model itself. DataSets may be DiffGrams, they may or may not include schema, and they represent "Sets of Data." They are an object of one type, DataSet. Whether there is a Java version of a DataSet object available doesn't matter. They are late-bound by nature, as even a Strongly Typed DataSet encapsulates conversion of types back and forth from SqlDataTypes to typical CLR types and calls to Rows["Apple"]. DataSets are the Class equivalent of an Variant - an Object that can be any kind of Object - only serializable as XML. Returning an object of type DataSet or Typed DataSet via publically accessible Web Service would succeed only in confusing a Java person, stymying any chance of interop, and giving them more ammo to use against .NET.

现在，为什么我们不应该从WebServices返回数据集？数据集及其序列化的XML格式包含大量与域模型本身无关的信息。数据集可以是DiffGrams，它们可以包含也可以不包含架构，它们表示“数据集”。它们是一种类型的对象，即DataSet。是否有可用的DataSet对象的Java版本无关紧要。它们本质上是晚绑定的，因为即使是强类型数据集也封装了从SqlDataTypes到典型CLR类型的来回类型转换以及对Rows [“ Apple”]的调用。 数据集是Variant的类等效项，Variant是一个可以是任何对象的对象，只能序列化为XML。 通过公共可访问的Web Service返回DataSet或Typed DataSet类型的对象只会成功地使Java人员感到困惑，阻碍任何互操作的机会，并使他们有更多的弹药来对抗.NET。

To be clear, I WOULD architect a system that included DataSets if I felt that they provided an exceptional value. I'm just promoting that folks BE AWARE of the ramifications of their decisions.

需要明确的是，如果我觉得包含数据集的系统具有非凡的价值，我将设计一个包含数据集的系统。我只是在鼓励人们注意他们的决定的后果。

Tagential aside: There's some yummy best practices up on TheServerSide.NET. Here's my favorites:

除了潜在的可能性： TheServerSide.NET上还有一些很好的最佳实践。这是我的最爱：

Using a DataReader vs. a DataSet: The DataReader was of course faster. It was faster by 16% in this particular case.
使用DataReader与DataSet： DataReader当然更快。在此特定情况下，速度提高了16％。
SQLDataReader vs. OleDBDataReader: Going with native drivers is always better. The SQLDataReader was 115% faster than going through OLE.
SQLDataReader与OleDBDataReader：使用本机驱动程序总是更好。 SQLDataReader比通过OLE快115％。
DataReader Column Reference - By Name, Ordinal, or GetString(): The order of speed? dr[0] was the fastest, followed by dr["ProductName"], followed by dr.GetString(0) as it has to do the conversion.
DataReader列参考-按名称，顺序或GetString()：速度的顺序？ dr [0]是最快的，其次是dr [“ ProductName”]，其次是dr.GetString(0)，因为它必须执行转换。
Inline (DataReader) vs. Controls (DataGrid): The inline script was 233% faster than a DataGrid component.
内联(DataReader)与控件(DataGrid)：内联脚本比DataGrid组件快233％。

翻译自: https://www.hanselman.com/blog/returning-datasets-from-webservices-is-the-spawn-of-satan-and-represents-all-that-is-truly-evil-in-the-world

webservices