Components vs Objects


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Components vs Objects

Hybrid View

  1. #1
    Oliver Lennon Guest

    Components vs Objects


    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

    Share on Google+

  2. #2
    Paul F Guest

    Re: Components vs Objects


    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
    >


    Share on Google+

  3. #3
    Paul F Guest

    Re: Components vs Objects


    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
    >


    Share on Google+

  4. #4
    Liam Grossmann Guest

    Re: Components vs Objects


    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
    >


    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