What are ObjectDataSources good for?

DataSources in general and ObjectDataSources in particular are a new feature within ASP.NET 2.0.
At first glance ObjectDataSources raise the expectation that this is a means to support layered architectures that feature a cleanly separated business layer (consisting of business services that exchange business data – either plain class structures or data sets). But this hope dies very fast.
At second glance they appear to support layered architectures that feature data objects (classes that represent the domain specific data model and implement a part of the business interfaces – all in one package). This hope lives longer before it, too, diminishes.
Finally one has to accept that they support about the same conceptual features that a SqlDataSource with DataSets supports: A view into the data that works best if it is closely tied to the current page.

Once you have accepted that you can start thinking about what ObjectDataSources actually can do for you – which is more than this introduction may suggest.

To understand what ObjectDataSources can and cannot do, let’s start with understanding SqlDataSources. On a page you may have a SqlDataSource configured to provide data for your grid view. Thus it would contain a SELECT statement asking for the columns you would like to show and upon databinding of the grid it would issue that statement against the database. Another SqlDataSource an the same page may be configured to select a distinct row, e.g. the one selected within the gridview, to be used by a form view (i.e. providing a master/detail page). This data source would contain a SELECT statement asking for the columns you would like to show/edit (perhaps different columns than in the grid view) and adding a WHERE clause for the id. It also would contain respective UPDATE, INSERT, and DELETE statements. The word “contain” in this context means “buried into the page”, as in this excerpt:

<asp:SqlDataSource ID=”SqlDataSource2″ runat=”server” ConnectionString=”<%$ ConnectionStrings:ConnectionString %>”
        SelectCommand=”SELECT * FROM [Authors] WHERE ([Id] = @Id)”
        UpdateCommand=”UPDATE [Authors] SET [fname] = @fname, [lname] = @lname, [phone] = @phone WHERE [Id] = @Id”>
    <SelectParameters>
        <asp:ControlParameter ControlID=”GridView1″ Name=”Id” PropertyName=”SelectedValue” Type=”Object” />
    </SelectParameters>
    <UpdateParameters>
        <asp:Parameter Name=”fname” Type=”String” />
        <asp:Parameter Name=”lname” Type=”String” />
        <asp:Parameter Name=”phone” Type=”String” />
        <asp:Parameter Name=”Id” Type=”Object” />
    </UpdateParameters>
    […]
</asp:SqlDataSource>

Let’s make that clear: Every databound control (grid view and form view in our example) has its own private datasource control. This means in particular:

1. The datasource controls are independent of each other, going directly to the database. If one datasource control issues an UPDATE statement the other one will reflect those changes only if its SELECT comes after the UPDATE.
2. The datasource controls are tailored to the specific needs of the databound control, i.e. giving access to exacly the data that is shown/manipulated. E.g. if a datasource selected/updated a column “street”, yet this column is not bound within the form view, it will not be left as is on update, rather it will be overwritten with NULL (best case).

And here is the point: The only relevant difference between SqlDataSources and ObjectDataSources is that ObjectDataSources issue method calls rather than SQL statements.
Now, this is crucial for the understanding and the implications are both good and bad.

• For one thing, calling a method means abstraction. Having SQL statements within the pages ties the database structures directly into your UI code. A method can hide some of these details.
  ➡ ObjectDataSource is good!
• C# classes are indivisible. While a SQL statement can explicitely state which columns to access, a class cannot be asked to please contain only a subset (i.e. a partition) of its properties. (Well, not unless we have LINQ support.) Thus we cannot use class instances for insert or update methods if we are only working on a partition of that object. In these cases we will have to provide methods like UpdateMainData(Customer), UpdateAddress(Customer), UpdateContactData(Customer), … with the name implying the partition of the Customer data type (or conceptually equal methods with single field parameters rather than customer objects). Can you spell “maintenance”?
  ➡ ObjectDataSource has its problems!
• ObjectDataSources create the configured data object class on demand, each datasource its own data object. Again, those data objects know nothing of each other, no change yet.
  ➡ ObjectDataSource does not address all problems!
• However, there is the possibility to subscribe to certain events and customize the behaviour. One could register for the ObjectCreating event and rather than creating a new data object return a reference to a previously created object. One could also register for the Updating event and implement logic that updates exactly the provided fields.
  ➡ ObjectDataSource provides better oportunities to address arising problems!

For small point&click applications, SqlDataSource may be the way to go. It’s fast, it is supported by designers and wizards (always good for quality and maintenance), it avoids unnecessary coding overhead, it is pure ASP.NET and therefore the application code has a steep learnig curve. No need to bother with the additional overhead an ObjectDataSource introduces.

For not so small, non-trivial, or enterprise applications, e.g.

• consisting of many pages,
• needing more sophisticated business logic,
• having a business logic layer that is (in principle) independent of UI specifics,
• having to comply with database access restrictions/policies,
• requiring a more sophisticated UI, e.g. maintaining changes in state before they are explicitely saved,
• being subject to versioning,
• …

… SqlDataSource is probably not the way to go. Rather it is prone to become a development problem and a maintenance nightmare.

ObjectDataSource in its plain form may not be the way to go either. Yet it offers the extensibility to roll your own additional logic. The farther you deviate from vanilla web applications, the more work you have to do – but you can do it.

Ergo: Use the right tool for the job at hand and know how to handle the tool. ObjectDataSource is a good tool if you know when to use it, how to use it, and what not to expect.

That’s all for now folks,
AJ.NET

Advertisement