Microsoft: Objects vs. Components?

Microsoft: Objects vs. Components?

Post by No e-mail pleas » Sat, 24 Jul 1999 04:00:00



I'm tackling my first n-tier OO project using SQL Server, NT Server, MTS,
and VB6.

I realize VB is not particularly OO-pure, and in part that is what this post
is about.  I'd appreciate any thoughts/opinions in reply.

MSDN has a sample project called Duwamish Books, including source code for
the various tiers.  Looking over the code, I'm struck by the degree to which
well-formed business objects have been sacrificed for the sake of optimizing
the tiers.

The Business Logic Layer contains three classes - one holds methods that are
transactional, another non-transactional, and a third for methods that
support (but do not require) transactions.

For example, the transactional class contains these methods:
   InsertOrder
   InsertSale
   UpdateOrder

The nontransactional class contains methods like:
   GetAuthors
   GetEmployees
   GetOrders

...etc.

I believe they are partitioned in this way so that their transactional
behavior can be set in MTS.  But this design really seems to completely
disregard the application's business classes.  Basically, it's just a
laundry list of functions stuffed into a class, and the classes are entirely
based on an implementation issue (transaction support) instead of business
concepts.

In the Client code (UI layer), there are classes like COrder, CAuthor, etc.,
but they just consist of property gets/lets.  There appears to be no
processing at all going on inside these classes.  Instead, a lot of the
processing for many of the classes is lumped into a code module named
CTPresentation.

I would expect the classes themselves to have operations like:

   oOrder.Load(...)
   oOrder.Update

...etc.

It seems that classes are simply used to hold a bunch of methods from the
same tier without any regard for creating well-formed business objects.  It
seems a great deal of attention is given to the multi-tiered aspects of the
project, not much to object orientation.

Is there some way to keep the automated transaction management without
totally disintegrating logical classes into tier-oriented components?  Do we
have to completely sacrifice the design for performance reasons?

Also, there is much talk about "stateless" components being ideal for
hosting in MTS.  If you take away the state, basically we're talking about a
bunch of function calls, right?  Doesn't this mean we've thrown away much of
the design advantages that come with OO?

Does anyone else have any thoughts on this??  As I said, I'm new to this,
and perhaps I'm missing something.  Maybe my "world view" is a little skewed
by the OO texts I've been reading...  On one hand I want to get going and
get
this project underway, and on the other, I'm hesitant to start a project
that uses
a design I find questionable.

I would love to get some feedback on this - especially from developers
who have encountered this before and found  a way to do it and still sleep
well at night!

Thanks!

 
 
 

Microsoft: Objects vs. Components?

Post by Ethan Smit » Sat, 24 Jul 1999 04:00:00


I Couldn't agree more with your assessment of the Duwamish sample project.
I found it's architecture to be totally lacking, and I pity any person who
uses that as a basis for a project.  unfortunately, you will find that there
are 2 main forces that come into play when building distributed systems
based on MS technology.  The first is a good object model, and the second is
the plethora of data centric technologies currently available.
Unfortunately they seem to be at odds with each-other.  If you design a good
object model, you will not have a simple way to bind your objects data to
GUI widgets, and you will have to develop a OR mapping layer that performs
well.  On the other hand if you want to use SQL's set processing and ad-hoc
querying capabilities, and data binding widgets, you will find it hard to
stick to an object model.  you have to decide which is more important, and
what compromises you're willing to make.  if you have the money, and are not
wed VB/MTS, you might be interested in a company called Persistence.  For
another view on building MTS based solutions with some semblance of an
object model, look at
http://msdn.microsoft.com/library/techart/windnadesign_intro.htm
http://msdn.microsoft.com/library/techart/windnadesign_guide.htm

Good Luck.



Quote:

> I'm tackling my first n-tier OO project using SQL Server, NT Server, MTS,
> and VB6.

> I realize VB is not particularly OO-pure, and in part that is what this
post
> is about.  I'd appreciate any thoughts/opinions in reply.

> MSDN has a sample project called Duwamish Books, including source code for
> the various tiers.  Looking over the code, I'm struck by the degree to
which
> well-formed business objects have been sacrificed for the sake of
optimizing
> the tiers.

> The Business Logic Layer contains three classes - one holds methods that
are
> transactional, another non-transactional, and a third for methods that
> support (but do not require) transactions.

