SqlDataSource vs ObjectDataSource

Question

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

更清楚：

一个何时应该使用SqlDataSource或ObjectDataSource？

如何激发选择？

Answer 1

仅仅是一个SQLDataSource是完全有效的，如果它只是一个演示，原型或快速入侵。它很快，很容易，它只是起作用，并为您提供所需的结果。但是，如果长期设计和构建应用程序，并预期事物（需求，客户愿望，最终数据库模式）可能会发生变化，那么引入适当的“业务“层 - 将业务对象建模为对象，然后提供从底层数据库到这些业务对象的映射。正如俗话所说 - 你可以通过一层间接（或抽象）的方式解决计算机科学中的任何问题 - 这里同样适用。

确定：你可以直接进入数据库，当然，首先和第一次迭代，这可能（或可能）是最快的方法。但从长远来看，当应用程序构建成可持续时，它通常是一种快速方式 - 维护成本，维护成本，根据您和您的客户需求进行更改所需的成本和工作量将会迅速增长，就努力而言，快速解决方案看起来不再那么棒。

所以总结一下我的观点：是的，最初，使用直接的SQL数据源可能会更快更容易 - 所以在重要的一点时使用它：为快速演示完成任务，概念样式app。但从长远来看，当您查看应用程序的生命周期时，通常值得投入更多（设计和编码）工作来添加这个抽象层，以便您的网页不直接依赖于底下的数据库。

马克

Answer 2

如果您在项目中使用了业务层，那么ObjectDataSource是自然选择。这很适合许多ORM，并且其中许多提供了额外的好处（验证，撤消等）。它还允许您访问业务对象上的任何其他属性&方法 - 而不仅仅是直接的SQL字段。这可以在绑定时真正实现 - 因为它允许您只绑定标记中的属性，而不必编写大量代码。

如果你要走这条路线，混合SQLDataSource和ObjectDataSource可能会导致下一个开发者混淆你的项目。在这种情况下，我坚持使用ObjectDataSource来实现代码一致性。

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

Answer 3

，如果你能applay业务层的代码在存储过程中 的它能够更好地使用SqlDataSource的

Answer 4

理论上的ObjectDataSource是更好的。但是，这一切都取决于对象模型编写和记录的程度。我们外包了一家使用自定义代码生成器（他们不会提供）的公司来生成所有的图层。事实证明，这是一场噩梦，甚至可以进行一些小改动，例如添加属性或更改字段类型。我现在几乎把他们所做的一切都废除了，只是使用他们编写的存储过程。

我的长期目标是从头开始使用商业建模工具&代码生成器重新编写应用程序。如果您打算使用objectdatasource，我强烈建议您找一个包含灵活代码生成器的优秀建模工具。