如果网页需要一些数据，为什么不让 SQLDataSource 调用存储过程呢？为什么要使用 ObjectDataSource 调用业务对象，然后再调用存储过程？我知道基于 .net 框架构建的其他应用程序（比如说桌面应用程序）可以访问业务对象，但如果该应用程序始终只是一个 Web 应用程序呢？
为了更清楚：
什么时候应该使用SqlDataSource 或ObjectDataSource？
如何激发选择的动机？
【问题讨论】：
标签： .net asp.net objectdatasource sqldatasource
如果您在项目中使用了业务层，那么 ObjectDataSource 是自然的选择。这非常适合许多 ORM，其中许多提供了额外的好处（验证、撤消等）。它还允许您访问业务对象上的任何其他属性和方法——不仅仅是直接的 SQL 字段。这在绑定时非常方便——因为它允许您只绑定到标记中的属性，而不必在后面编写大量代码。
如果您走这条路，混合使用 SQLDataSource 和 ObjectDataSource 可能会导致下一个开发人员接手您的项目时感到困惑。在这种情况下，为了代码的一致性，我坚持使用 ObjectDataSource。
如果您没有业务层并且只是直接使用 SQL，请使用 SQLDataSource。我个人的偏好是你所有的 SQL 代码都应该在业务或数据层中，因为我几乎从不使用 SQLDataSource。
【讨论】：
只有一个 SQLDataSource 是完全有效的，如果它只是一个演示、原型或快速 hack。它快速、简单、有效，并为您提供所需的结果。
但是，如果应用程序是为长期设计和构建的，并且预计事物（需求、客户愿望、最终数据库架构）可能会发生变化，那么引入适当的“业务”可能会更有意义" 层 - 将您的业务对象建模为对象，然后提供从底层数据库到这些业务对象的映射。
俗话说 - 您可以通过多一层间接（或抽象）来解决计算机科学中的几乎所有问题 - 这里也是如此。
当然：您可以直接访问数据库，而且在第一次和第一次迭代中，这可能是（或可能）最快的方式。但从长远来看，当一个应用程序经久耐用时，它通常是一种快速又脏的方式——维护成本、维护成本、更改所需的成本和工作量您和您的客户的需求会增长得非常快，就工作量而言，这种快速的'n'dirty 解决方案看起来不再那么棒了。
总结一下我的观点：是的，最初，使用直接的 SQL 数据源可能会更快、更容易 - 所以当这是重要的一点时使用它：完成任务以进行快速演示、概念验证风格的应用程序。但从长远来看，当您查看应用程序的生命周期时，通常值得投入更多（设计和编码）工作来添加这一抽象层，这样您的网页就不会直接依赖于下面的数据库。
马克
【讨论】：
SELECT * FROM .... 您的代码很可能会在第二个字段添加到数据库表时崩溃。如果您在两者之间有业务层，则情况并非如此。
如果您可以在存储过程中应用您的业务层代码 最好使用 SQLDataSource
【讨论】：
理论上 objectdatasource 更好。但这一切都取决于对象模型的编写和记录的好坏。我们外包了一家公司，该公司使用自定义代码生成器（他们不会向我们提供）来生成所有层。事实证明，即使是很小的更改（例如添加属性或更改字段类型）也是一场噩梦。我现在几乎放弃了他们所做的一切，只使用他们编写的存储过程。
我的长期目标是使用商业建模工具和代码生成器从头开始重新编写应用程序。如果您打算使用 objectdatasource，我强烈建议您找到一个包含灵活代码生成器的良好建模工具。
【讨论】：