|
-
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.
-
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> <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>
<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? 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. 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. Then immediately destroy (set to nothing)
the
<br>business and data objects. The argurment here is that leaving
MTS objects
<br>active keeps transactions open too long and eats up resources.
<p>3. 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. Wheather or not they are
located on
<br>the users PC or in MTS, the interface should not matter. Furthermore,
MTS
<br>is designed to manage the use of objects more efficiently. The
points above
<br>suggest a design that is not very object oriented.
<p>Thanks for your feedback.</blockquote>
</html>
-
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.
-
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Development Centers
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center
|
