我一直在开发许多应用程序，并且对使用数据集感到困惑。 到目前为止我不使用数据集，并使用在数据库引擎上运行的查询和过程直接从我的数据库工作到我的应用程序。
但我想知道，什么是好的做法 使用数据集？ 要么 在数据库上工作。
Plz尝试在某些情况下向我提供何时使用数据集以及操作（插入/更新）
我们可以根据数据库设置数据集的读/写锁
答案 0 :(得分：5)
您应该拥抱存储过程，或者让数据库变得愚蠢。这意味着您的数据库中没有任何逻辑，只有CRUD操作。如果你使用哑数据库模型，数据集是不好的。最好使用真实对象，这样就可以为它们添加业务逻辑。这种方法比使用存储过程直接在数据库上运行更复杂，但随着系统的增长，您可以更好地管理复杂性。如果你的大型系统有很多小规则，那么存储过程就很难管理。
答案 1 :(得分：2)
在MVC仅仅是哈克眼中的闪光之前，让DataSet处理排序，多重关系和缓存以及诸如此类的东西都非常方便。
我们真正的开发人员并不关心像数据库上的锁这样的琐事。不，我们有冲突解决策略，通常只是在最近的编辑中加盖。用户友好性？ ＆LT; Pshaw＆gt;。
但是在这些日子里，通过大量的通用收藏，过多的ORM以及对关注点分离的意识，他们真的不再有太多的地方了。可以公平地说，每当我看到DataSet时，我最近都会替换它。并没有错过它。
答案 2 :(得分：1)
根据经验，我会将涉及数据一致性，完整性等的逻辑尽可能地接近该数据 - 即在数据库中。此外，如果我必须以相互依赖的方式获取我的数据（即从表A，B和C中获取，其中A，B和C的贡献之间的关系在请求时是已知的），那么保存是有意义的callout开销并通过数据库对象（如函数，过程）进行一次（如OMGPonies已经指出的那样）。对于删除了一级或两级的逻辑，将其“处理性地”处理它的位置更为直观，例如在数据集中。说了这么多，经验法则有时是他们的首字母缩略词推断...... ROT！
在过去的.Net项目中，我经常在数据库中完成数据导入/转换（例如银行交易数据文件）（一个标注，所有逻辑都封装在过程中并受事务保护），但是已经“解析”了在第二阶段使用相同数据的项目，在我的.net代码中使用数据表等（尽管这些天我很可能会跳过数据集阶段并使用类对象从更高的抽象杠杆处理它们。）
答案 3 :(得分：0)
我已经看到一个应用程序中使用的数据集非常好，但这是在相当多的不同应用程序（至少两位数）的7年开发。
现在有很多最佳实践指出了使用Objects开发的twords而不是企业开发的数据集。对象以及像NHibernate或Entity Framework这样的ORM可以非常强大，并且可以在创建CRUD存储过程时花费大量精力。这是我喜欢开发应用程序的方式，因为我可以在域层中以这种方式很好地分离业务逻辑。
这并不是说数据集没有它们的位置，我相信在某些情况下它们可能比对象更合适但对我来说，在使用它们之前我需要非常确定。
答案 4 :(得分：0)
当我几个月来没有在源代码中使用DataSet时，我也一直在想这个。
实际上，如果您的对象是O / R映射的，并且使用序列化和泛型，那么您将永远不需要DataSet。
但DataSet在生成报告方面非常有用。
这是因为，报告没有可以或应该进行O / R映射的特定结构。
我只将DataSet与报告工具结合使用。