DataSets, ObjectDataSource and 3-Tier ASP.NET

As I’ve mentioned in other post, while I think LINQ has it’s uses, I still favor the use of the ObjectDataSource control in conjunction with DataSets and a 3-tiered architecture.  Since any future demos I do will probably involve this architecture, I thought it would be useful to do a short demo that demonstrates how to create a 3-Tiered architecture in ASP.NET.

Related Post

3 Responses to “DataSets, ObjectDataSource and 3-Tier ASP.NET”

  • [...] Datasets ObjectDataSource and 3-Tier ASP.NET Datasets StoredProcedures and 3-Tier ASP.NET Swapping Out the Data Access Layer Swapping the Data Access Layer Abstractly Using Reflection to Load a Class in ASP.NET [...]

  • Joel:

    I started out using SqlDataSource controls in ASP.NET, then moved to custom classes to have the separation between presentation, logic, and data access, but the overhead of doing manual CRUD for every custom class was prohibitive. I’m relatively new to both typed datasets and Linq2Sql (and Linq in general), so if I’m misunderstanding something, please correct me. But I’m not entirely sure I understand why you prefer typed datasets over Linq2Sql classes. From my understanding (and I’m asking this to clarify this issue in my own head), unless I’m misinformed, Linq2Sql should be more efficient, in terms of both productivity and performance.

    If I’m using a typed dataset, let’s say a relatively simple Customer, Order, OrderLineItem type of system, if I want to return the details for a single customer’s order and I call the generated GetData() method, it’s going to return a populated DataSet with all my customers, all my orders, and every single line item in my system. Then in the BLL, I would filter it to return only the details for the Order I’m interested in, and expose that as a new method, such as GetOrder(). Not a big deal if you’ve only got a few hundred customers and order history going back 2 or 3 years, but if you’re developing on a larger scale where you have thousands, or 10′s of thousands of customers, with years and years of history, and frequent orders, and large numbers of items in each order, this becomes extremely inefficient (I haven’t tried performance testing to verify this, so maybe I’m making an invalid assumption). Alternatively, I could create a new method in the DAL to return just the specific data I’m looking for, but I’d have to write this by hand, losing the productivity benefit of using the generated DataSet. I would also need to know ahead of time the fields I would need to query on, so each can be exposed as a method, or have an abstracted way of querying by any parameter, in which case I now lose the advantage of using a typed dataset, since I’m now filtering by [string FieldName], and typos or changes to field names won’t be found until runtime instead of at compilation. Then I would also have to create custom adapters for any datasource I want to use, since the query syntax is going to be different based on whether my data is coming from Access, or MS-SQL, or MySql, or an XML file.

    My understanding of Linq2Sql is that it allows you to do more dynamic, and yet still strongly-typed, filtering which actually gets translated directly into the WHERE clause of your SELECT when it gets passed to the database, and it allows you to use Intellisense for the field names as you’re writing code. This way, only the data I need is returned from the database, which should improve performance and cut down on both the amount of memory used and the network traffic generated, without the need for extra development beyond the existing Linq2Sql framework. And if the business requirements change from XML to using an SQL database, or vice versa, I can switch out Linq2Sql for Linq2Xml.

    Again, I haven’t had much experience using either technology (yet), and I may be misinformed as to how Linq actually works, or be reading too much into the marketing hype around Linq. I’m basically at the point in my current project where I need to make a decision between using Linq2Sql or using typed datasets, so I’m trying to reach a conclusion, and I don’t want to take the Linq2Sql route, then find out 3 months from now that Linq2Sql is missing some great feature that typed datasets would handle easily, and have to start over.

    For instance (and I’m not sure how a typed DataSet would be any better or worse for this), how can I handle Enums in my custom classes which are tables in my database? Basically, tiny tables with only a few entries, but which can be joined to to give meaning to ID fields (status, etc.), mostly for reporting purposes so that I don’t need to have Account.Status = ‘Active’ and Account.StatusID = 1 (or worse, no ID field at all, just a text field) both as fields on the Account table in the database, and I also don’t have to hardcode translations into my reports just to display friendly terms like “Active” instead of Status=1 in the reports. I was thinking in my Linq2Sql class, I could have a property that would return an enum based on the value of the corresponding ID field, for instance:

    public AccountStatus Status {
    get {
    return (AccountStatus)Enum.Parse(typeof(AccountStatus), this.StatusID);

  • Dave:

    Wow Joel. You’ve posted 3 times in one night?!

    OK.. let me see if I can address some of your items.

    First thing. When you use a typed dataset, you would NEVER retrieve all of the data and THEN filter it. You’d create a stored procedure that returned what you wanted and then create an appropriate method in your BLL that would then return that data.

    So, the only real benefit, as you’ve already stated is that you don’t have to write the stored proc.

    But, since LINQ is essentially SQL using VB.NET or CSharp (or whatever other language) syntax. You are essentially having to write this code. It is really just a matter of where you choose to write it.

    And then there is the issue of code re-use. And again, it is a matter of WHERE you write the code, not a matter of IF. To re-use the code correctly, you need a DAL accessed by a BLL. This can be done in either SQL with stored procs OR it can be done with LINQ.

    What LINQ really buys us is the ability for the program to control his own calls to the database instead of having to either depend on or actually be a DBA.

    If it works for you, use it. Personally, I can’t see that it buys me enough to use it as my primary means of accessing the database.

    However, I do find it useful for processing list in my code as if they were a database. I just did that tonight in fact.

    Purely MY opinion. And I’m sure you can find other post that will entirely disagree with me on this, but I find that LINQ2SQL is great for small projects and/or developers who haven’t spent the time to learn SQL. But, if you know SQL, you would be just as well off writing the stored procs.

    In summary, this isn’t a hill I’d die on. The only wrong way to do this is to use the SqlDataSource, which it sounds like you’ve already discovered.

    A good programmer will learn both (LINQ and ObjectDataSource) so that they know the benefits (and drawbacks) of each so they can pick the right tool for the job.