SqlDataSource vs ObjectDataSource

Question

如果网页需要一些数据，为什么不让SQLDataSource调用存储过程呢？为什么要使用ObjectDataSource来调用业务对象，然后再调用存储过程呢？我知道构建在.net框架上的其他应用程序(比如说桌面应用程序)可以访问业务对象，但如果应用程序始终只是一个web应用程序怎么办？

更清楚地说：

什么时候应该使用SqlDataSource或ObjectDataSource

如何激励人们做出这样的选择？

Answer 1

如果它只是一个演示、原型或快速开发，那么拥有一个SQLDataSource是完全有效的。这是快速的，它是简单的，它只是工作，并给你需要的结果。

然而，当一个应用程序是为长期而设计和构建的，并且预计事情(需求、客户意愿，最终是数据库模式)可能会发生变化，那么引入一个适当的“业务”层--将业务对象建模为对象，然后提供从底层数据库到这些业务对象的映射--可能会更有意义。

正如俗语所说--你可以通过多一层间接(或抽象)来解决计算机科学中的几乎任何问题--这里也是如此。

当然:您可以直接访问数据库，当然，在第一次迭代时，这可能是(或可能是)最快的方法。但从长远来看，当一个应用程序被构建为可持续时，它通常是一种quick-and-dirty方式-维护成本，维护成本，根据您和客户的需求进行更改所需的成本和工作量将会增长，而且非常快，就工作量而言，这种快速而肮脏的解决方案看起来不再那么棒了。

所以总结一下我的观点:是的，一开始，使用直接的SQL数据源可能会更快更容易-所以在重要的地方使用它:完成一个快速演示，一个概念验证风格的应用程序。但从长远来看，当你观察一个应用程序的生命周期时，通常值得投入更多的精力(设计和编码)来添加这一抽象层，这样你的网页就不会直接依赖于底层数据库的细节。

Marc

Answer 2

如果您有一个在项目中使用的业务层，那么ObjectDataSource是自然而然的选择。这很适合许多ORM，而且它们中的许多都提供了额外的好处(验证、撤消等)。它还允许您访问业务对象上的任何其他属性和方法-而不仅仅是直接的SQL字段。这在绑定时非常有用-因为它允许您只绑定到标记中的属性，而不必编写大量的代码。

如果你走这条路，混用SQLDataSource和ObjectDataSource可能会导致下一位接手你项目的开发人员的混淆。在这种情况下，为了代码一致性，我坚持使用ObjectDataSource。

如果您没有业务层，只是直接使用SQL -使用SQLDataSource。我个人的偏好是所有的SQL代码都应该放在业务层或数据层，因为我几乎从不使用SQLDataSource。

Answer 3

如果您可以在存储过程中应用您的业务层代码，那么最好使用SQLDataSource