locked
table data gateway ? RRS feed

  • Question

  • If we were using a domain model and were working with collections of domain entites, we would have to map them to data.
    Now consider this mapping ..
    We have a customer entity containing a collection of order line items..
    In order to populate this we could follow two approaches..
    Just want to know when we would decide for one over the other ?

    option 1] We could fire an outer  join  query to the relational database and get a resultset of  customer info and related orders
    The resultant from the query would be a recordset containing repeating customer info for every record from the order table, which is ok as we have used a outer join.
    we could then loop through the results and populate the cutomer entity and the order entity collection and get the required customer  object.
     
    option 2] Other way would be to use a "table data gateway" pattern
    I would have one class for every table, the customer info would be returned by the "customer gateway class" and the order collection would be returned by the "order gateway class".
    The Biz layer would combine the output from both the gateways and provide the required customer object.


    Question is .. which one will you choose and why ?




    Thursday, February 14, 2008 12:57 AM

Answers

  • From reading the information on the pattern, it says, and I quote:

     

    "Many developers aren't comfortable with SQL, and many who are comfortable may not write it well". 

     

    That seems to be the primary drive behind using the pattern.

     

    What you're doing, is being forced to implement the join in code instead, which I would expect to be a lot slower that using the database to do it instead.

     

    I could see a lot of benefits to decoupling objects from other objects, and performing the record consolidation in one place, but it really depends on what performance is acceptible.

     

    If you think about it, instead of saying to the DAL to get you all the data, then using knowledge of that join to perform the mapping to domain objects, you would be going through each record, asking for the child records, then setting then, then moving to the next record and so on.  Is that what would happen, as I'd expect that that wouldn't scale very well?  I would expect that you would need to implement caching to make the situation work better, but I still can't see how it could perform as well as a database server?

     

    From the point of view of the implementations and how they work, I think you're missing the point.  The consideration first is for the requirements, so get the quality of service (non-functional) requirements like performance metrics first, then that will narrow down the field to a small number, or maybe even one choice.

     

    Don't try to take the pattern and make the requirements fit it, otherwise you will be in for a whole world of hurt.

     

    I hope this helps,

     

    Martin Platt.

    Friday, February 15, 2008 12:10 AM

All replies

  • This second pattern approach, how does that work?  Surely that just encapulates option 1 anyway?

     

    It seems to me that the gateway class is basically just some sort of business rules object, that you call that returns domain objects?

     

    Perhaps you could give an example of what the gateway does, and how it differs from the other option?

     

    hope this helps,

     

    Martin Platt.

    Thursday, February 14, 2008 4:51 AM
  • requirement is to populate a domain object with 2 collections.
    Obj.collection1 and obj.collection2



    1st appraoch
    entityObject = DAL.getEntity()
    inside the getEntity() I would have fired a join query which pulls data from these 2 tables, got a resultset
    populated my entity and return it to the biz layer


    The second approach

    collection1obj = DAL.getcollection1()
    entityobject.collection1.= collection1obj

    collection2obj = DAL.getcollection2()
    entityobject.collection2.= collection2obj

    In the second approach the gateway class is in the context of a "Table data gateway" pattern as per Martin Fowler ...
    In the implmentation which I have seen there are no joins used at all, there is 1 class per table.
    Each of these classes return data from the table in the form of collections, these collections are then added to the main entity object.

    why use the second approach as per the table data gateway pattern ?





    Thursday, February 14, 2008 5:35 AM
  • From reading the information on the pattern, it says, and I quote:

     

    "Many developers aren't comfortable with SQL, and many who are comfortable may not write it well". 

     

    That seems to be the primary drive behind using the pattern.

     

    What you're doing, is being forced to implement the join in code instead, which I would expect to be a lot slower that using the database to do it instead.

     

    I could see a lot of benefits to decoupling objects from other objects, and performing the record consolidation in one place, but it really depends on what performance is acceptible.

     

    If you think about it, instead of saying to the DAL to get you all the data, then using knowledge of that join to perform the mapping to domain objects, you would be going through each record, asking for the child records, then setting then, then moving to the next record and so on.  Is that what would happen, as I'd expect that that wouldn't scale very well?  I would expect that you would need to implement caching to make the situation work better, but I still can't see how it could perform as well as a database server?

     

    From the point of view of the implementations and how they work, I think you're missing the point.  The consideration first is for the requirements, so get the quality of service (non-functional) requirements like performance metrics first, then that will narrow down the field to a small number, or maybe even one choice.

     

    Don't try to take the pattern and make the requirements fit it, otherwise you will be in for a whole world of hurt.

     

    I hope this helps,

     

    Martin Platt.

    Friday, February 15, 2008 12:10 AM