> For example, the transactional class contains these methods:
>    InsertOrder
>    InsertSale
>    UpdateOrder

> The nontransactional class contains methods like:
>    GetAuthors
>    GetEmployees
>    GetOrders

> ...etc.

> I believe they are partitioned in this way so that their transactional
> behavior can be set in MTS.  But this design really seems to completely
> disregard the application's business classes.  Basically, it's just a
> laundry list of functions stuffed into a class, and the classes are
entirely
> based on an implementation issue (transaction support) instead of business
> concepts.

> In the Client code (UI layer), there are classes like COrder, CAuthor,
etc.,
> but they just consist of property gets/lets.  There appears to be no
> processing at all going on inside these classes.  Instead, a lot of the
> processing for many of the classes is lumped into a code module named
> CTPresentation.

> I would expect the classes themselves to have operations like:

>    oOrder.Load(...)
>    oOrder.Update

> ...etc.

> It seems that classes are simply used to hold a bunch of methods from the
> same tier without any regard for creating well-formed business objects.
It
> seems a great deal of attention is given to the multi-tiered aspects of
the
> project, not much to object orientation.

> Is there some way to keep the automated transaction management without
> totally disintegrating logical classes into tier-oriented components?  Do
we
> have to completely sacrifice the design for performance reasons?

> Also, there is much talk about "stateless" components being ideal for
> hosting in MTS.  If you take away the state, basically we're talking about
a
> bunch of function calls, right?  Doesn't this mean we've thrown away much
of
> the design advantages that come with OO?

> Does anyone else have any thoughts on this??  As I said, I'm new to this,
> and perhaps I'm missing something.  Maybe my "world view" is a little
skewed
> by the OO texts I've been reading...  On one hand I want to get going and
> get
> this project underway, and on the other, I'm hesitant to start a project
> that uses
> a design I find questionable.

> I would love to get some feedback on this - especially from developers
> who have encountered this before and found  a way to do it and still sleep
> well at night!

> Thanks!


 
 
 

Microsoft: Objects vs. Components?

Post by patr.. » Sun, 25 Jul 1999 04:00:00



: MSDN has a sample project called Duwamish Books, including source
: code for the various tiers.  Looking over the code, I'm struck by
: the degree to which well-formed business objects have been
: sacrificed for the sake of optimizing the tiers.

: The Business Logic Layer contains three classes - one holds methods
: that are transactional, another non-transactional, and a third for
: methods that support (but do not require) transactions.

: For example, the transactional class contains these methods:
:    InsertOrder
:    InsertSale
:    UpdateOrder

: The nontransactional class contains methods like:
:    GetAuthors
:    GetEmployees
:    GetOrders

: ...etc.

: I believe they are partitioned in this way so that their
: transactional behavior can be set in MTS.  But this design really
: seems to completely disregard the application's business classes.

I have not seen this design before, so I am working without a net to
some extent in what I write here.

I do not see anything wrong with this initial partitioning if these
classes are designed to be "transactional command objects" and
"non-transactional command objects", following the Command pattern. As
presented I do not see enough information to say this is a poor
design. I assume that MTS, like EJB, requires these classes to
implement some abstract interface in order to be an object in the MTS
framework. These seem like "session beans" in EJB, (although they have
the dignity not to be called "beans".)

: In the Client code (UI layer), there are classes like COrder,
: CAuthor, etc., but they just consist of property gets/lets.  There
: appears to be no processing at all going on inside these classes.
: Instead, a lot of the processing for many of the classes is lumped
: into a code module named CTPresentation.

Again I do not see any problem with this per se. Think of these UI
objects as kind of like HTML files and the CTPresentation as kind of
like a browser. There may be times when you wish you had a more
sophisticated UI framework, but maybe this is "good enough"? If the
real business logic is on the server, these objects are simply
"command contexts" for the "command objects" that eventually get
executed on the server.

Many business systems can be boiled down to "Query for information;
Compose a proposal; Submit the proposal; Evaluate the proposal;
Succeed or fail; Repeat."  You may not be able to implement the
applications *you* are requiring with this, but perhaps 90 percent of
everyone else can.

: It seems that classes are simply used to hold a bunch of methods
: from the same tier without any regard for creating well-formed
: business objects.  

