虽然有许多人对ADO.NET优化表示怀疑，但在年复一年的不断发展中，他的安全性也在不断提高。保障ADO.NET优化的安全性是完全有可能的，但前提是要深入理解到底什么是ADO.NET优化，及他是怎么运作的 

避免自动增加（Auto-Increment）值冲突 

和许多数据源一样，DataSet允许你在添加新行时识别自动增加值的列。ADO.NET优化在DataSet中使用自动增加列时，由于数据源也有自动增加列，需要避免添加到DataSet中的本地行号与添加到数据源中的行之间的冲突。 

例如，假设一个表的自动增加主键列是CustomerID。两个新客户信息添加到该表，获得的自动增加CustomerID值分别是1和2。ADO.NET优化接着只有第二个客户行给数据适配器传递的Update方法，在数据源中新添加的行接受的自动增加CustomerID值是1，与数据集中的2不匹配。当数据适配器用返回值填充表中的第二行时，ADO.NET优化由于第一个顾客行的CustomerID是1，便出现了错误。 

为了避免这种情况，我们推荐当使用数据源和数据集中有自动增加列时，数据集中的该列的AutoIncrementStep设为－1，AutoIncrementSeed设为0，同时确保数据源中生成的自动增加标识值从1开始，步长为正。结果是数据集生成负的自动增加值，不会与数据源产生的正自动增加值冲突。ADO.NET优化另一种选择是使用Guid类型的列带有自动增加列，该算法产生的Guid值在数据集和数据源中永远不同。 

如果你的自动增加列永远简单的作为唯一值，ADO.NET优化没有其它的意义，考虑使用Guid代替自动增加列。它们是唯一的，避免了做另外的工作处理自动增加列。 

查找优化的并发性故障 

因为DataSet被设计为从数据源断开，所有必须确保当多个客户端更新数据源的数据时应用程序避免冲突。  测试优化并发性错误有多种技术。一种是在表的列中包含时间戳。另一种技术是通过使用SQL语句中的WHERE条件检测来验证行中所有的源列值与数据库中的匹配。#t# 

多线程编程 

ADO.NET优化是为了提高性能、吞吐量和可伸缩性。结果是ADO.NET不锁定资源并且只能在单个线程中使用，其中一个例外是DataSet，它对多个阅读程序来说是线程安全安的。但是在写的时候必须锁定DataSet。  只在必要的时候使用COM交互操作（Interop）访问ADO 

ADO.NET被设计成大量应用程序的最佳解决方案。但是，有些应用程序需要只能使用ADO对象。在这些情况下，应用程序能使用COM交互操作访问ADO。注意使用COM交互操作访问ADO的数据将极大的降低性能。设计应用程序时，在实现使用COM交互操作访问ADO这种设计前首选决定ADO.NET是否符合设计需要。