SqlDataSource 与 ObjectDataSource
如果网页需要一些数据，为什么不直接让 SQLDataSource 调用存储过程呢？ 为什么使用 ObjectDataSource 调用业务对象，然后再调用存储过程？ 据我了解，基于 .net 框架构建的其他应用程序（比如说桌面应用程序）可以访问业务对象，但是如果该应用程序始终只是一个 Web 应用程序怎么办？
更清楚地说：
什么时候应该使用 SqlDataSource 或 ObjectDataSource？
如何激发人们做出选择？
If a web page needs some data, why not just have a SQLDataSource call a stored procedure? Why use an ObjectDataSource to call a business object that then calls the stored procedure? I understand that other apps (lets say desktop apps) built on the .net framework can access the business objects, but what if the application will always be only a web app?
To be more clear:
When should one use an SqlDataSource or ObjectDataSource?
How does one motivate the choice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果它只是一个演示、一个原型或一个快速破解，那么只有一个 SQLDataSource 是完全有效的。 它快速、简单、有效并为您提供所需的结果。
然而，当一个应用程序是为长期设计和构建的，并且预计事情（需求、客户愿望、最终数据库模式）可能会发生变化时，那么引入适当的“业务”层可能会更有意义 -将您的业务对象建模为对象，然后提供从底层数据库到这些业务对象的映射。
俗话说——你可以通过多一层间接（或抽象）来解决计算机科学中的几乎所有问题——这同样适用。
当然：您可以直接访问数据库，当然，在第一次和第一次迭代中，这可能是（或可能）最快的方法。 但从长远来看，当一个应用程序被构建为持久时，它通常是一种快速而肮脏的方式 - 维护成本，维护成本，根据需要进行更改所需的成本和精力您和您的客户的需求将会增长，而且速度非常快，就工作量而言，这种快速而肮脏的解决方案看起来不再那么好。
总结一下我的观点：是的，最初，使用直接 SQL 数据源可能会更快、更容易 - 所以在重要的时候使用它：完成快速演示、概念验证样式应用程序的工作。 但从长远来看，当您考虑应用程序的生命周期时，通常值得投入更多（设计和编码）精力来添加这一抽象层，这样您的网页就不会直接依赖于应用程序的细节下面的数据库。
马克
Having just a SQLDataSource is perfectly valid, if it's just a demo, a prototype, or a quick hack. It's fast, it's easy, it just works and gives you the results you need.
However, when an app is designed and built for the long run, and anticipates that things (requirements, customer wishes, eventually the database schema) may change, then it might make a whole lot more sense to introduce a proper "business" layer - model your business objects as objects, and then provide a mapping from the underlying database to those business objects.
As the saying goes - you can solve pretty much anything in computer science by one more layer of indirection (or abstraction) - same holds here.
SURE: you can go straight to the database, and sure, at first and for the first iteration, that's possibly (or probably) the quickest way. But in the long run, when an app is built to last, it's usually a quick-and-dirty way - the cost of upkeep, the cost of maintenance, the cost and effort needed for changing according to your and your customer's needs will grow and quite quickly, that quick'n'dirty solution doesn't look so great anymore, in terms of effort.
So to sum up my point: yes, initially, using a direct SQL Data source might be quicker and easier - so use it when that's the important point: to get things done for a quick demo, a proof-of-concept style app. But in the long run, when you look at the life span of an app, it's usually worthwhile investing a bit more (design and coding) effort to add this layer of abstraction so that your web pages don't directly depend on the details of the database underneath.
Marc
如果您在项目中使用业务层，则 ObjectDataSource 是自然的选择。 这非常适合许多 ORM，并且其中许多提供了额外的好处（验证、撤消等）。 它还允许您访问任何其他属性和信息。 您对业务对象拥有的方法 - 不仅仅是直接的 SQL 字段。 这在绑定时非常方便 - 因为它允许您只绑定到标记中的属性，而不必在后面编写大量代码。
如果您要走这条路，混合 SQLDataSource 和 ObjectDataSource 可能会导致下一个开发人员在接手您的项目时感到困惑。 在本例中，我坚持使用 ObjectDataSource 来保持代码一致性。
如果您没有业务层并且只是直接使用 SQL - 请使用 SQLDataSource。 我个人的偏好是所有 SQL 代码都应该位于业务层或数据层，因为我几乎从不使用 SQLDataSource。
If you have a business layer that you're using in your projects, ObjectDataSource is the natural choice. This fits well with many ORMs, and many of them provide additional benefits (validation, undo, etc). It also lets you access any of the other properties & methods you have on your business objects - not just the direct SQL fields. This can come in real handy when binding - since it allows you to just bind to properties in the markup instead of having to write a lot of code behind.
If you are going this route, mixing SQLDataSource and ObjectDataSource can lead to confusion by the next developer to pick up your project. In this case, I stick with ObjectDataSource for code consistency.
If you don't have a business layer and are just hitting SQL directly - use the SQLDataSource. My personal preference is that all of your SQL code should be in a business or data layer, and because of I almost never use SQLDataSource.
如果你可以在存储过程中应用你的业务层代码
最好使用 SQLDataSource
if you can applay your business layer code in the stored procedure
the its better to use SQLDataSource
理论上objectdatasource更好。 但这一切都取决于对象模型的编写和记录得如何。 我们外包了一家使用自定义代码生成器（他们不会向我们提供）的公司来生成所有层。 事实证明，即使是进行很小的更改（例如添加属性或更改字段类型）也是一场噩梦。 我现在几乎放弃了他们所做的一切，只使用他们编写的存储过程。
我的长期目标是使用商业建模工具和模型从头开始重写应用程序。 代码生成器。 如果您打算使用 objectdatasource，我强烈建议您找到一个包含灵活代码生成器的良好建模工具。
In theory objectdatasource is better. But that all depends on how well the object model is written and documented. We outsourced a company that used a custom code generator (which they would not provide us with) to produce all of the layers. It turned out to be nightmare to make even small changes such as adding a property or changing a field type. I am now scrapping virtually everything they did and just using the stored procedures they wrote.
My long term goal is to re-write the application from the ground up using a commercial modeling tool & code generator. If you are going to use objectdatasource I highly recommend finding a good modeling tool that includes a flexible code generator.