Thin Objects for Better Performance

Dave Fleischman · 06-16-2000, 11:15 AM

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.

Bill Slater · 06-16-2000, 12:25 PM

<!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.
 <a href="http://msdn.microsoft.com/workshop/server/components/vbmtsiis.asp">Web
Workshop - Developing a Visual Basic Component for IIS/MTS</a>
HTH
  
Dave Fleischman wrote:
<blockquote TYPE=CITE>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.</blockquote>
</html>

Eric Brown · 06-26-2000, 04:06 PM

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.

Flacco · 08-18-2000, 02:10 PM

> 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.

Thread: Thin Objects for Better Performance

Thread Tools

Display

Thin Objects for Better Performance

Re: Thin Objects for Better Performance

Re: Thin Objects for Better Performance

Re: Thin Objects for Better Performance

Posting Permissions