引用 Andrew Hare 在 这个问题。
对象数据源适合小型企业
项目，但它们无法很好地扩展
你正在嵌入数据层
您的 UI 层中的信息
应用。我建议你
仅将它们用于非常小的情况
应用程序和暂存器测试
东西。如果您做出设计决定
使用它们时要做好斗争的准备
具有扩展和维护问题
未来。
应用架构=可维护性+可扩展性+……
我认为，我读过的每一篇开始学习应用架构的文章都使用了一些类来构建业务数据层，并使用ObjectDataSource来构建业务数据层。连接表示层和业务层。
看来我全都错了。用于业务层及其与表示层的连接的最佳方法是什么？
Quoting the answer of Andrew Hare on the This Question.
Object data sources are nice for small
projects but they do not scale well as
you are embedding data-layer
information in the UI layer of your
application. I would suggest that you
only use them for very small
applications and scratch-pad testing
stuff. If you make a design decision
to use them be prepared to struggle
with scaling and maintenance issues in
the future.
Application Architecture = Maintainability + Scalability + ......
And I think, every article that I've read to start learning application architecture used some classes to build up the business data layer and used ObjectDataSource to connect the presentation layer with the business layer.
Looks like I've got all wrong. What's really the best approach to use for the business layer and its connection with the presentation layer?
发布评论
评论（2）
毫无疑问，ObjectDataSource 使绑定过程变得更加容易。
它可以轻松处理过滤、分页等操作。
需要考虑的要点。
业务对象因此限制了一些
诸如重构之类的任务
应用程序变得越来越大。
现在的应用程序使用 IoC 和 ODS
不支持这一点。
参数和if过滤条件
增加我们必须增加数量。的
业务中的参数是
也不可取。
因此，如果我们考虑所有这些点，ODS 就无法很好地扩展。
There is no doubt that ObjectDataSource makes the binding process easier.
It handles filtering, paging etc..with less headache.
Points to be considered.
Business object so it restricts some
of the tasks like Refactoring while
the application grows bigger.
application nowadays use IoC and ODS
does not support that.
parameters and if filter conditions
increase we have to increase no. of
parameters in the Business which is
also not desirable.
So if we consider all these points ODS does not scale well.
我不使用 ObjectDataSource；就我个人而言，我喜欢对绑定过程进行控制，因此我直接通过DataSource属性进行绑定，而不使用DS控件。因为 DS 控制何时绑定或不绑定，所以我不喜欢利用事件来取消绑定，只是因为我不想在那个特定时间执行此操作...它可以掩盖某些类型的编码错误，从而使调试变得更加困难，但如果出现错误，我相信您可以点击选定、插入等事件并处理错误。
但是，我不明白为什么它是错误的；我不太确定为什么它不能很好地扩展......如果它适合你，并且当你测试性能正常时，那么我会说为什么不呢。
HTH。
I don't use the ObjectDataSource; personally, I like the control over the binding process, so I bind directly through the DataSource property, and not use the DS controls. Because the DS controls when to bind or not bind, I dislike tapping into events to cancel binding only because I didn't want to do it at that specific time... It can mask some types of coding blunders, making it harder to debug, but if there is an error, you can tap into the selected, inserted, etc. event and handle the error, I believe.
However, I don't see why its wrong; I am not quite sure why it wouldn't scale well... if it works for you, and when you test the performance is OK, then why not I would say.
HTH.