Exposing Business Layer Objects to Presentation Layer

[dan]

I've seen lots of postings around this issue, however I may need some
more info especially with the limitations that my project introduces.

I'm in the process of designing the presentation layer of my web-based
network management application. My concern is regarding the way the
business layer objects should (or maybe they shouldn't at all??) be
exposed to the presentation. Why exposing business objects to the
presentation may be problematic? At least in my case the business
objects represent a live pool of related objects - network entities, a
hierarchy that gets constructed and modified periodically from the
persistency regardless of the presentation requests. That is, the
objects are there because they are part of some use cases that may not
involve the presentation layer. In addition the Business class
hierarchy is of course not built for a specific presentation and some
of the business layer logic is intrinsic to the business layer itself.

For example, some of the flows are only known to the Business layer
and not to the presentation layer, some of the presentation uses are
delegated to other business objects that perform some action and
return data to the presentation, and some of the presentation objects
are sort of combinations of business objects.

I may be wrong here but as I see it providing a common interface to
the business objects for both business and presentation is wrong since
it will result in endless methods for each object. Providing a common
data part for each business object that will be used by presentation
and business will violate the encapsulation policy of the business
objects since presentation would be familiar with the internal state
or implementation of the business objects. However creating a
presentation layer representation for every object in the business
layer also seems a bit cumbersome...

So the question is how should the business layer objects be exposed or
transfered to the presentation layer. I believe that this problem is
widely addressed by many projects - in fact I can't imagine any tiered
project that doesn't introduce this kind of concerns. However I
couldn't find any design pattern that perfectly addresses this
problem. I was wondering if the Builder pattern or the AbstactFactory
pattern may fit here but being unexperienced with those I'm not sure.

Your help is greatly appreciated

TIA,

DK

Thank you all for the detailed and helpful answers!

DK

 

[Shane Mingins]

The example dialog box that puts up a list of employees with a
terminate button.

So in that example the EmployeeTerminatorView interface is the
"Presentation" layer of Model-View-Presenter-Controller in that it hides the
actual View implementation from the Controller? Therefore you could replace
the Swing implementation of the View with an HTML or Text UI implementation.

Have I got it?

Cheers
Shane

----------------------------------------------------------------------------

 

[Universe]

To start again emphasizing the big overall picture for Dan, the
architecture should roughly have this kind of a skeletal or core layered
topology:

UI/Presentation
----"aPI"---- // "abstract Polymorphic Interface" - an
abstract facade
Business model
----"aPI"---- // aPI's could be an abstract COM/Corba
entity; a set of abstract class factories, etc
Data model

This is the "canonical" layered architectural topology that nowadays is
used almost everywhere for your typical, or average business, technical,
or other application--for nearly all OOPLs, older structured paradigm
3GLs, application frameworks, libraries, etc.

Note that is a *rough*, "sense of" diagram. Usually the 3 main
layers/tiers have sublayers and the nature of many of these sublayers
have been at least superficially hit upon and discussed in the course of
this thread. Eg. the Data model often has a sublayer of objects that
directly access a lower datastore (database) sublayer. Typically large
complex projects have multiple databases (datastores) in that layer.
Ie. MySQL, DB3, Oracle, etc.

And given these kind of large, complex projects there are often one or
more "transaction managers" usually residing as a sublayer in either the
Business, or Data layers or slipping somewhere in between, as a layer in
its own right.

Also certainly the UI/Presentation layer above has sublayers. These are
frequently in fact divided into separate Presentation and UI sublayers,
but just as often there are many projects where there is no distinct
division between the 2 kinds of responsibilities. It may be that one
is a slither relative to the other, or given the requirements and
character of the particular system the logical need for subdividing
simply doesn't make itself felt.

We don't want the business objects knowing about the presentation
layer because then the business logic would be constrained by the
presentation. On the other hand we don't mind that the presentation
layer knows about the business layer since the presentation layer is
already constrained by the business.

The key thing for layered architectures, and this is a point xp/rcm
falter badly on, is that *overall* physical dependencies should flow
from top to bottom. When this is true, lower levels may be compiled.
linked and put into operation without the need for upper (higher) layers
being present.

While inherited type classes generate *1* form of dependency between an
interface and its one or more implementations where dependency flows
"up" from the interface to the implementation, *overall* from a larger
system perspective it would be ridiculous to have most system dependency
flowing upward as RMartin's harmful and confused 'dip' (he calls the
dependency inversion principle) would have it.

