.NET2.0 datasets and the provider model

Posts   
 
    
omar avatar
omar
User
Posts: 569
Joined: 15-Oct-2004
# Posted on: 29-Jun-2005 11:07:34   

Greetings all, I wanted to share some thoughts about my experience thus far with .NET2.0: * DataSets have gained extra functionality in the following areas: 1- They can be binary serialized 2- DataTable is serializable now 3- can embed data access code in a datasets XSD file. This data access code can be for object data sources. Now I am thinking are Datasets now presenting themselves as an alternative to structures like EntityCollection and EntityBase. I am not talking taking out our BL layer but rather to use our DataSets as exchange mechanism between UI and BL.

  • all presistance logic in .NET 2.0 (profiles, WebParts, permissions, ...etc.) uses the Provider to abstarct coupling with a specific db storage. Putting it simply, all presistance logic talks to a standard Provider API and you can write a provider (by inhertiing a class) to presist to whatever storage you want. I was thinking that this is very close to LLBL's approach of abstarcting all DB driver use through interfaces.

I can't help but think if these two pints could influence the future architecture of LLBL ?? confused

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39801
Joined: 17-Aug-2003
# Posted on: 29-Jun-2005 13:03:29   

omar wrote:

Greetings all, I wanted to share some thoughts about my experience thus far with .NET2.0: * DataSets have gained extra functionality in the following areas: 1- They can be binary serialized 2- DataTable is serializable now 3- can embed data access code in a datasets XSD file. This data access code can be for object data sources.

Code in the .xsd? Or do you mean code in the partial class generated for typed datasets? In the latter case, indeed that's true. The generation of typed datasets is still very poor though. e.g., no generics.

Now I am thinking are Datasets now presenting themselves as an alternative to structures like EntityCollection and EntityBase. I am not talking taking out our BL layer but rather to use our DataSets as exchange mechanism between UI and BL.

Datatable can be seen as an alternative to entitycollection, though it can't be seen as an alternative to entitybase. The entity is an object, not a bucket. I've planned some utility methods inside the entitybase and entity collection classes to convert back/to datatable/datarow to make life easier for people who want to use with datasets.

Though one thing misses in the dataset approach: dyn. sql generation and server-side filter construction, which IMHO is the core asset of an O/R mapper: use objects which produce sql for you.

Like an object graph which is simply saved with 1 statement, without having to write tedious syncing code and procs to save every element in the graph, in the RIGHT order.

  • all presistance logic in .NET 2.0 (profiles, WebParts, permissions, ...etc.) uses the Provider to abstarct coupling with a specific db storage. Putting it simply, all presistance logic talks to a standard Provider API and you can write a provider (by inhertiing a class) to presist to whatever storage you want. I was thinking that this is very close to LLBL's approach of abstarcting all DB driver use through interfaces. I can't help but think if these two pints could influence the future architecture of LLBL ?? confused

It's the typical Microsoft sugar simple_smile By using a provider model doesn't make your software suddenly database agnostic. You still have to deal with database specific stuff, like the SQL for example. The providers help a bit, though I already use a provider model for the driver/DQE's. The drivers will definitely stay the same as they're now as every db needs a new bag of tricks which is unique for that db. The DQE's will likely merge to 1 main class and per db a set of overrides, to make it easier to write DQE's.

Also, I think webparts communicating with a db directly is not what you want, though it demos great simple_smile . Most apps use a BL tier the PL communicates with. Therefore I think having an object provider for these elements is more what people will use. If that's what's needed, that class will be written for 2.0 simple_smile .

I've to dig into the details yet for ObjectDataSource for example to see where its limits are, as it sports 4 crud methods, but if these offer all the functionality offered by LLBLGen Pro is to be seen.

Frans Bouma | Lead developer LLBLGen Pro
omar avatar
omar
User
Posts: 569
Joined: 15-Oct-2004
# Posted on: 29-Jun-2005 13:58:53   

thanx for the answer... wink