DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: Repost: Databases & Business Objects

  1. #1
    Garry Mc Guest

    Repost: Databases & Business Objects


    Greetings

    I have a dilema... I am putting a business object together which stores data
    into a SQL database. The problem is, which technique to use??

    In VB6 we didn't have many options, so it was easy, well kind of. Now, we
    have a number of wiz bang ways, but which is best? Let me try to expalain
    the problem, and maybe you can provide some light on the best solution.

    Problem:
    Hierarchial object model, some objects have a small amount of data, others
    have a large number ie 2,000+ in a collection. I'd like to keep it as natural
    as possible, that is the nice x("key").Name type syntax.

    The way I see it I have the following options. I should point out that I
    haven't got a full understanding of all the options as yet, but have a basic
    understanding of what they 'should' do for me.

    Option 1: Method Calls
    Read Access:
    Reduce the object to a simple structure and have each method call access
    the database and return a result set. Probably a DataSet in .NET
    Write Access:
    Where we try update the database with something like x.update(value1,value2)
    or some XML maybe as a parameter. The idea being send a chunk of data to
    the middle tier and process it without creating the object model.

    Option 2: Object Model
    Read Access:
    On creation of the object load all the data into the object model. Then
    access data as normal via the object tree.

    Write Access:
    Again read all the data into the model. Then change the bits required, and
    then call an update method.

    Option 3: DataSet
    Read Access:
    Map a .NET typed DataSet to the object model. Using relationships in the
    Dataset to map to the tables.

    Write Access:
    As above, but change the values like Option 2. Then call the accept changes
    method of the dataset.

    Option X: Your suggestion!

    The key thing I want to achieve is it to be 'fast' and scalable yet have
    a nice object model feel to it. I see Option 1 as being a little ugly in
    presentation but probably fast. Option 2 looks good, but would probably
    be slow. Option 3? well I think this is the area to look at but its all
    abit new, and I'm not quite sure what the performance would be. I'm also
    not that sure how you'd wire the typed dataset created by VS.NET to your
    business object.

    Another issue is that it should be easily used by the calling application.
    That is it would be nice to be able to bind the object to ASP.NET controls
    etc.

    If you think I've missed the mark on my Options that's cool, as I and I'm
    sure many others would appreciate other views on how to tackle the Database
    Vs Object model problem.

    I look forward to anyones comments. Just make them pleasant

    Garry Mc


  2. #2
    Patrice Scribe Guest

    Re: Repost: Databases & Business Objects

    Especially for *ASP* applications, I prefer to see a database as a single
    object on which I perform "well known queries" exposed as methods (option 1)
    returning a recordset. It avoids to create intermediate objects.

    I'm using stored procedures behind the scene to easily perform additional
    tasks when data are inserted, selected, updated, deleted...

    For option 1 I would have for example :
    GetClient(ClientCode)
    GetOrder(OrderCode)

    I would call for example explicity GetClient(ClientCode) wether I want data
    for a client selected in a list or for the client to which a particular
    order belongs (retrieved using GetOrder(OrderCode), ClientCode being a field
    from the returned recordset)...

    Note though that option 2 is probably not that far you seems to think. I
    would still recommend using method calls (so that you can make only needed
    queries instead of preloading collections you may have no use for in a
    particular context). It seems to me that option 1 is just the
    "implementation" of the full object model view exposed by option 2.
    For option 2, I would see :
    Clients(ClientCode) this is actually a method call even though it feels like
    a collection.
    Orders(OrderCode).Client : a property i.e. a method call that is implemented
    using Clients(Me.ClientCode)
    Both could actually calls a private GetClient(ClientCode) option 1 style
    method.

    For now I prefer to have always the "get a client by its code" semantic
    rather than having the "get the client to which this <object> belongs"
    semantic.

    Patrice

    "Garry Mc" <garrymc@itswebservices.com> a écrit dans le message news:
    3b97ed26$1@news.devx.com...
    >
    > Greetings
    >
    > I have a dilema... I am putting a business object together which stores

    data
    > into a SQL database. The problem is, which technique to use??
    >
    > In VB6 we didn't have many options, so it was easy, well kind of. Now, we
    > have a number of wiz bang ways, but which is best? Let me try to expalain
    > the problem, and maybe you can provide some light on the best solution.
    >
    > Problem:
    > Hierarchial object model, some objects have a small amount of data, others
    > have a large number ie 2,000+ in a collection. I'd like to keep it as

    natural
    > as possible, that is the nice x("key").Name type syntax.
    >
    > The way I see it I have the following options. I should point out that I
    > haven't got a full understanding of all the options as yet, but have a

    basic
    > understanding of what they 'should' do for me.
    >
    > Option 1: Method Calls
    > Read Access:
    > Reduce the object to a simple structure and have each method call access
    > the database and return a result set. Probably a DataSet in .NET
    > Write Access:
    > Where we try update the database with something like

    x.update(value1,value2)
    > or some XML maybe as a parameter. The idea being send a chunk of data to
    > the middle tier and process it without creating the object model.
    >
    > Option 2: Object Model
    > Read Access:
    > On creation of the object load all the data into the object model. Then
    > access data as normal via the object tree.
    >
    > Write Access:
    > Again read all the data into the model. Then change the bits required,

    and
    > then call an update method.
    >
    > Option 3: DataSet
    > Read Access:
    > Map a .NET typed DataSet to the object model. Using relationships in the
    > Dataset to map to the tables.
    >
    > Write Access:
    > As above, but change the values like Option 2. Then call the accept

    changes
    > method of the dataset.
    >
    > Option X: Your suggestion!
    >
    > The key thing I want to achieve is it to be 'fast' and scalable yet have
    > a nice object model feel to it. I see Option 1 as being a little ugly in
    > presentation but probably fast. Option 2 looks good, but would probably
    > be slow. Option 3? well I think this is the area to look at but its all
    > abit new, and I'm not quite sure what the performance would be. I'm also
    > not that sure how you'd wire the typed dataset created by VS.NET to your
    > business object.
    >
    > Another issue is that it should be easily used by the calling application.
    > That is it would be nice to be able to bind the object to ASP.NET

    controls
    > etc.
    >
    > If you think I've missed the mark on my Options that's cool, as I and I'm
    > sure many others would appreciate other views on how to tackle the

    Database
    > Vs Object model problem.
    >
    > I look forward to anyones comments. Just make them pleasant
    >
    > Garry Mc
    >




  3. #3
    Garry Mc Guest

    Re: Repost: Databases & Business Objects


    Patrice

    I have been thinking about this problem a lot more and have come up with
    a jitDAL (Just in Time Data Access Layer), which I'm still working on. Initial
    tests seem good, and it should provide the speed of method 1 (basic method
    calls), with the fuctionality of the object model. Implementation will also
    be very simple (well that's the plan once its finished!), by making it a
    base class from which you inherit.

    Trying to work out the best use of all the tools .NET gives is a challenge,
    but they do seem to be quite good.

    As a side note: I have found with very simple comparite tests so far, that
    .NET DataAccess was twice as fast as the ADO version. Also, if anyone is
    doing anything witht .NET and thinks is slow in the IDE, your right! - compile
    it up and then try, you'll notice a HUGE difference. For example my ADO.NET
    test was taking 14 secs in the IDE, but only 2.5 secs when compiled. That's
    a huge difference.

    Garry Mc

    "Patrice Scribe" <scribe@chez.com> wrote:
    >Especially for *ASP* applications, I prefer to see a database as a single
    >object on which I perform "well known queries" exposed as methods (option

    1)
    >returning a recordset. It avoids to create intermediate objects.
    >
    >I'm using stored procedures behind the scene to easily perform additional
    >tasks when data are inserted, selected, updated, deleted...
    >
    >For option 1 I would have for example :
    >GetClient(ClientCode)
    >GetOrder(OrderCode)
    >
    >I would call for example explicity GetClient(ClientCode) wether I want data
    >for a client selected in a list or for the client to which a particular
    >order belongs (retrieved using GetOrder(OrderCode), ClientCode being a field
    >from the returned recordset)...
    >
    >Note though that option 2 is probably not that far you seems to think. I
    >would still recommend using method calls (so that you can make only needed
    >queries instead of preloading collections you may have no use for in a
    >particular context). It seems to me that option 1 is just the
    >"implementation" of the full object model view exposed by option 2.
    >For option 2, I would see :
    >Clients(ClientCode) this is actually a method call even though it feels

    like
    >a collection.
    >Orders(OrderCode).Client : a property i.e. a method call that is implemented
    >using Clients(Me.ClientCode)
    >Both could actually calls a private GetClient(ClientCode) option 1 style
    >method.
    >
    >For now I prefer to have always the "get a client by its code" semantic
    >rather than having the "get the client to which this <object> belongs"
    >semantic.
    >
    >Patrice
    >
    >"Garry Mc" <garrymc@itswebservices.com> a écrit dans le message news:
    >3b97ed26$1@news.devx.com...
    >>




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center