Components vs Objects

[Oliver Lennon]

Currently I am currently designing an n-tier system (Win32 client, MTS/DCOM
& RDBMS). From what I can determine there are two approaches - build components
that wrap up all the functionality of business objects and data objects and
expose an API to the client (all components running on the server) OR bring
the business object layer to the client (and hence exposing the objects and
their attributes etc) and leave the data objects on the server with basic
datatypes being passed between the two (to overcome DCOM marshalling of parameters
with many network roundtrips).

The client and business/data objects will all be written using VB6.

I have used the component exposing API and maintaining state on the server
with a thin client (browser based) before and it was quite good, but was
limited in that we could not manipulate the business objects at the client
(just basic datatypes returned). Someone has suggested moving the object
layer to the front end to give more OO benefit when manipulating data for
the GUI.

All thoughts welcomed!

Oliver

[Paul F]

I guess for a Win32 Client App the idea of a thin client isn't a major concern
(compared with a web based app). In this case it might be an idea to keep
your business logic in objects on the client side communicating with server
side object (data access) that reside in MTS. The reason for this is that
MTS really only work wells with Stateless objects and infact is recommended
that as little state as possible be placed in your server side objects(though
there are exceptions in some cases). In the case of passing data across machine
boundaries ADO provides an excellent alternative. It has a rich API and it
also looks after marchalling itself across machine boundaries so you don't
have to concern yourself with mingling with DCOM API's.
Another reason for moving client objects to the client side is to minimize
the round trips to your server machine when accessing object attribute/methods.

Also, how scalable does your app have to be. If you have a lot users accessing
the same objects on the same server machine, the server resources could get
choked up pretty quick. Remember in a web-based app, you could nearly consider
the web server as your client machine and MTS as your server machine as far
a load balancing goes (A browser doens't constitute a client in a Client/Server
type environment)

My suggestion:
Client side -> GUI with business objects
Server side -> Stateless data access objects
ADO to communicate between the two.


"Oliver Lennon" <o.lennon@stranmillis.fsnet.co.uk> wrote:
>
>Currently I am currently designing an n-tier system (Win32 client, MTS/DCOM
>& RDBMS). From what I can determine there are two approaches - build components
>that wrap up all the functionality of business objects and data objects
and
>expose an API to the client (all components running on the server) OR bring
>the business object layer to the client (and hence exposing the objects
and
>their attributes etc) and leave the data objects on the server with basic
>datatypes being passed between the two (to overcome DCOM marshalling of
parameters
>with many network roundtrips).
>
>The client and business/data objects will all be written using VB6.
>
>I have used the component exposing API and maintaining state on the server
>with a thin client (browser based) before and it was quite good, but was
>limited in that we could not manipulate the business objects at the client
>(just basic datatypes returned). Someone has suggested moving the object
>layer to the front end to give more OO benefit when manipulating data for
>the GUI.
>
>All thoughts welcomed!
>
>Oliver
>

[Paul F]

Why the distinction between Components and Objects?

"Oliver Lennon" <o.lennon@stranmillis.fsnet.co.uk> wrote:
>
>Currently I am currently designing an n-tier system (Win32 client, MTS/DCOM
>& RDBMS). From what I can determine there are two approaches - build components
>that wrap up all the functionality of business objects and data objects
and
>expose an API to the client (all components running on the server) OR bring
>the business object layer to the client (and hence exposing the objects
and
>their attributes etc) and leave the data objects on the server with basic
>datatypes being passed between the two (to overcome DCOM marshalling of
parameters
>with many network roundtrips).
>
>The client and business/data objects will all be written using VB6.
>
>I have used the component exposing API and maintaining state on the server
>with a thin client (browser based) before and it was quite good, but was
>limited in that we could not manipulate the business objects at the client
>(just basic datatypes returned). Someone has suggested moving the object
>layer to the front end to give more OO benefit when manipulating data for
>the GUI.
>
>All thoughts welcomed!
>
>Oliver
>

[Liam Grossmann]

Oliver,

I think as long as the business objects are coded as classes, there is no
issue where you deploy them. However, if you need to make changes to the
business logic, you'll obviously have to redistrbute the DLLs to all the
client machines.

If you ever need to port the application to run from the web, you'll need
to make sure that the business objects do maintain state. Otherwise the application
won't scale.

Liam
http://www.vbexpress.com.


"Oliver Lennon" <o.lennon@stranmillis.fsnet.co.uk> wrote:
>
>Currently I am currently designing an n-tier system (Win32 client, MTS/DCOM
>& RDBMS). From what I can determine there are two approaches - build components
>that wrap up all the functionality of business objects and data objects
and
>expose an API to the client (all components running on the server) OR bring
>the business object layer to the client (and hence exposing the objects
and
>their attributes etc) and leave the data objects on the server with basic
>datatypes being passed between the two (to overcome DCOM marshalling of
parameters
>with many network roundtrips).
>
>The client and business/data objects will all be written using VB6.
>
>I have used the component exposing API and maintaining state on the server
>with a thin client (browser based) before and it was quite good, but was
>limited in that we could not manipulate the business objects at the client
>(just basic datatypes returned). Someone has suggested moving the object
>layer to the front end to give more OO benefit when manipulating data for
>the GUI.
>
>All thoughts welcomed!
>
>Oliver
>