Newbie n-Tier / OO Design Questions

[Terry Paterson]

Hi There,

I'm working on creating the middle-tier of a three tier system - the
system is an inventory control system, and is supposed to replace an
existing char based, xBase system.

I want to represent all of my inventory items (parts) as instances of
a PART class, which has various instance variables - age, vehicle
model, vehicle year, part type, colour, mileage, price, condition,
status, etc, and then of course various getter/setter methods.

now -- my question is -- will one class be sufficient to represent all
the usages of part data ?

i.e. if I wanted to update the prices of all the engines in the
existing system I could do something like ( UPDATE inventory SET
price=price*1.10 WHERE parttype='ENGINE' )

but if I want to deal only with objects presumably I would need to
construct a method which gets references to all of the required PART
objects, and then call some method on each object to update the price
? which seems rather in-efficent compared to the previous SQL..

I should also mention that part of the reason I'm thinking I'd have to
do it this was is that I hoped to use the Observer/Observable pattern
on my PART objects so that multiple users across the network could be
looking at the same PART objects and be notified if any of it's
properties changed -- i.e. the users would infact have references to
the SAME part object.

is this a sensible way to go about things ? is there a better way to
perform batch updates ? does is make sense to give users on different
PCs references to the same part objects on the middle-tier ?

any help / suggestions would be much appreciated !

 

[Jacob]

I'm working on creating the middle-tier of a three tier system - the
system is an inventory control system, and is supposed to replace an
existing char based, xBase system.

I want to represent all of my inventory items (parts) as instances of
a PART class, which has various instance variables - age, vehicle
model, vehicle year, part type, colour, mileage, price, condition,
status, etc, and then of course various getter/setter methods.

now -- my question is -- will one class be sufficient to represent all
the usages of part data ?

Depends on the diversity of parts. Start with a Part base class
and see how far you can get. Don't try to stretch things if it
doesn't fit. Subclass it if it gets too messy.

i.e. if I wanted to update the prices of all the engines in the
existing system I could do something like ( UPDATE inventory SET
price=price*1.10 WHERE parttype='ENGINE' )

If price is a common property, have it in the Part base class
and you can update it for all parts as you indicate.
(And make sure you leave SQL out of the middle tier

but if I want to deal only with objects presumably I would need to
construct a method which gets references to all of the required PART
objects, and then call some method on each object to update the price
? which seems rather in-efficent compared to the previous SQL..

I should also mention that part of the reason I'm thinking I'd have to
do it this was is that I hoped to use the Observer/Observable pattern
on my PART objects so that multiple users across the network could be
looking at the same PART objects and be notified if any of it's
properties changed -- i.e. the users would infact have references to
the SAME part object.

is this a sensible way to go about things ? is there a better way to
perform batch updates ? does is make sense to give users on different
PCs references to the same part objects on the middle-tier ?

This is sensible. Consider the JMS for doing event handling
in a distributed environment.

 

[Steve]

now -- my question is -- will one class be sufficient to represent all
the usages of part data ?

i.e. if I wanted to update the prices of all the engines in the
existing system I could do something like ( UPDATE inventory SET
price=price*1.10 WHERE parttype='ENGINE' )

but if I want to deal only with objects presumably I would need to
construct a method which gets references to all of the required PART
objects, and then call some method on each object to update the price
? which seems rather in-efficent compared to the previous SQL..

You've pretty much hit the nail on the head. Domain models (i.e.
defining classes for parts, engines etc) are great for designing the
system and ensuring you capture all the right attributes and
behaviour. The one big failing (IMHO) of such systems is exactly this
type of operation.

You have a few choices...
1) Put up with the inefficiency and do as you suggested; I.e. when you
need to update the price of every engine you create a collection of
all engines and on each one call "setPrice(originalPrice *
increaseFactor). If you have a large collection this will be potential
very slow.

