Design and Tools - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 2 FirstFirst 12
Results 16 to 21 of 21

Thread: Design and Tools

  1. #16
    Pierre G. Boutquin Guest

    Re: Design and Tools

    This isn't just about state. It's also about round-trips!

    > 1) Using a more OO approach...
    >
    > Set oEmp = New cEmployee
    > With oEmp
    > .Name = sName


    1 trip

    > .Location = sLocation


    another trip

    > .Save


    yet another trip

    > End With
    > Set oEmp = Nothing
    >
    > 2) Using the Dwamish style...
    > Set oEmp = New cEmployee
    > oEmp.AddEmployee(sName, sLocation)


    1 single trip

    > Set oEmp = Nothing


    <Pierre/>



  2. #17
    Richard Dalton . Guest

    Re: Design and Tools





    "Pierre G. Boutquin" <boutquin@home.com> wrote:
    >This isn't just about state. It's also about round-trips!


    Pierre,

    your answer suggests that the business object would
    be running remotely. Would in not make more sense to
    have the business object in process on the client,
    so you could set or read it's properties at will,
    and then go "over the wire" only for loading and
    saving?

    I know, this is heresy for the true COM lovers.


    -Richard


  3. #18
    Richard Dalton . Guest

    Re: Design and Tools


    "Pierre G. Boutquin" <boutquin@home.com> wrote:

    >What you are suggesting is in fact equivalent to method #2, >since to save

    you will need to call
    >
    >Save(param1, param2, ..., paramN)
    >



    I would have done the following:

    With obj
    .Prop1 = val1
    .Prop2 = val2
    .Prop3 = val3
    .Save
    End With


    But this wouldn't require round trips over the
    wire because the object would be in process. Only
    the Save method would need to look beyond the client
    machine.

    It means you can have stateful busines objects in the
    client, while retaining the ability to marshall data
    efficiently.

    >It appears we are agreeing here.


    Probably ;-)

    -Richard

  4. #19
    Pierre G. Boutquin Guest

    Re: Design and Tools

    <Richard Dalton .> wrote in message news:3a6ff7c4$1@news.devx.com...
    > I would have done the following:
    >
    > With obj
    > .Prop1 = val1
    > .Prop2 = val2
    > .Prop3 = val3
    > .Save
    > End With
    >
    >
    > But this wouldn't require round trips over the
    > wire because the object would be in process. Only
    > the Save method would need to look beyond the client
    > machine.


    And inside this Save method, you'd have:

    SaveBeyondMachine(param1, param2, ..., paramN)

    We are making different points here: you're pointing out a neat pattern, I
    was pointing out an obvious fact to somebody claiming to be confused. My
    point, which you don't seem to dispute is that besides server state, one
    needs to reduce server trips. Reducing server state increases scalability,
    reducing server trip is great for performance.

    <Pierre/>



  5. #20
    Richard Dalton . Guest

    Re: Design and Tools


    "Pierre G. Boutquin" <boutquin@home.com> wrote:

    >And inside this Save method, you'd have:
    >
    >SaveBeyondMachine(param1, param2, ..., paramN)
    >


    Well, Again, not quite. But I'll stop pointing out
    areas where we differ. The principle is the same,
    move your properties around in chunks not individually.

    >My point, which you don't seem to dispute is that besides
    >server state, one needs to reduce server trips.


    I agree fully. I was just pointing out that I would keep
    the business object local to the client. In which case
    it's perfectly OK to set the properties individually, as
    long as you marshall them back to the DB in one round trip.
    -Richard




  6. #21
    Bob Guest

    Re: Design and Tools

    In article <3a598fcd$1@news.devx.com>, "Richard Dalton" . says...
    >

    <snip>
    > Anyhow, what we built is a tool that will build business objects
    > that allow you to talk to a database. Pretty standard stuff.
    > When you point it at a table e.g Employee you get 4 classes
    > CEmployee and CEmployeeCollection in the business layer
    > and CEmployeeDB and CEmployeeCollectionDB in the Database
    > layer.


    It sounds like you've made a design assumption that 1 table = 1 business
    object. Is this correct?

    Bob

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