对象数据源或代码隐藏:哪个更好?

时间:2009-05-19 13:38:26

标签: .net asp.net data-binding

我知道这是一个可以引起很多争论的主题,但我想知道人们认为使用对象数据源的各种利弊是什么。我现在正在做一个项目,其他程序员的经验和舒适程度都源于经典的ASP,我不确定将采用哪种方式 a)快速完成工作 b)以最小的麻烦完成工作

我们有一个很好的存储库层,其域对象能够自我验证,因此这些方法可用于执行ODS绑定或代码隐藏绑定。

我出于大多数显而易见的原因而不喜欢ODS,但如果它确实使我不必手动编码分页/排序/选择/插入/更新/删除方案,那么它真的会那么糟糕吗?

7 个答案:

答案 0 :(得分:11)

对象数据源适用于小型项目,但由于您在应用程序的UI层中嵌入数据层信息,因此它们无法很好地扩展。我建议您只将它们用于非常小的应用程序和便笺式测试。如果您做出设计决定使用它们,请准备好在将来解决扩展和维护问题。

答案 1 :(得分:7)

DataSourceControls的最大好处是它们消除了对.NET生命周期的一些担忧,同时提供对完整CRUD和双向数据绑定表达式的支持,即<%#Bind(“FirstName”)%> (但是双向数据绑定确实有点糟糕,所以你可能不会错过任何东西)。作为一种设计模式,使用平庸的实现(很像WebForms本身)是一个非常好的主意。

如果你禁用了viewstate并发现自己试图弄清楚你的回发没有被处理的原因,或者你最终不得不在几个地方调用DataBind(),那么数据源可以带走一些令人头疼的问题,因为DataBoundControls他们足够聪明,知道他们什么时候需要数据,他们只需要从数据源中获取数据。没有必要的DataBind()调用。

DataSources还提供了处理排序,过滤和分页的好方法。大多数开发人员在使用代码隐藏时,通常不进行分页,而是最终从数据库中返回大量结果集。

数据源的缺点是没有很多好的实现。通常你最终将你的web UI绑定到你的持久性实现(即SqlDataSource,LinqDataSource等),或者最终使用ObjectDataSource,因为它非常有限,需要你将类名和方法名硬编码到ASPX中,使用反射效率有点低。因此,它对使用依赖注入或静态DAO类的人没有用。这是一个非常糟糕的课程,看起来几乎就像是MS的事后想法。

我个人更喜欢使用DataSources和代码隐藏。使用DataSource消除生命周期/视图状态的问题,然后在代码隐藏中为其提供“选择”事件/委托。不幸的是,ObjectDataSource只能使用反射,但您可以轻松编写自己的实现。我有自己的一个,但它不公开。然而,在我写它之前,我使用了它,这弥补了ObjectDataSource的一些不足之处:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

答案 2 :(得分:4)

您越来越熟悉使用的基础ADO.NET框架,您将越来越少地依赖Visual Studio打包的数据源控件。我在我工作的前几个.NET项目中虔诚地使用它们,但我很快发现,只使用连接和检索数据库上的数据的基础知识比依靠.NET来制作数据要好得多。最好的尝试为我做。

我或多或少地将它们视为训练轮,让您或多或少地熟悉数据绑定的生命周期。

答案 3 :(得分:0)

就个人而言,我认为这取决于项目。如果它是一个带有几页的小型CRUD应用程序,那么绑定到对象数据源可能会快速,简单,并且几乎没有后果。

如果它是具有定制需求的大规模应用程序,那么您可能会发现尝试使对象数据源满足这些特定需求是令人沮丧的。

答案 4 :(得分:0)

在我看来,两者都有自己的位置,优势和劣势。节省编码你提到的元素的时间,特别是分页和排序,是很有帮助的,但是如果你想对它们做任何远程有趣的事情,它们很快就会变得很难处理。

当数据严格用于显示时,我使用ODS。在数据网格,ODS中进行操作,您就完成了。但如果需要以任何方式操纵这些数据,我会远离所有内置部件,没有网格,没有ODS。

答案 5 :(得分:0)

我认为通常,代码隐藏更有用,因为它提供了自定义数据层连接的中心位置。只要将操作划分为不同的层,后面的代码就可以非常灵活。

另一方面,自定义对象数据源非常有用,因为它允许与GridView控件进行固有绑定。自定义对象数据源提供的数据集允许轻松排序和分页。自定义对象还为数据层访问提供了一个中心位置。

答案 6 :(得分:0)

与WebForms中的任何其他xxxDatasource一样,ObjectDatasource是大型应用程序(或较小应用程序上的数据访问层)上的业务层与控件本身之间的协调器。

它只是为应用程序的可视部分提供数据和其他功能,用户界面由数据存储中的视图驱动。

人们应该将这些控件视为UI内容的请求和响应,并停止滥用或完全丢弃它们。它们不是DAL,它们不是邪恶的,它们只是与数据源的连接,它们控制着如何高效地说话。

例如,如果您有一个数据网格根据决策改变了它的来源,那么应该配置两个ObjectDatasources,并且该决定应该驻留在页面中,而不是ObjectDatasource。这是使用它们的首选方式,并避免人们试图在其他响应中引用的问题。