Thin Objects for Better Performance


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Thin Objects for Better Performance

  1. #1
    Dave Fleischman Guest

    Thin Objects for Better Performance


    Can anyone tell me if it is better to design objects as described below to
    improve performance and limit overhead? Some people I work with are arguing
    these points with me.

    1. Limit the use of properties because they require additonal round trips
    from the client to the MTS server. Same concept for database calls.

    2. Design business and data objects to pass data back to the GUI instead
    of loading a business object (class/collection) and loading GUI controls
    from the business object. Then immediately destroy (set to nothing) the
    business and data objects. The argurment here is that leaving MTS objects
    active keeps transactions open too long and eats up resources.

    3. Basically, objects in MTS should just look more like a BAS module with
    functions that return values.

    In my mind, if you are programming object, they should be designed with the
    appropriate properties and methods. Wheather or not they are located on
    the users PC or in MTS, the interface should not matter. Furthermore, MTS
    is designed to manage the use of objects more efficiently. The points above
    suggest a design that is not very object oriented.

    Thanks for your feedback.
    Share on Google+

  2. #2
    Bill Slater Guest

    Re: Thin Objects for Better Performance

    <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
    <html>
    The following link should help answer most of your questions. Basically
    what you have been told is correct.
    <p>&nbsp;<a href="http://msdn.microsoft.com/workshop/server/components/vbmtsiis.asp">Web
    Workshop - Developing a Visual Basic Component for IIS/MTS</a>
    <p>HTH
    <br>&nbsp;
    <p>Dave Fleischman wrote:
    <blockquote TYPE=CITE>Can anyone tell me if it is better to design objects
    as described below to
    <br>improve performance and limit overhead?&nbsp; Some people I work with
    are arguing
    <br>these points with me.
    <p>1. Limit the use of properties because they require additonal round
    trips
    <br>from the client to the MTS server.&nbsp; Same concept for database
    calls.
    <p>2. Design business and data objects to pass data back to the GUI instead
    <br>of loading a business object (class/collection) and loading GUI controls
    <br>from the business object.&nbsp; Then immediately destroy (set to nothing)
    the
    <br>business and data objects.&nbsp; The argurment here is that leaving
    MTS objects
    <br>active keeps transactions open too long and eats up resources.
    <p>3.&nbsp; Basically, objects in MTS should just look more like a BAS
    module with
    <br>functions that return values.
    <p>In my mind, if you are programming object, they should be designed with
    the
    <br>appropriate properties and methods.&nbsp; Wheather or not they are
    located on
    <br>the users PC or in MTS, the interface should not matter.&nbsp; Furthermore,
    MTS
    <br>is designed to manage the use of objects more efficiently.&nbsp; The
    points above
    <br>suggest a design that is not very object oriented.
    <p>Thanks for your feedback.</blockquote>
    </html>

    Share on Google+

  3. #3
    Eric Brown Guest

    Re: Thin Objects for Better Performance


    Dave,
    There is some truth in what you've been told.
    1. This suggests an improper implementation of a distributed component.
    It says that 'stateful' objects are being used as opposed to 'stateless'.
    MTS is intended for stateless object deployment, so that resources can be
    created JIT (just in time) and their resources can be released as soon as
    possible. There are a couple of good articles on MSDN that address the general
    approach for Windows DNA (Distributed InterNet Application) implementation.

    http://msdn.microsoft.com/library/de...sign_intro.htm

    2. The objects themselves BELONG in the middle and presentation tiers.
    There is nothing evil about having them there and using an object in your
    client code. What IS evil is if you use a remote server to serve an OBJECT,
    rather than data. The data services tier shouldn't even care what object
    it's getting - it should just fulfill a request for data that's passed back
    all at once - NOT a reference to an object that exists in ITS process. If
    you do the latter, that's when you incur the client/server roundtrip everytime
    you set or retrieve an attribute value. Boo!Hiss! Lean toward connecting
    only when you have a request, get the data, destroy the connection, and keep
    objects in the client layer. You then, of course, have to solve the concurrency
    issue that comes with stateless objects, but that's part of the price for
    performance in distributed apps.

    3. The interfaces between the tiers (in Microsoft-speak) are DCOM/COM+.
    Therefore, you must carefully design the inter-tier method calls - Give
    preference to a single function call with a large number of arguments over
    several simpler function calls as your inter-object communications approach.
    Follow the advice in the linked article above and you should be fine.

    I tend to agree with your summarization that the arguments presented suggest
    incorrect solutions to problems arising from not using the DNA architecture
    correctly.

    Eric Brown


    "Dave Fleischman" <DFleisch@visto.com> wrote:
    >
    >Can anyone tell me if it is better to design objects as described below

    to
    >improve performance and limit overhead? Some people I work with are arguing
    >these points with me.
    >
    >1. Limit the use of properties because they require additonal round trips
    >from the client to the MTS server. Same concept for database calls.
    >
    >2. Design business and data objects to pass data back to the GUI instead
    >of loading a business object (class/collection) and loading GUI controls
    >from the business object. Then immediately destroy (set to nothing) the
    >business and data objects. The argurment here is that leaving MTS objects
    >active keeps transactions open too long and eats up resources.
    >
    >3. Basically, objects in MTS should just look more like a BAS module with
    >functions that return values.
    >
    >In my mind, if you are programming object, they should be designed with

    the
    >appropriate properties and methods. Wheather or not they are located on
    >the users PC or in MTS, the interface should not matter. Furthermore, MTS
    >is designed to manage the use of objects more efficiently. The points above
    >suggest a design that is not very object oriented.
    >
    >Thanks for your feedback.


    Share on Google+

  4. #4
    Flacco Guest

    Re: Thin Objects for Better Performance

    > The points above
    > suggest a design that is not very object oriented.


    I think you're right about this and this was my biggest stumbling block to
    accepting the way ASP/MTS work. I do believe that you're forced to diverge
    rather significantly from your logical design when you implement it using
    stateless components. Nonetheless, the popular wisdom is that you must do
    this to get scalability in that environment.






    Share on Google+

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