W
wangming_
Unregistered / Unconfirmed
GUEST, unregistred user!
我用MIDAS技术有6年之久，现在转向ADO.NET技术。
对照来看，他们如出一辙，都是中间层和客户端采取数据集打包发送的方式进行交互，也就是MSDN上所论述的用DataSet来实现Data Transfer Object。
下面是从MSDN的摘录：
{
下面列出了使用 DataSet 作为数据传输对象的优缺点：
优点
•
开发工具支持。DataSet 类是在 ADO.NET 中实现的，因此，无需设计和实现数据传输对象。Microsoft Visual Studio? 版本 6.0 开发系统中的扩展支持也可以用于自动创建 DataSet 对象和填入数据。
•
与控件集成。DataSet 直接与 Windows 窗体和 Web 窗体中的内置控件协作，这使得它成为理想的数据传输对象选择。
•
序列化。DataSet 能够将自身序列化为 XML。它不但可以对内容进行序列化，还能在序列化中表现内容的架构。
•
断开连接的数据库模型。DataSet 是数据库当前内容的快照。这意味着，您可以更改 DataSet 的内容，并且随后使用 DataSet 作为更新数据库的手段。
缺点
•
互操作性。由于 DataSet 类是 ADO.NET 的一部分，因此，在需要与不运行 .NET Framework 的客户端进行互操作的情况下，它不是数据传输对象的最佳选择。不过，您仍然可以使用 DataSet，这时，客户端将被强制分析 XML 语法，并构建它自己的表现形式。如果必须具有互操作性，请参阅“在 .NET 中使用序列化对象实现 Data Transfer Object”。
•
过期数据。前面已经说明，DataSet 与数据库的连接是断开的。构造它时，会将数据库中数据的快照填入其中。这意味着，数据库中的实际数据可能与 DataSet 中包含的数据不同。如果主要是为了读取静态数据，这就不是重要的问题。不过，如果数据经常发生更改，建议不要使用 DataSet。
•
对数据库架构的依赖性。由于大多数时候 DataSet 需要填入数据库数据，因此任何引用列名的代码都会依赖于数据库架构。另外，因为程序员必须对表之间的关系进行显式编码，所以，如果数据库中的关系发生更改，也必须对代码进行修改。
•
性能可能降低。对 DataSet 进行实例化和填入数据需要占用大量资源。对 DataSet 进行序列化和反序列化也会非常费时。关于使用 DataSet 的一条经验法则是，当使用一个以上的表或依靠 DataSet 的能力来更新数据库时，DataSet 是一个很好的选择。如果只需要显示来自单个表的结果，并且不需要 DataSet 所提供的功能，则可以考虑使用 DataReader 来加载强类型对象，这样可以获得更好的性能。
•
非类型安全。您从 DataSet 收到的值可能必须被转换为正确的数据类型。这就要求您判断应该有哪些类型。这个过程可能比较冗长，并且容易产生错误，因为您必须显式检查 DataSet 的类型信息。正如“使用类型化 DataSet”[Microsoft02] 部分所描述的那样，类型化的 DataSet 可以生成从一般 DataSet 类继承来的强类型 DataSet 子类，从而缓解了这个问题。
•
扩展二级体系结构。使用 DataSet 所带来的方便可能会成为缺点，因为开发人员更愿意直接从数据库将 DataSets 传递到用户界面。这样会使用户界面与物理数据库架构紧密地联系在一起。许多机制都有助于避免这个问题。例如，可以从存储过程向 DataSet 填入数据，以便将 DataSet 结构从物理数据库架构中抽象出来。另外，也可以从 XML 文档（可以使用可扩展样式表语言 (XSL) 进行转换）加载 DataSets。这种方式在用户界面、业务逻辑和数据存储之间提供了另一层间接关系。
}
上述ADO.NET基于多层开发的优缺点同样适用于MIDAS，而这些缺点也都可以在封装这些技术的基础之上嵌入自己的处理方法来克服掉。如此，可以达到通用性的目的，即一个通用的持久层引擎，以尽可能少的开发量达到快速完成项目的目的。
但还有其他的技术来实现分布式开发。比如，手工或者用工具来创建N个类，用传输对象的方式进行信息交互，比如ORM在分布式开发上的应用。但其缺点也是显而易见的，如MSDN上的论述：
{
缺点
•
可能需要太多的类。如果选择了使用强类型的 DTO，则可能必须为每个远程方法创建一个（如果考虑返回值，则为两个）DTO。即使在粗粒度接口中，这也可能导致大量的类。编写如此数量的类的代码并管理这些类会是很困难的。使用自动代码生成可以在一定程度上缓解此问题。
•
增加计算量。如果将服务器上的一种数据格式转换为可以跨网络传输的字节流，并在客户端应用程序内转换回对象格式，可以带来相当大的开销。通常，需要将来自多个源的数据聚合到服务器上的单个 DTO 中。要提高通过网络进行远程调用的效率，必须在任一端执行其他计算，才能聚合和串行化信息。
•
增加编码工作量。可以用一行代码完成将参数传递到方法的操作。使用 DTO 要求实例化新对象，并为每个参数调用 setters 和 getters。编写此代码可能是很乏味的。
}
如题，大家在实际开发当中，又是采用什么DTO技术呢？
对照来看，他们如出一辙，都是中间层和客户端采取数据集打包发送的方式进行交互，也就是MSDN上所论述的用DataSet来实现Data Transfer Object。
下面是从MSDN的摘录：
{
下面列出了使用 DataSet 作为数据传输对象的优缺点：
优点
•
开发工具支持。DataSet 类是在 ADO.NET 中实现的，因此，无需设计和实现数据传输对象。Microsoft Visual Studio? 版本 6.0 开发系统中的扩展支持也可以用于自动创建 DataSet 对象和填入数据。
•
与控件集成。DataSet 直接与 Windows 窗体和 Web 窗体中的内置控件协作，这使得它成为理想的数据传输对象选择。
•
序列化。DataSet 能够将自身序列化为 XML。它不但可以对内容进行序列化，还能在序列化中表现内容的架构。
•
断开连接的数据库模型。DataSet 是数据库当前内容的快照。这意味着，您可以更改 DataSet 的内容，并且随后使用 DataSet 作为更新数据库的手段。
缺点
•
互操作性。由于 DataSet 类是 ADO.NET 的一部分，因此，在需要与不运行 .NET Framework 的客户端进行互操作的情况下，它不是数据传输对象的最佳选择。不过，您仍然可以使用 DataSet，这时，客户端将被强制分析 XML 语法，并构建它自己的表现形式。如果必须具有互操作性，请参阅“在 .NET 中使用序列化对象实现 Data Transfer Object”。
•
过期数据。前面已经说明，DataSet 与数据库的连接是断开的。构造它时，会将数据库中数据的快照填入其中。这意味着，数据库中的实际数据可能与 DataSet 中包含的数据不同。如果主要是为了读取静态数据，这就不是重要的问题。不过，如果数据经常发生更改，建议不要使用 DataSet。
•
对数据库架构的依赖性。由于大多数时候 DataSet 需要填入数据库数据，因此任何引用列名的代码都会依赖于数据库架构。另外，因为程序员必须对表之间的关系进行显式编码，所以，如果数据库中的关系发生更改，也必须对代码进行修改。
•
性能可能降低。对 DataSet 进行实例化和填入数据需要占用大量资源。对 DataSet 进行序列化和反序列化也会非常费时。关于使用 DataSet 的一条经验法则是，当使用一个以上的表或依靠 DataSet 的能力来更新数据库时，DataSet 是一个很好的选择。如果只需要显示来自单个表的结果，并且不需要 DataSet 所提供的功能，则可以考虑使用 DataReader 来加载强类型对象，这样可以获得更好的性能。
•
非类型安全。您从 DataSet 收到的值可能必须被转换为正确的数据类型。这就要求您判断应该有哪些类型。这个过程可能比较冗长，并且容易产生错误，因为您必须显式检查 DataSet 的类型信息。正如“使用类型化 DataSet”[Microsoft02] 部分所描述的那样，类型化的 DataSet 可以生成从一般 DataSet 类继承来的强类型 DataSet 子类，从而缓解了这个问题。
•
扩展二级体系结构。使用 DataSet 所带来的方便可能会成为缺点，因为开发人员更愿意直接从数据库将 DataSets 传递到用户界面。这样会使用户界面与物理数据库架构紧密地联系在一起。许多机制都有助于避免这个问题。例如，可以从存储过程向 DataSet 填入数据，以便将 DataSet 结构从物理数据库架构中抽象出来。另外，也可以从 XML 文档（可以使用可扩展样式表语言 (XSL) 进行转换）加载 DataSets。这种方式在用户界面、业务逻辑和数据存储之间提供了另一层间接关系。
}
上述ADO.NET基于多层开发的优缺点同样适用于MIDAS，而这些缺点也都可以在封装这些技术的基础之上嵌入自己的处理方法来克服掉。如此，可以达到通用性的目的，即一个通用的持久层引擎，以尽可能少的开发量达到快速完成项目的目的。
但还有其他的技术来实现分布式开发。比如，手工或者用工具来创建N个类，用传输对象的方式进行信息交互，比如ORM在分布式开发上的应用。但其缺点也是显而易见的，如MSDN上的论述：
{
缺点
•
可能需要太多的类。如果选择了使用强类型的 DTO，则可能必须为每个远程方法创建一个（如果考虑返回值，则为两个）DTO。即使在粗粒度接口中，这也可能导致大量的类。编写如此数量的类的代码并管理这些类会是很困难的。使用自动代码生成可以在一定程度上缓解此问题。
•
增加计算量。如果将服务器上的一种数据格式转换为可以跨网络传输的字节流，并在客户端应用程序内转换回对象格式，可以带来相当大的开销。通常，需要将来自多个源的数据聚合到服务器上的单个 DTO 中。要提高通过网络进行远程调用的效率，必须在任一端执行其他计算，才能聚合和串行化信息。
•
增加编码工作量。可以用一行代码完成将参数传递到方法的操作。使用 DTO 要求实例化新对象，并为每个参数调用 setters 和 getters。编写此代码可能是很乏味的。
}
如题，大家在实际开发当中，又是采用什么DTO技术呢？
