none
Data Provider Design Pattern RRS feed

  • Question

  • i am currently developing a data access layer. my aim is to separate the entities from their data access logic. this way i will be able to work with different data sources with the minimum of fuss. i am trying to implement a kind of provider pattern in order to achieve this aim. please let me explain with a simple example. let's say i have a class called Client which has fields and properties for name and department.

    my proposed solution is to make my entity a simple object with just these fields and properties (CDO object so good for serialization over web service) then i can have an external Provider class which fills my entity like this:

    ClientProviderSqlServer

    ...

    while (rdr.Read)

    {

        client = new Client();

        if (rdr.IsDBNull(1) client.Name = rdr.GetString(1);

    ... etc ...

     

    am i on the right track here do we think? thanks

     

    Thursday, February 1, 2007 10:57 AM

Answers

  • I guess you are for 3 major reasons:

    1- you abstract your objects from the way they are stored. It does not matter if your object is represented by 1, 2 or N tables. The upper layer just gets objects
        from the database and not a set of mystic rows. It is also a good practice because onec you decided to move to Oracle, or other vendor, you know that you have
        only a limited number of classes that deals the database issue.

    2- Performance wise, using dataset may result in a big overhead when trying to access complex data. It may involve using Select method, DataRelation, not to forget the indexer Row[ColumnName] and the casting. Conversly, once an object is populated from the database, accessing its properties is very straight forward and has minimum overhead. It is as simple as: Person.Address.Street

    3- When developing, especially if there is a team that is going to use this set of APIs, other programmers can easily rely on VS IntelliSense to figure out the properties of the
        objects. Additionaly, most error resulting of badly written names are caught on compile time, thus reducing runtime errors hell.

     

    Good luck 

    Wednesday, February 7, 2007 2:56 PM

All replies

  • This looks like a sensible direction depending on the role you see for the data objects (if thier only role is to contain data they might as well persist it)

    I personally like to pass messages and not just data between tiers as it also lets you carry intent and it lets you bundle related data(units of work).

    In any event, you may consider tools like NHibernate, Wilson O/R, ActiveRecord (or LinQ for Entities if you can wait :) ) that do this already

    Arnon

    Thursday, February 1, 2007 5:19 PM
  • I guess you are for 3 major reasons:

    1- you abstract your objects from the way they are stored. It does not matter if your object is represented by 1, 2 or N tables. The upper layer just gets objects
        from the database and not a set of mystic rows. It is also a good practice because onec you decided to move to Oracle, or other vendor, you know that you have
        only a limited number of classes that deals the database issue.

    2- Performance wise, using dataset may result in a big overhead when trying to access complex data. It may involve using Select method, DataRelation, not to forget the indexer Row[ColumnName] and the casting. Conversly, once an object is populated from the database, accessing its properties is very straight forward and has minimum overhead. It is as simple as: Person.Address.Street

    3- When developing, especially if there is a team that is going to use this set of APIs, other programmers can easily rely on VS IntelliSense to figure out the properties of the
        objects. Additionaly, most error resulting of badly written names are caught on compile time, thus reducing runtime errors hell.

     

    Good luck 

    Wednesday, February 7, 2007 2:56 PM
  • re your statement about passing messages. have you got any URL's that i can learn about message based programming as this interests me a great deal.

    thanks

    Thursday, March 1, 2007 11:54 PM