2) keep the model for all your main business but put in sneaky "admin"
function which is just a wrapper to the SQL code to do the update. Not
nice from an architectural point of view perhaps, but it will be
quick. Will get the job done but if you change your object-relational
mapping this may break your "admin" code. If you are confident your
data model is fixed then I'd do this anyway.

3) You could design you "part" object to be more lightweight, consider
useing lazy evaluation. That way if you choose option (1) you don't
end up retreiving huge amounts of data you don't need, you only need
to get/set the price in this example. Lasy evaluation is a neat trick
but may have a negative impact in other areas because you have to keep
going back to the database for each attribute.

I can recommend "Patterns of Enterprise Application Architecture"
By Martin Fowler for discussions of this and other related issues.

HTH.

Steve

~ If emailing, please use: Steve_A_Haigh
~ @
~ hotmail.com
~

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

Hi There,

I'm working on creating the middle-tier of a three tier system - the
system is an inventory control system, and is supposed to replace an
existing char based, xBase system.

Your messaged failed to specify how data is being communicated between the
tiers. Are you serializing objects, using CORBA, text, or brewed your own
XML. How does the communication between the tiers reflect or influence the
design your proposing?

I want to represent all of my inventory items (parts) as instances of
a PART class, which has various instance variables - age, vehicle
model, vehicle year, part type, colour, mileage, price, condition,
status, etc, and then of course various getter/setter methods.

now -- my question is -- will one class be sufficient to represent all
the usages of part data ?

i.e. if I wanted to update the prices of all the engines in the
existing system I could do something like ( UPDATE inventory SET
price=price*1.10 WHERE parttype='ENGINE' )

Are all your parts the same kind of part? Are they all cars? How many
different kind of parts are there? How is the data modeled in the database?
Proposing object design be /totally/ independent of the database is
academically appealing but not always practical. To say that your object
model has only one kind of part when the database has multiple types of parts
(distinguished by their properties) or that your object model supports
multiple part types while the database does not will cause all sorts of headaches.

Additionally, though some of the part properties were listed the messages
failed to specify how many of them we're really interested in. Are they used
for anything other than for storing? Will the objects actually behave
differently in the system based on their properties, or are the objects just
containers for a list of properties? In the case of the latter you don't need
a PART class, you just need associations (a dictionary) for each part/tuple.

but if I want to deal only with objects presumably I would need to
construct a method which gets references to all of the required PART
objects, and then call some method on each object to update the price
? which seems rather in-efficent compared to the previous SQL..

If you wanted to deal only with objects you would use an object database and
an object language--neither of which is probably being used so your design
will straddle both and translate between them.

That said, instantiating every part from the database (reading RDB rows and
creating a collection of parts for each) to satisfy a soft requirement of
dealing only with objects will create more work than implementing a
transaction that ultimately executes SQL in the back.

I should also mention that part of the reason I'm thinking I'd have to
do it this was is that I hoped to use the Observer/Observable pattern
on my PART objects so that multiple users across the network could be
looking at the same PART objects and be notified if any of it's
properties changed -- i.e. the users would infact have references to
the SAME part object.

it may be possible to implement that mechanism more easily be leaning on the
database for more help. To implement it all in your application may required
you to cache more data than is practical or desireable in a middle tier. The
database may be a good place for that. How real-time are the requirements for
these people watching inventory?

 

[Jacob]

Your messaged failed to specify how data is being communicated between
the tiers. Are you serializing objects, using CORBA, text, or brewed
your own XML. How does the communication between the tiers reflect or
influence the design your proposing?

A common mistake. The business tier must *never* get influenced
by the implementation practicalities of the surrounding system.
The business tier should model real world concepts and processes
only!

 

[Terry Paterson]

<snip>


Hi Guys,

Thanks for all the replies - very helpful, a few more questions if I
may


Jacob :

"And make sure you leave SQL out of the middle tier "

Can you give me a bit more explanation of this ?
I thought this was exactly the place I would put the SQL ?

