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