I'm working on a data layer for an application. It uses the Data Access Application Blocks (version 3.0) to do the data access. Above that, there's a Data Access Layer (DAL) that will provide an object oriented way to deal with the data. Nothing new about that. I've been reading Microsoft's Application Architecture for .NET: Designing Applications and Services and find it a very good read. I've already learned quite a bit about how to design applications to be scalable and flexible. I would recommend this to any .NET application architect out there.


Anyway, when building a data layer, it recommends using a Dataset to pass data around in, so that binding is easy to do, as well as a known interface to program against, easy for other developers to pick up on, lots of help available about datasets, etc. To make the programming easier, I decided on a typed dataset, but now I'm not so sure on the idea of a dataset at all.


Our application will load small chunks of related data at a time, with one master object, which has three or four collections off of it, each with anywhere from 2 to 100 objects in each. The smallest collection of those will have a sub collection, which will also have a sub collection. Here's an example XML representation:


<MyObject>
  <MySubCollection1>

    <MySubObject1>
      <MySubSubObject>

        <MySubSubSubObject />
        <MySubSubSubObject />

        <MySubSubSubObject />
        <MySubSubSubObject />

      </MySubSubObject>
      <MySubSubObject>

        <MySubSubSubObject />
        <MySubSubSubObject />

      </MySubSubObject>
      <MySubSubObject>

        <MySubSubSubObject />
        <MySubSubSubObject />

        <MySubSubSubObject />
      </MySubSubObject>

    </MySubObject>
    <MySubObject>

      <MySubSubObject>
        <MySubSubSubObject />

        <MySubSubSubObject />
        <MySubSubSubObject />

        <MySubSubSubObject />
      </MySubSubObject>

      <MySubSubObject>
        <MySubSubSubObject />

        <MySubSubSubObject />
      </MySubSubObject>

      <MySubSubObject>
        <MySubSubSubObject />

        <MySubSubSubObject />
        <MySubSubSubObject />

      </MySubSubObject>
    </MySubObject1>

  </MySubCollection1>
  <MySubCollection2>

    <MySubObject2 />
    <MySubObject2 />

    <MySubObject2 />
    <MySubObject2 />

    <MySubObject2 />
    <MySubObject2 />

    <MySubObject2 />
  </MySubCollection2>

  <MySubCollection3>
    <MySubObject3 />

    <MySubObject3 />
    <MySubObject3 />

  </MySubCollection3>
</MyObject>


Of course, each object has properties and defines relations between them. For example, MySubObject3 references a MySubSubSubObject (great names huh?).


So is a typed dataset overkill for this? If I only load a handful of records do I need this? Also, our control that this data works against doesn't support databinding, so will I see a benefit from even trying this?


The other question I have is related to this. I want to inherit from the dataset for each object and add static methods to it for basic CRUD functionality (Create, Retrieve, Update, Delete). So what I was doing was inheriting from the DataTables created in the dataset class, and adding them there, but is that the correct way to do it? Or do I inherit from the dataset, add them there, and prefix each CRUD method with the object name?


I think my solution here will be one of two things. First is to drop the typed dataset and go with custom objects, each with their own CRUD methods. This also helps extract the database design away from the application, and you can still databind to public properties of an object. Plus, the CRUD methods become standard across all objects (myObject.Create("myId");, etc.) making it easy to pick up how to code against it. The second object is to put my CRUD methods on an inherited dataset object, rather than the datatable itself, which could get ugly. Thoughts?


I've even started looking at Gentle.NET as a potential solution for the data access, but we'll see. I haven't played with it much, but figure I'll try it out Some Day.