SqlDataSource与ObjectDataSource

Dum*_*ner 16 .net asp.net objectdatasource sqldatasource

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

更清楚:

什么时候应该使用SqlDataSourceObjectDataSource

如何激励选择?

mar*_*c_s 23

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

但是,当应用程序从长远来看被设计和构建,并预期事物(需求,客户希望,最终数据库架构)可能会发生变化时,那么引入适当的"业务"层可能会更有意义 - 将业务对象建模为对象,然后提供从底层数据库到这些业务对象的映射.

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

确定:你可以直接进入数据库,并且首先确保第一次迭代,这可能(或可能)是最快捷的方式.但从长远来看,当应用程序构建持久时,通常是一种快速而肮脏的方式 - 维护成本,维护成本,根据您和您的客户需求进行更改所需的成本和工作量将会增长并且很快,就努力而言,那个快速的解决方案看起来不再那么好了.

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

  • 优点是:如果您的数据库发生更改,但您的业务对象保持不变,则UI仍然有效.如果您直接使用SqlDataSource,并且像许多人一样,使用`SELECT*FROM ....`您的代码很可能会崩溃第二个字段被添加到数据库表中.如果您之间有业务层,则不会出现这种情况. (5认同)
  • 而且,通过将数据打包到业务对象中,可以更轻松地使用它们。例如,您有一个“ Customer”对象,可以读取和写入“ CustomerID”,“ Name”等属性,而不必处理复杂的数据库行和字段,而不必每次都进行转换您访问一些数据。 (2认同)