SqlDataSource与ObjectDataSource

Question

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

更清楚：

什么时候应该使用 SqlDataSource 或 ObjectDataSource ？

如何激励选择？

Answer 1

只有一个SQLDataSource是完全有效的，如果它只是一个演示，原型或快速黑客。它很快，很简单，它只是工作，并为您提供所需的结果。

然而，当应用程序从长远来看被设计和构建，并且预期事物（需求，客户希望，最终数据库模式）可能会发生变化时，那么引入正确的应用程序可能会更有意义。商业＆QUOT; layer - 将业务对象建模为对象，然后提供从底层数据库到这些业务对象的映射。

俗话说 - 你可以通过一层间接（或抽象）来解决计算机科学中的任何问题 - 这里也是如此。

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

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

马克

Answer 2

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

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

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

Answer 3

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

Answer 4

理论上，objectdatasource更好。但这完全取决于对象模型的编写和记录情况。我们外包了一家公司，该公司使用自定义代码生成器（他们不会提供给我们）来生成所有层。事实证明，即使是添加属性或更改字段类型等微小更改也是一场噩梦。我现在正在废弃他们所做的一切，只是使用他们编写的存储过程。

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