If most system dependency flowed 'upward' it would be *impossible* to
compile and link and get *any* lower layers operating before *some*
suitable higher layer had been compiled and linked. Think about it.

We want to have say our systems' number crunching engine able to get
going *before* we had to have a suitable higher layer UI, or
Presentation layer operating. But Robert Martin's 'dip' stresses that
we want a system's lower layers to physically depend (to compile and
link) upon higher layers! For RCM, *that* is the a cornerstone of the
"proper" handling of OO dependency. I hope now that more see 'dip' for
what it really is, harmful, deleterious, and just downright a stinker of
bad software engineering design theory/principle?

Elliott

 

[Universe]

** Typo: Should be ***

UI/Presentation
----"aPI"----
Business model
----"aPI"----
Data model


[email protected]...

To start again emphasizing the big overall picture for Dan, the
architecture should roughly have this kind of a skeletal or core layered
topology:

UI/Presentation
----"aPI"---- // "abstract Polymorphic Interface" - an
abstract facade
Business model
----"aPI"---- // aPI's could be an abstract COM/Corba
entity; a set of abstract class factories, etc
Data model

** Should be ***

UI/Presentation
----"aPI"----
Business model
----"aPI"----
Data model

 

[Universe]

While inherited type classes generate *1* form of dependency between an
interface and its one or more implementations where dependency flows
"up" from the interface to the implementation, *overall* from a larger
system perspective it would be ridiculous to have most system dependency
flowing upward as RMartin's harmful and confused 'dip' (he calls the
dependency inversion principle) would have it.

Corrected and better:

Inheritance type class hierarchies generate *1* form of dependency between
the hierarchy interface and its one or more derived concrete
implementation classes. This is a
** PHYSICAL (compilaton and linking) inheritance) **
dependency.
** versus equally important LOGICAL dependency. (Logical dependenct
is _never_ or
hardly _ever_ mentioned by RCM, nor RCM's original source for
this confusion
surrounding physical inheritance dependency, Grady Booch) **
This inheritance physical dependency flows from a concrete implementation
class to the interface of the class hierarchy.

RCM and Booch incorrectly fetishize and get stuck on pointing that the
direction of the physical dependency between the interface and concrete
implementation class flows in the "upward" direction.

RCM errantly believes that most systems outside of, and prior to, the
current heyday of OO chiefly had physical dependencies that "flow" in a
"downward" direction. This is wrong.

And further we *wamt* most both logial and psjhycal dpemncty to flow
*downward* to generally acievei the msot optiam system desing, atlkin into
acocutn the key OO and otehr sw enineeign desigbn foactrs acoss all fronts.

Stuck one aspect - class type strcuture (vs myraid of other places physiacl
dependnecy is generated in a system) - of one aspect - physical dependency
(vs logical). This stems from their super conservative, pradgmatosm. Blind
or hard to see the logical and blind or hared to see nathing oheer thab
inheriance dependencgt withn pshyical dependcy. It's a shame and itgs a
shame given their opiurtunims that hoes hand in hand owht theor ugly, ultra
reattgionary progamntism. Exists tin a;ll fields and in sofwtare enginerin
it's called "Craftistry".

Sorry about typos will clean up later.

Elliott
..



flowing
** implementation to the interface ** to the, *overall* from a larger

system perspective it would be ridiculous to have most system dependency
flowing upward as RMartin's harmful and confused 'dip' (he calls the
dependency inversion principle) would have it.

 

[Uncle Bob (Robert C. Martin)]

So in that example the EmployeeTerminatorView interface is the
"Presentation" layer of Model-View-Presenter-Controller in that it hides the
actual View implementation from the Controller? Therefore you could replace
the Swing implementation of the View with an HTML or Text UI implementation.

Have I got it?

Yes. I wrote that segment before the Model-View-Presenter vocabulary
was fixed in my mind. But the idea is the same.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc. | unclebob @ objectmentor . com
501 N. Riverside Dr.| Tel: (800) 338-6716
Suite 206 | Fax: (847) 775-8174 | www.objectmentor.com
| | www.XProgramming.com
Gurnee, IL, | Training and Mentoring | www.junit.org
60031 | OO, XP, Agile, C++, Java, C# | http://fitnesse.org