Design patterns

[Ronadl]

Hey all,

Just got done looking at an article on MSDN regarding a design pattern called
Engine-Collection-class. You can find this featured on the MSDN Home page.
I was curious what y'all thought of it and I wanted to add a few comments
of my own, or ask a few questions. Here goes.

This looks like a well thought out pattern but while it purports to be friendly
for nTier development it also seems to be very stateful. Am I reading that
correctly? Along these lines, statefulness seems to be a huge design no-no
in COM+ development. Almost to the point that even a little is to be quickly
designed out.

We are writing our first distributed app within our IT shop, and we want
to avoid many of the mistakes that can be made with a DNA application; Implementing
this design pattern looks like it would be a mistake. Any opinions?

In our search for help in designing the application, we have looked at Duwamish
Books 4 and FMStocks, both of which seemed to be designed with scalability
and performance first. My concern is that they are both relatively simple
applications with only four or five objects, their OLTP style design would
be easy to manage. But if the number of business objects you need are 15
to 20, this design would have the performance but would be a bit of a nightmare
to maintain, right? Duwamish has no discrete objects just a business layer
performing business transactions, if you multiply the needed transaction
methods times 10, these objects would resemble the client apps we're trying
to replace, yuk. FMStocks 2000 at least groups the transaction methods in
stateless objects (account related transactions in the Account object) but
no real pattern (add, change, delete, update, fetch, search, etc)

Does anybody feel strongly for a design pattern that would be a balance of
maintainability and performance?

Sorry to ramble, I'm been combing the web for days looking for a good balanced
middle tier design for COM+... not much out there.

rfp

[Yves Reynhout]

Design patterns are nice, but should only be used to help you solve certain
problems, not for the sake of having a design pattern in your application.

"Ronadl" <rfphillips_remove_@pub.mcleodusa.com> wrote in message
news:39beabe7$1@news.devx.com...
>
> Hey all,
>
> Just got done looking at an article on MSDN regarding a design pattern
called
> Engine-Collection-class. You can find this featured on the MSDN Home
page.
> I was curious what y'all thought of it and I wanted to add a few comments
> of my own, or ask a few questions. Here goes.
>
> This looks like a well thought out pattern but while it purports to be
friendly
> for nTier development it also seems to be very stateful. Am I reading
that
> correctly? Along these lines, statefulness seems to be a huge design
no-no
> in COM+ development. Almost to the point that even a little is to be
quickly
> designed out.

There's nothing against statefullness in COM+. You just need to be
selective about where you use it. I wouldn't use this kind o' pattern for a
Website/-application, but possibly for a Win32 client oriented application.

> We are writing our first distributed app within our IT shop, and we want
> to avoid many of the mistakes that can be made with a DNA application;
Implementing
> this design pattern looks like it would be a mistake. Any opinions?
>
> In our search for help in designing the application, we have looked at
Duwamish
> Books 4 and FMStocks, both of which seemed to be designed with scalability
> and performance first. My concern is that they are both relatively simple
> applications with only four or five objects, their OLTP style design would
> be easy to manage. But if the number of business objects you need are 15
> to 20, this design would have the performance but would be a bit of a
nightmare
> to maintain, right?

The size of your application (in terms of BO) shouldn't be a concern, but
every phase of your development cycle should.

> Duwamish has no discrete objects just a business layer
> performing business transactions, if you multiply the needed transaction
> methods times 10, these objects would resemble the client apps we're
trying
> to replace, yuk. FMStocks 2000 at least groups the transaction methods in
> stateless objects (account related transactions in the Account object) but
> no real pattern (add, change, delete, update, fetch, search, etc)

Well, patterns are nice in an object-oriented environment, not in a
service-oriented environment. Believe me, developing for MTS/COM+ is more
about service-oriented than object-oriented.

> Does anybody feel strongly for a design pattern that would be a balance of
> maintainability and performance?
>
> Sorry to ramble, I'm been combing the web for days looking for a good
balanced
> middle tier design for COM+... not much out there.
>
> rfp

Best Reg.,
Yves Reynhout - http://www.orbidsmartx.com