3

My application is separated into three layers (presentation, business, and data access). Most of the pages in my application work like this:

[Presentation Layer]

    public override void FillData()
    {
        grid.DataSource = AnimalBll.FindAnimal(
            SessionHelper.GetLoginInfo(base.sessionId).First().Id);
        grid.DataBind();
    }

[Business Layer]

    public static DataTable FindAnimal(int id)
    {
        var result = DBHelper.GetDataTableFromSP("FindAnimal", id);
        return result;
    }

As you can see I bind directly to the grid. So, why would I use an ObjectDataSource?

O.O
  • 11,077
  • 18
  • 94
  • 182
  • Reading the answers below on this page, I happened to see this http://stackoverflow.com/questions/4485946/if-objectdatasource-isnt-the-answer-for-a-large-application-what-is listed in the right side "Related" question. – gbs Mar 31 '11 at 22:36

2 Answers2

5

You shouldn't - they should never be used in a serious application. The ObjectDataSource control discourages the separation of concerns in your application. Since you have already properly partitioned the different tiers of your app, an ObjectDataSource would only cause problems and cross-tier responsibilities.

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
  • 1
    Hmm, I'm a little confused by your answer. "The ObjectDataSource control supports a three-tier architecture..." http://msdn.microsoft.com/en-us/library/9a4kyhcx.aspx – O.O Mar 31 '11 at 21:34
  • 1
    @subt13 - Sorry I conflated `ObjectDataSource` and `SqlDataSource`. You are right, an `ObjectDataSource` can be used in a >2 tier architecture. – Andrew Hare Mar 31 '11 at 21:36
  • 1
    @subt13 - I still think that an `ObjectDataSource` doesn't make a whole lot of sense for you at this point given your infrastructure. – Andrew Hare Mar 31 '11 at 21:39
  • @Andrew - the app is still being developed and I just wanted to take a step back and see if I was missing out on something. – O.O Mar 31 '11 at 21:42
  • I feel that ObjectDataSources just makes it unclear what happens under the hood.. was it sqlserver, or was it OLEDB? Memory Class? Or.. perhaps.. a Serial Com device? In three tiers the way to check, can be long. – Independent Mar 31 '11 at 21:43
  • @Jonas - I would argue that abstraction is usually a good thing in this context. I really don't see how it could be that hard to track down the business object that it is bound to... – O.O Mar 31 '11 at 21:47
  • @Jonas that's the whole point of an ObjectDataSource. You don't want your UI to care what's happening under the hood, because it may be done one way in production and completely differently for testing. As long as the data is returned in the correct format, it doesn't matter what's happening under the hood, and I don't see that as a violation of the N-Tier approach at all, but directly supporting it! – Joel C Apr 01 '11 at 04:04
  • "Why use objectdatasource when I can bind directly". I prefer to be clear with what the code want's / uses. Even when there **are** several possible datasources, prefer manage the data in BL and send it further directly to the control binding, like subt13 sample. Of course there, for others, may exist many good reasons using Ods, – Independent Apr 01 '11 at 06:44
3

The benefit of using an ODS is that it allows you to also update and save your entities automatically. With how you have it now, you'd have to catch the appropriate event (row_saving?) and then strip out the new values, and pass them to your ORM for saving.

Andrew is right though, ObjectDataSource almost never works well, you should avoid it at all costs.

For basic grid-type updating I've had decent luck with either a LinqDataSource or an EntityDataSource (assuming you're using L2S or EF), but again, for large applications you're going to want to stay away from things like this (separation of concerns and all that)

Adam Rackis
  • 82,527
  • 56
  • 270
  • 393
  • Ummmmmmmm, honestly it's been a lot of years since I've tried, I've just always had trouble getting it to work the way I needed. As I recall it was designed to be used with a very specific type of ORM, and that never worked out well for me. Sorry I can't give you more details. Just find the best solution **for you** and run with it. Maybe you have a unique case where ODS yields the best code. – Adam Rackis Mar 31 '11 at 21:41
  • I have one now, and it's a nightmare. A simple 3 tier approach with stored procedures and entities would have been so much simpler. With double binding, this monster has 61 projects in the solution. It's only 20-30 screens. – ARLibertarian Mar 21 '19 at 16:39