i.e. my front/end client tier would talk only in terms of objects to
the middle tier (via RMI),
and my middle tier would then talk to the database via SQL ?


Thomas :

"Your messaged failed to specify how data is being communicated between the tiers.
Are you serializing objects, using CORBA, text, or brewed your own XML.
How does the communication between the tiers reflect or influence the

design your proposing? "

I'm pretty new to this stuff and at the moment I've just been using
RMI, and the built-in serialization mechanisms
(I know I can manually override these - but at the moment I'm just
trying to figure out how to go about designing my class's),
I also know I could use CORBA - but since this app is going to be all
Java - it seems simpler to use RMI.


Steve :

(You could design you "part" object to be more lightweight, consider useing lazy evaluation)

sorry - the term "lazy evaluation" is new to me ? I presume this means
something like only loading the various properties as and when they
are needed ?


and for a bit more overview about what I'm doing :


The application will be all Java, probably a Java Application as the
front-end rather than an applet / JSP / etc..


The database structures I will be accessing in the SQL server are
already well defined,

each part is treated individually (these are recycled
car/van/automobile parts)
- each one is unique - different condition, different mileage, donor
vehicle, etc, etc .., no widgets involved !

all of the parts are held in one table,
there can be between 10,000 and 500,000 parts depending on the site.

only dealing with fairly major/large/valuable items -- Engines,
Transmissions, Doors, body panels, alternators, ECUs,
- no brackets, trim, spacers, washers, nuts + bolts, etc...

and I don't imagine I'll need seperate subclass's for Engine,
Transmission, Drivers Door, etc -- or even by grouping i.e. Body
Parts, Mechanical Parts, etc .. they really don't behave differently
depending on there properties.


however - what I was really asking was :

I could create an all singing - all dancing PART class which has all
of the properties and methods which would be required throughout the
system,
but I did wonder if this might be a little bit of overkill ?
- especially when performing any sort of batch operation
(generating a report, updating a group of parts at once - like the
updating the price of all the engines)

however - after all of your replies I've been thinking about it a
little more and don't see it as such a big problem,
I guess I was still thinking about our existing xBase product in terms
of reports, etc - and thinking that my front tier/client
would have to deal with individual part records and actually generate
the report
- but of course there's no reason for the database + middle tier not
to generate the report
and then feed back some sort of custom report object to the front
tier/client.



oh -- and thanks for the e-mail Sean -- hopefully the above gives you
a better idea of what I'm working on !


T

 

[Jacob]

Can you give me a bit more explanation of this ?
I thought this was exactly the place I would put the SQL ?
i.e. my front/end client tier would talk only in terms of objects to
the middle tier (via RMI),
and my middle tier would then talk to the database via SQL ?

The business tier should concern itself with domain
business exclusively. The persistence tier deals with
storage. In your case you happen to be connected to a
DB and your persistence tier should reflect that fact.
Later you might decide to change the setup, and you
don't want the business level to be influenced by it.

The persistence tier is a separate piece of code that
(in your case) communicates with the database.
In your example piece of code you don't have a separate
persistence tier (remember the database itself is not
a "tier" as such, no more than the end user is a "tier").

 

[=?ISO-8859-1?Q?Thomas_Gagn=E9?=]

A common mistake. The business tier must *never* get influenced
by the implementation practicalities of the surrounding system.
The business tier should model real world concepts and processes
only!

Perhaps I wasn't clear because how requests are communicated between a client
and a server can influence the design of the server. If the client sends
RPC-like requests and expects answers that look like objects, that can impact
what the server does (or does not do). Does it need to express its answers as
objects? XML? TDS? Maybe it's not necessary to have invoice objects at all
and it's perfectly satisfactory to deal with arrays of information from the
database? Or if something more than arrays, then perhaps a different kind of
composition? Depending on the amount of work involved it may be more work to
convert to an answer or from a request than makes sense to do the work in
something completely different. I'm not suggesting he changes paradigms or
algorithms, just consider the relationship.