Jos*_*h E 10 .net asp.net data-binding
我知道这是一个可以引起很多争论的主题,但我想知道人们认为使用对象数据源的各种利弊是什么.我现在正在做一个项目,其他程序员的经验和舒适程度都源于经典的ASP,我不确定哪种方式可以
a)快速完成工作b)以最低限度完成工作大惊小怪
我们有一个很好的存储库层,其域对象能够自我验证,因此这些方法可用于执行ODS绑定或代码隐藏绑定.
我出于大多数显而易见的原因不喜欢ODS,但是如果它确实使我不必手动编码分页/排序/选择/插入/更新/删除场景,那么它真的会那么糟糕吗？
And*_*are 11
对象数据源适用于小型项目,但由于您在应用程序的UI层中嵌入数据层信息,因此它们无法很好地扩展.我建议您只将它们用于非常小的应用程序和便笺式测试.如果您做出设计决定使用它们,请准备好在将来解决扩展和维护问题.
DataSourceControls的最大好处是它们抽象出了关于.NET生命周期的几个问题,同时提供对完整CRUD和双向数据绑定表达式的支持,即<%#Bind("FirstName")%>(但是双向数据绑定)有点吮吸所以你可能不会错过任何事情).作为一种设计模式,使用平庸的实现(很像WebForms本身)是一个非常好的主意.
如果您禁用viewstate并发现自己试图弄清楚为什么没有处理回发,或者您最终不得不在几个地方调用DataBind(),那么数据源可以带走一些令人头疼的问题,因为DataBoundControl足够聪明知道他们什么时候需要数据,他们只需要从数据源中获取数据.没有必要的DataBind()调用.
DataSources还提供了处理排序,过滤和分页的好方法.大多数开发人员在使用代码隐藏时,通常不进行分页,而是最终从数据库返回大量结果集.
数据源的缺点是没有很多好的实现.通常你最终会将你的web UI绑定到你的持久性实现(即SqlDataSource,LinqDataSource等),或者最终使用ObjectDataSource,因为它非常有限,需要你将类名和方法名硬编码到ASPX中,使用反射效率有点低.因此,它对使用依赖注入或静态DAO类的人没有用.这是一个非常糟糕的课程,看起来几乎就像是MS的事后想法.
我个人更喜欢使用DataSources和代码隐藏.使用DataSource消除生命周期/视图状态的问题,然后在代码隐藏中为其提供"选择"事件/委托.不幸的是,ObjectDataSource只能使用反射,但是您可以轻松编写自己的实现.我有自己的一个,但它不公开.然而在我写它之前我使用了它,这弥补了ObjectDataSource的一些不足之处:
http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html