What is a "well-formed business object"?

: It seems a great deal of attention is given to the multi-tiered
: aspects of the project, not much to object orientation.

MTS is attempting to compete with the likes of BEA Tuxedo. The
patterns for getting Tuxedo to scale to thousands and thousands of
concurrent users are well known. They require an emphasis on the three
tiers in order to get that kind of scalability.

: Do we have to completely sacrifice the design for performance
: reasons?

It is not clear to me that there has been a great sacrifice, given the
requirements of MTS.

: Also, there is much talk about "stateless" components being ideal
: for hosting in MTS.  If you take away the state, basically we're
: talking about a bunch of function calls, right?  Doesn't this mean
: we've thrown away much of the design advantages that come with OO?

MTS is not really "stateless", rather the state is maintained on the
server and can be load balanced, etc. by implementing the "state
management" interfaces for the MTS framework. This is the same as for
EJB, no surprise.

: Does anyone else have any thoughts on this??  As I said, I'm new to
: this, and perhaps I'm missing something.  Maybe my "world view" is a
: little skewed by the OO texts I've been reading...

Most OO texts are not concerned with getting real systems up and
running, unfortunately.

--

 
 
 

1. Microsoft: Objects vs. Components?

I'm tackling my first n-tier OO project using SQL Server, NT Server, MTS,
and VB6.

I realize VB is not particularly OO-pure, and in part that is what this post
is about.  I'd appreciate any thoughts/opinions in reply.

MSDN has a sample project called Duwamish Books, including source code for
the various tiers.  Looking over the code, I'm struck by the degree to which
well-formed business objects have been sacrificed for the sake of optimizing
the tiers.

The Business Logic Layer contains three classes - one holds methods that are
transactional, another non-transactional, and a third for methods that
support (but do not require) transactions.

For example, the transactional class contains these methods:
   InsertOrder
   InsertSale
   UpdateOrder

The nontransactional class contains methods like:
   GetAuthors
   GetEmployees
   GetOrders

...etc.

I believe they are partitioned in this way so that their transactional
behavior can be set in MTS.  But this design really seems to completely
disregard the application's business classes.  Basically, it's just a
laundry list of functions stuffed into a class, and the classes are entirely
based on an implementation issue (transaction support) instead of business
concepts.

In the Client code (UI layer), there are classes like COrder, CAuthor, etc.,
but they just consist of property gets/lets.  There appears to be no
processing at all going on inside these classes.  Instead, a lot of the
processing for many of the classes is lumped into a code module named
CTPresentation.

I would expect the classes themselves to have operations like:

   oOrder.Load(...)
   oOrder.Update

...etc.

It seems that classes are simply used to hold a bunch of methods from the
same tier without any regard for creating well-formed business objects.  It
seems a great deal of attention is given to the multi-tiered aspects of the
project, not much to object orientation.

Is there some way to keep the automated transaction management without
totally disintegrating logical classes into tier-oriented components?  Do we
have to completely sacrifice the design for performance reasons?

Also, there is much talk about "stateless" components being ideal for
hosting in MTS.  If you take away the state, basically we're talking about a
bunch of function calls, right?  Doesn't this mean we've thrown away much of
the design advantages that come with OO?

Does anyone else have any thoughts on this??  As I said, I'm new to this,
and perhaps I'm missing something.  Maybe my "world view" is a little skewed
by the OO texts I've been reading...  On one hand I want to get going and
get
this project underway, and on the other, I'm hesitant to start a project
that uses
a design I find questionable.

I would love to get some feedback on this - especially from developers
who have encountered this before and found  a way to do it and still sleep
well at night!

Thanks!

2. Plymouth, MA Adelphia customer input wanted!

3. Microsoft VBScript runtime error '800a01ad' / ActiveX component can't create object

4. Switch from InterNotes R3 to InterNotes R4 (incl.) - No problem?

5. Component based vs. object oriented design

6. MáS PASTAAAAA!!!!!!!!!

7. Components vs objects

8. Newbie question - program to make my PC 'Alive' and active

9. Objects vs. components / building blocks

10. Objects vs Components

11. Apple vs. Microsoft (QT vs. AVI)

12. Object Domain vs With Class vs ?????

13. Microsoft Office Shortcut Bar's button component?