Exposing Business Layer Objects to Presentation Layer

dan · Oct 14, 2003

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

H. S. Lahman · Oct 14, 2003

Responding to 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.

This sort of situation is exactly where the conventional layered models
for RAD/USER applications start to break down. The models of the
presentation - Business - Data ilk all presuppose that the application
is basically USER in nature. IOW, it is just a pipeline between the DB
and the display whose only problem to solve is the transformation from
one view to the other.

[The reason such models exist is because these sorts of USER problems
form a very large fraction of IT applications; hence the rise of RAD
IDEs to prominence. The more complex layered infrastructures are a
similar sort of automation but at a somewhat lower level of abstraction
than a tool like MS Access.]

The difficulties arise when the problems being solved in the business
layer is of primary importance while display and persistence become
secondary concerns. In effect that introduces a third paradigm that
must be mapped. More important, that paradigm is inserted between the
UI paradigm and the DB paradigm. So instead of mapping

Page/Section <==> Table/Tuple (Browser)
Window/Control <==> Table/Tuple (GUI)

one must map

Page/Section <==> problem space paradigm <==> Table/Tuple
Window/Control <==> problem space paradigm <==> Table/Tuple

So all the convenient OTS layer interface infrastructures (e.g., DAO
objects) no longer quite play together.

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.

The short answer is: don't expose the objects in any layer to other
layers. Employ pure data transfer interfaces between the layers and let
those interfaces do the mapping of the data to their own paradigm.

The interfaces TO persistence and TO the UI will not change appreciably
because those paradigms don't change. However, one needs to encapsulate
the business problem solution within interfaces that are suited to its
paradigm. That means one must insert wrappers that understand how to
convert the UI-to-DB requests to UI-to-business and DB-to-UI to
DB-to-business.

For complex applications where UI and DB are peripheral services, the
general purpose model for subsystems (or layers) is:

+--------------+ +----------------+
| Subsystem A | | Subsystem B |
| | | |
| +------+ +------+ |
| | Aout |------------>| Bin | |
| +------+ +------+ |
| | | |
| +------+ +------+ |
| | Ain |<------------| Bout | |
| +------+ +------+ |
| | | |
+--------------+ +----------------+

where Ain and Bin are traditional input interfaces to the subsystem
(think: Facade pattern). Those interfaces are fixed regardless of reuse
context and they dispatch incoming data transfer messages (e.g., events)
to the relevant objects that implement the subsystem.

The Aout and Bout are output interfaces. The objects that implement the
subsystem talk to these interfaces whenever they need to send a message
to the outside world. The interface is also fixed so the subsystem
implementation always talks to the outside world the same way,
regardless of reuse context. The output interfaces also usually employ
a Facade pattern because the subsystem may need to talk to any of
several other subsystems.

For an original implementation the output interfaces will have trivial
implementations because the mapping will be designed to be 1:1 between
Xout messages and the other subsystem's Xin messages as a matter of good
systems engineering. However, in a reuse situation the interface the
client wants to use and the Xin interface provided may not match up
syntactically even though the service semantics is the same. In that
case the implementation of the Xout Facade interface implementation
provides the "glue" code to resolve the syntactic mismatch (e.g., names,
data units, etc.).

The advantage of this approach is that the implementations of the
subsystems are completely decoupled. Each has a fixed input and output
interface that is pure data transfer. That allows whatever is on the
other side of the interface to change drastically without any effect on
the subsystem (so long as the requirements on it service are unchanged).
The only shared semantics exists in the implementation of the Xout
interface and it only needs to understand the syntax of the other
subsystem's input interface.

Note that this is easily adaptable to your situation. You simply need
Xin and Xout wrappers for your business solution that know how to
convert to/from data transfer messages from/to the UI or persistence
layer view of things.

For example, your business layer needs to store an object. It collects
the object's attribute data into a data packet and sends a message whose
message identifier can be interpreted as meaning, "Here's a pile of data
I call Z. Store it." Now your wrapper maps that message identity to a
particular SQL string, substitutes the name 'Z' in that string,
constructs a DataSet, and submits the SQL query to the DB.

[Actually an oversimplification. Things like DataSet construction would
probably be done is a subsystem that isolates the DB access mechanisms.
That subsystem effectively becomes a "smart" interface.]

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH

ns · Oct 15, 2003

H. S. Lahman said:
Responding to Dan...

The short answer is: don't expose the objects in any layer to other
layers. Employ pure data transfer interfaces between the layers and let
those interfaces do the mapping of the data to their own paradigm.

The interfaces TO persistence and TO the UI will not change appreciably
because those paradigms don't change. However, one needs to encapsulate
the business problem solution within interfaces that are suited to its
paradigm. That means one must insert wrappers that understand how to
convert the UI-to-DB requests to UI-to-business and DB-to-UI to
DB-to-business.

For complex applications where UI and DB are peripheral services, the
general purpose model for subsystems (or layers) is:

+--------------+ +----------------+
| Subsystem A | | Subsystem B |
| | | |
| +------+ +------+ |
| | Aout |------------>| Bin | |
| +------+ +------+ |
| | | |
| +------+ +------+ |
| | Ain |<------------| Bout | |
| +------+ +------+ |
| | | |
+--------------+ +----------------+

where Ain and Bin are traditional input interfaces to the subsystem
(think: Facade pattern). Those interfaces are fixed regardless of reuse
context and they dispatch incoming data transfer messages (e.g., events)
to the relevant objects that implement the subsystem.

The Aout and Bout are output interfaces. The objects that implement the
subsystem talk to these interfaces whenever they need to send a message
to the outside world. The interface is also fixed so the subsystem
implementation always talks to the outside world the same way,
regardless of reuse context. The output interfaces also usually employ
a Facade pattern because the subsystem may need to talk to any of
several other subsystems.

For an original implementation the output interfaces will have trivial
implementations because the mapping will be designed to be 1:1 between
Xout messages and the other subsystem's Xin messages as a matter of good
systems engineering. However, in a reuse situation the interface the
client wants to use and the Xin interface provided may not match up
syntactically even though the service semantics is the same. In that
case the implementation of the Xout Facade interface implementation
provides the "glue" code to resolve the syntactic mismatch (e.g., names,
data units, etc.).

The advantage of this approach is that the implementations of the
subsystems are completely decoupled. Each has a fixed input and output
interface that is pure data transfer. That allows whatever is on the
other side of the interface to change drastically without any effect on
the subsystem (so long as the requirements on it service are unchanged).
The only shared semantics exists in the implementation of the Xout
interface and it only needs to understand the syntax of the other
subsystem's input interface.

Note that this is easily adaptable to your situation. You simply need
Xin and Xout wrappers for your business solution that know how to
convert to/from data transfer messages from/to the UI or persistence
layer view of things.

For example, your business layer needs to store an object. It collects
the object's attribute data into a data packet and sends a message whose
message identifier can be interpreted as meaning, "Here's a pile of data
I call Z. Store it." Now your wrapper maps that message identity to a
particular SQL string, substitutes the name 'Z' in that string,
constructs a DataSet, and submits the SQL query to the DB.

[Actually an oversimplification. Things like DataSet construction would
probably be done is a subsystem that isolates the DB access mechanisms.
That subsystem effectively becomes a "smart" interface.]

So what you are suggesting is defining the Facade for the entire
business layer according to the presentation needs. You may end up
with large number of interface methods. Facade, if you take it to the
extreme would encapsulate not only the business layer objects but also
the rational behind the object hierarchy composition. In some cases
your model would benefit from it since you actually managed to hide
all the model logic but take for example 2 totally different and
unrelated presentation layers. the first require a Composite
representation of the business objects while the other only needs a
flat list of objects. Since the logic of creating the composite or the
list is entirely hidden behind the facade any change to the
presentation needs would result in adding more interface methods to
the facade - what I mean unless the presentation layer recognizes
some sort of the logics of composing self objects it wil require
change to the facade for each new requirement. Since you have 2
different presentation needs you can't even benefit from having common
"logic" of composing the presentation objects (a list that can be
converted to list if you know the composition logic).
J2EE introduces the concept of ValueObject pattern which is some sort
of factory product of the original model object. It seems that for the
case of several different presentation layers your application may
benefit from it more than just having the Facade in front of your
business layer

Universe · Oct 15, 2003

(e-mail address removed) (ns) wrote in message

SAP (Service Access Point) is the term I use for layer interfaces in
my published article "OO Layered Architecture and Subsystems". For
this I followed the terminology for the layered architecture of the 7
layer OSI reference model for communication.

Obviously it makes sense to implement SAPs to be as pliant and
flexible as possible. Generally, for statically reliant OOPLs like
C++, Eiffel, Ada, Modula, etc, that means a SAP should be an abstract
class or set of classes - a "PI", (or "aPI" - abstract "P"olymophic
"I"nterface).

Then variously appropriate implementations may be substituted with
minimal demand for recompiling or relinking users of a SAP, when
changes occur to a layer interface.

Better each traditional, major overall layer type - UI, Business, or
Data - should perform its role best as it can and each should provide
one or more SAP, designed to serve the greatest number or key needs
for the greatest number of other key client layers.

My main point here is that:

*** Every layer's SAPs should all have a consistent underlying
abstract<=>implementation design structure while performing, providing
DbC ("D"esign "b"y "C"ontract) services specific to the role of the
layer. ***

Generally I agree.

"Trivial" is according to opinion, or context, as I see it.

Whatever "trivial" may be interpreted to be, a layer's one or more SAP
must flexibly, and reliably provide the service(s) for which the layer
is responsible.

The chief thing I can unite with here is that both a SAP's interface
and implementation may change as reuse grows and environment changes
take place. Clearly we want to avoid interace mods to greatest extent
possible. And as I stated above, implementation may vary within
limits if the SAP is abstract. Or the larger point being if a client
uses a reference to access a SAP.

Overall, what a SAP should or should not look like for each iterative
and incremental release is properly an outcome of tradeoffs based upon
the interplay of requirements project resources, stakeholder schedule
needs etc.

Comments on the following to come shortly (later today, tomorrow).

So what you are suggesting is defining the Facade for the entire
business layer according to the presentation needs. You may end up
with large number of interface methods. Facade, if you take it to the
extreme would encapsulate not only the business layer objects but also
the rational behind the object hierarchy composition. In some cases
your model would benefit from it since you actually managed to hide
all the model logic but take for example 2 totally different and
unrelated presentation layers. the first require a Composite
representation of the business objects while the other only needs a
flat list of objects. Since the logic of creating the composite or the
list is entirely hidden behind the facade any change to the
presentation needs would result in adding more interface methods to
the facade - what I mean unless the presentation layer recognizes
some sort of the logics of composing self objects it wil require
change to the facade for each new requirement. Since you have 2
different presentation needs you can't even benefit from having common
"logic" of composing the presentation objects (a list that can be
converted to list if you know the composition logic).
J2EE introduces the concept of ValueObject pattern which is some sort
of factory product of the original model object. It seems that for the
case of several different presentation layers your application may
benefit from it more than just having the Facade in front of your
business layer

Elliott

Universe · Oct 15, 2003

Elliott

Universe · Oct 15, 2003

(e-mail address removed) (ns) wrote in message

Correctamundo!!

The overall technical structure of a layer "SAP" (Service Access
Point, as called in the 7 layer OSI communication reference model and
my published article "OO Layered Architeture and Subsystems"@) should
be generally be the same for all layers.

Obviously specific SAP API semantics - the nature of the service
responsibilities proffered to clients- and specific SAP grammar and
packaging - methods, one or more classes, packaging e.g "assembly",
bean, servlet, ocmponent, COM, CORBA, JEE, etc will vary depending
upon the one or more role responsibilities of the layer and the
layer's program context - "depth" in program, design of neighboring
layers, etc.

And again:
The overall technical structure of a layer "SAP" should be *generally*
be the same for all layers in the same program/system.

@ request copies of "OO Layered Architeture and Subsystems" via
e-mail. The article also explores "system theory", and polymorphism as
they relate.

Elliott

H. S. Lahman · Oct 15, 2003

Responding to Ns...

So what you are suggesting is defining the Facade for the entire
business layer according to the presentation needs. You may end up

No, that's not what I said at all. Each layer or subsystem has its own
Facade that is constructed around that subject matter. Each subject
matter drives the interface syntax appropriate for that subject matter.
It is the implementation of the output Facade that resolves any
syntactic mismatches for the particular communication context.

with large number of interface methods. Facade, if you take it to the
extreme would encapsulate not only the business layer objects but also
the rational behind the object hierarchy composition. In some cases
your model would benefit from it since you actually managed to hide
all the model logic but take for example 2 totally different and
unrelated presentation layers. the first require a Composite
representation of the business objects while the other only needs a
flat list of objects. Since the logic of creating the composite or the
list is entirely hidden behind the facade any change to the
presentation needs would result in adding more interface methods to
the facade - what I mean unless the presentation layer recognizes
some sort of the logics of composing self objects it wil require
change to the facade for each new requirement. Since you have 2
different presentation needs you can't even benefit from having common
"logic" of composing the presentation objects (a list that can be
converted to list if you know the composition logic).

Actually, having multiple UIs is very common in my world. That is one
of the driving reasons why the model I presented is used. As the OP
noted, with conventional RAD/USER layered models it is difficult to
avoid exposing business objects to the presentation and vice versa.
This is especially true if one tries to define semantic correspondence
between the layers using inheritance.

The whole point of employing pure data transfer interfaces and having a
subsystem's object talk to a fixed output interface is to completely
eliminate any coupling of implementations. That allows the business
layer to be indifferent to whether the UI is a GUI, web browser, command
line, or clay tablets. More important, one can substitute the UI
paradigm with complete confidence that the problem solution is still
correct.

J2EE introduces the concept of ValueObject pattern which is some sort
of factory product of the original model object. It seems that for the
case of several different presentation layers your application may
benefit from it more than just having the Facade in front of your
business layer

J2EE is (among other things) a very specific implementation of a
traditional RAD/USER layered model. Such infrastructures exist because
RAD/USER problems are very common in IT. The reason the world is filled
with WYSIWYG GUI and web builders is that the paradigms are very well
defined and standardized. However, once one gets out of the RAD/USER
pipeline situations into problem environments that do not have well
defined solutions such infrastructures tend to be less useful and can
actually get in the way.

The situation is similar to pure RAD IDEs. One can build an enormously
complex application in Access or Delphi. However, it will be an
exercise in masochism to develop it, a resource pig to run, and it will
be a nightmare to maintain. So at some point the complexity of the
application drives one to more conventional application development in a
3GL.

Similarly, at the 3GL level infrastructures like J2EE can be very useful
in a lot of situations. However, when the business complexity increases
substantially one will encounter the same sorts problems with the 3GL
layered model as in the RAD IDE, mainly because the RAD IDE is a special
case of the J2EE layered model. The 3GL infrastructure allows one to
address considerably more complex problems that a pure RAD IDE. But
eventually one hits a complexity wall where one has to provide one's own
partitioning model and corresponding infrastructure. (One may still use
J2EE for very low level work, but that will be encapsulated in specific
areas of the application rather an ubiquitous infrastructure.)

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH

Universe · Oct 16, 2003

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.

Many of course create or reuse (their own or others) general screen,
console, etc. presentation libraries that embody screen operations
mostly common the need of their system's use cases as a whole. Eg.
for C++ RogueWave, AWT and Swing for Java, the NIH IO libraries, and
so on.

What some find to be just the ticket is fashioning a more system
project presentation library using the elements, widgets, etc of
general screen, "presentation" (I/O) library package. You reduce
work, yet still have a nicely fitting "I/O" layer.

And yes to the design and structure of such I/O layers, they apply the
tried and true mechanisms and patterns, like 'facade', abstract
'PI's', PI's with factories to create and vary implementation on the
fly, etc and combos thereof.

Good luck!

Elliott

Uncle Bob (Robert C. Martin) · Oct 16, 2003

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.

We *do* want a separation between the presentation logic, and the
actual UI logic. For example, the presentation logic understands the
elements of each screen, but is not aware that the screen is HTML or
Swing, or even text. The presentation logic knows that there are
lists, options, commands etc, that roughly correspond to listboxes,
checkboxes, buttons. The presentation logic knows what data to put
into the fields, and what responses to give to the commands. It knows
when certain commands should be disabled (grayed) or not. It knows
the flow between screens.

The presentation logic does not know about the UI, but the UI *does*
know about the presentation.

Model-View-Controller is a good place to start for design patterns
that discuss this kind of separation. Model-View-Presenter and
Model-View-Presenter-Controller are more advanced.

Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python | http://fitnesse.org

Nitsan · Oct 16, 2003

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

Sounds like typical business/presentation conversion. Seems that
Abstract Factory wrapped by a Facade may solve that. Consider a set of
factory products for your presentation (tree, list, single element)
and appropriate factory for each that is accessed by the client
(presentation in this case) through teh facade. The outcome is a new
representation of the business object hierarchy that has relationship
whatsoever with the business layer objects

NS

Shane Mingins · Oct 17, 2003

Uncle Bob (Robert C. Martin) said:
Model-View-Controller is a good place to start for design patterns
that discuss this kind of separation. Model-View-Presenter and
Model-View-Presenter-Controller are more advanced.

Are there any code examples around of Model-View-Presenter-Controller that
would help illustrate this pattern?

Shane

--
(e-mail address removed)

remove clothes before replying

"It is not the strongest of the species that survive, nor the most
intelligent, but the one most responsive to change." --- Charles Darwin

dan · Oct 17, 2003

Uncle Bob (Robert C. Martin) said:
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.

We *do* want a separation between the presentation logic, and the
actual UI logic. For example, the presentation logic understands the
elements of each screen, but is not aware that the screen is HTML or
Swing, or even text. The presentation logic knows that there are
lists, options, commands etc, that roughly correspond to listboxes,
checkboxes, buttons. The presentation logic knows what data to put
into the fields, and what responses to give to the commands. It knows
when certain commands should be disabled (grayed) or not. It knows
the flow between screens.

The presentation logic does not know about the UI, but the UI *does*
know about the presentation.

Model-View-Controller is a good place to start for design patterns
that discuss this kind of separation. Model-View-Presenter and
Model-View-Presenter-Controller are more advanced.

Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python | http://fitnesse.org

Does that mean that the presentation actually recognizes the business
objects and can access them directly? Or does that mean that the
presentation is built upon the business objects by some kind of
mediator?

dan · Oct 17, 2003

H. S. Lahman said:
Responding to Ns...

No, that's not what I said at all. Each layer or subsystem has its own
Facade that is constructed around that subject matter. Each subject
matter drives the interface syntax appropriate for that subject matter.
It is the implementation of the output Facade that resolves any
syntactic mismatches for the particular communication context.

Let me try sketching your idea. Consider a business structure that
represents a network hierarchy and a collection of objects that
respresents the individual network entities. What you are saying is
that these items only live within the Business layer while the outside
world can interact with them in some way.
That way according to you is that the business layer commits to a
certain interface regardless of its clients needs (in fact it doesn't
know who its cleinst are and what their needs are) and its clients
communicate to this interface in order to construct their data
representation. No problem with that except for the fact that this
commitment is done aprior to any knowledge of the clients needs.
Isn't that one of the purposes of the Abstract Factory? To be able to
build a specific product (in this case - representation) according to
the client needs?
How would you solve the problem of having the need of representing a
semantic tree hierarchy in the business as an ordered (flat) list?
Will the business layer have to commit to an interface that exports
its hierarchy also as a list?

Regards
DK

H. S. Lahman · Oct 18, 2003

Responding to Dan...

Let me try sketching your idea. Consider a business structure that
represents a network hierarchy and a collection of objects that
respresents the individual network entities. What you are saying is
that these items only live within the Business layer while the outside
world can interact with them in some way.

Yes, up to a point. There are many possible views of a network. There
could be multiple network subject matters within the business layer.
For example, the view needed to dynamically add and remove physical or
logical network elements is likely to be different than the view needed
to optimize resource allocation. Similarly, the view of protocols to
send and receive messages would be yet another view.

This is why the subsystem view of application partitioning is better for
larger, complex applications than the simple layered view. It allows
a two dimensional partitioning rather than a one dimensional
partitioning. The RAD/USER layered models are just a special case of
the more general subsystem view. IOW, a layer is just a subsystem that
has no peers at a particular level of abstraction.

Nor are the views of a network restricted to the business layer. To
initialize an application that deals with networks one needs a
definition of the network configuration that persists across executions.
So one may also have a persistence view of the network that is also
unique. The basic idea is simply to encapsulate those views, concerns,
functional responsibilities, etc. behind an interface so that the
implementation is completely decoupled from other implementations in the
environment.

[BTW, it's not my idea. This is a pretty standard model in R-T/E and
systems engineers have been practicing this of thing for large systems
for decades. OO has simply provided an infrastructure that allows it to
be much more systematic.]

That way according to you is that the business layer commits to a
certain interface regardless of its clients needs (in fact it doesn't
know who its cleinst are and what their needs are) and its clients
communicate to this interface in order to construct their data

That's true up to a point. But recall my model where the
/implementation/ of a subsystem talks to its own output interface. It
is that interface that is fixed and is constructed around the semantics
of the contained subject matter, just as the other subsystem's input
interface is constructed around /that/ subsystem's contained subject matter.

What the model provides is the ability to resolve syntactic disconnects
in those views in the implementation of the output interface. So when
the UI sends "User Clicked Button 4b" that output message semantics can
be mapped into the input message "Emergency Stop".

The primary motivation here is that it supports large scale reuse by
allowing one to provide "glue" code for the reuse context in a very
isolated way. But that has additional benefits. It allows one to view
subject matters in a very generic fashion. That is manifested in
expressing the subject matter in terms of problem space invariants,
which makes large scale reuse self-fulfilling. It also precludes any
implementation-level dependencies so the application will be more robust.

representation. No problem with that except for the fact that this
commitment is done aprior to any knowledge of the clients needs.
Isn't that one of the purposes of the Abstract Factory? To be able to
build a specific product (in this case - representation) according to
the client needs?

Again, up to a point. B-) If by 'needs' you mean views like
presentation and persistence, then the answer is that one no longer
needs the Abstract Factory. Each subject matter will have its own
"concrete" Factory for constructing its subject matter view. This
actually simplifies things because one does not have to worry about
trying to invent a one-size-fits-all base factory interface to
accommodate all possible views.

If you mean 'needs' in the sense of dynamic needs are run time (e.g.,
the choice of network protocol is made at run time on a case-by-case
basis), then one is still constrained to the dynamics of a single
subject matter view. That may require an Abstract Factory but the
context will be much more limited to the subject matter in hand.

However, IME the need for an Abstract Factory is very rare /within/ a
subject matter. Basically a factory does two things: it instantiates
class objects and it instantiates relationships. Both of those can
easily be handled in a mundane way through lookup tables and whatnot so
long as one has a good scheme for object identity. If one has a good
scheme for identity (e.g., XML strings), then both the instances and the
relationships can almost always be instantiated parametrically through
external data. That is pretty cookbook stuff (albeit sometimes tedious).

So the only time one needs an Abstract Factory is when the rules and
policies of instantiation are unusually complicated. In that case the
Abstract Factory is useful because it allows one to isolate those rules
to one place (i.e., whoever instantiates the relationship between
Context and the specific instance of Abstract Factory) in a manner that
is consistent across a wide variety of contexts.

OTOH, the RAD/USER infrastructures have made extensive use of the notion
of inheritance across layers from a common Abstract Factory model. This
is very convenient because it allows the infrastructure to provide
aspect-like boilerplate transparently to do a lot of the grunt work.
But those aspects only work well when the things being built in each
layer are very, very similar.

How would you solve the problem of having the need of representing a
semantic tree hierarchy in the business as an ordered (flat) list?
Will the business layer have to commit to an interface that exports
its hierarchy also as a list?

One needs a lot more specific context to answer this. B-) However,
let's assume on the business side we represent the hierarchy with:

1 1
[Client] -----------

| 0..1
| root of
|
child of 0..1 | 1
+------------- [Element]
| | 0..*
| | parent of
| |
+-------------------+

while the outside world has the view:

1 <<ordered>> *
[Client] ----------------- [Element]

Now there has to be some mechanism for mapping the parent/child
relationship in the flat list version of [Element]s. Let's assume
that's in the form of a Element.levelNumber attribute value and that the
list is positionally ordered such that each parent is followed
immediately by its children so that

[E1] Level 0
/ \
/ \
/ \
[E2] [E3] Level 1
/ \ \
/ \ \
/ \ \
[E4] [E5] [E6] Level 2

appears in the flat list as {E1(0), E2(1), E4(2), E5(2) , E3(1), E6(2)}.
Now let's look at what happens when the outside world (subsystem OW)
sends the list to the subsystem in hand (IH). The output interface,
OW.here'sTheList(<data packet>), will have a data packet that looks
exactly like the above (where En is expanded to the appropriate
attribute values). That is, it is just an array of Elements in the flat
list order.

In this case the IH.here'sAList(<data packet>) probably looks exactly
the same; it's just a list of [Element]s. IH.here'sAList understands
the ordering and the significance of levelNumber in terms of a
parent/child hierarchy. So it could instantiate the [Element]s and
relationships as it "walks" the input array. As a practical matter,
though, Here'sAList probably just forwards this array without change to
a Factory that knows how to instantiate [Elements] and the child
of/parent of relationships by "walking" the flat data structure.

As it happens, this is not a very good example because of the flat file
source. As a practical matter pure data transfer interfaces are always
"flat file" representation (i.e., their data packets are a monolithic
data structure). So the conversion is pretty trivial. The real work is
done in the Factory that understands the rules and policies of
instantiation, given a data stream. In effect one just has an [Element]
class in OW with a levelNumber attribute while the view of the same
[Element] class in IH replaces levelNumber with parentPtr and/or
childPtr referential attributes to implement the relationships in a
different manner.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH

dan · Oct 19, 2003

H. S. Lahman said:
Responding to Dan...

One needs a lot more specific context to answer this. B-) However,
let's assume on the business side we represent the hierarchy with:

1 1
[Client] -----------

| 0..1
| root of
|
child of 0..1 | 1
+------------- [Element]
| | 0..*
| | parent of
| |
+-------------------+

while the outside world has the view:

1 <<ordered>> *
[Client] ----------------- [Element]

Now there has to be some mechanism for mapping the parent/child
relationship in the flat list version of [Element]s. Let's assume
that's in the form of a Element.levelNumber attribute value and that the
list is positionally ordered such that each parent is followed
immediately by its children so that

[E1] Level 0
/ \
/ \
/ \
[E2] [E3] Level 1
/ \ \
/ \ \
/ \ \
[E4] [E5] [E6] Level 2

appears in the flat list as {E1(0), E2(1), E4(2), E5(2) , E3(1), E6(2)}.
Now let's look at what happens when the outside world (subsystem OW)
sends the list to the subsystem in hand (IH). The output interface,
OW.here'sTheList(<data packet>), will have a data packet that looks
exactly like the above (where En is expanded to the appropriate
attribute values). That is, it is just an array of Elements in the flat
list order.

In this case the IH.here'sAList(<data packet>) probably looks exactly
the same; it's just a list of [Element]s. IH.here'sAList understands
the ordering and the significance of levelNumber in terms of a
parent/child hierarchy. So it could instantiate the [Element]s and
relationships as it "walks" the input array. As a practical matter,
though, Here'sAList probably just forwards this array without change to
a Factory that knows how to instantiate [Elements] and the child
of/parent of relationships by "walking" the flat data structure.

As it happens, this is not a very good example because of the flat file
source. As a practical matter pure data transfer interfaces are always
"flat file" representation (i.e., their data packets are a monolithic
data structure). So the conversion is pretty trivial. The real work is
done in the Factory that understands the rules and policies of
instantiation, given a data stream. In effect one just has an [Element]
class in OW with a levelNumber attribute while the view of the same
[Element] class in IH replaces levelNumber with parentPtr and/or
childPtr referential attributes to implement the relationships in a
different manner.

The Element object in your example is not only a part of a class
hierarchy but also an object that lives within *one* subsystem and
should only be recognized in the context of this subsystem. an Element
object can't be passed between IH and OW as is. So this requires some
conversion on both interfaces: to/from IH::ElementForm from/to
OW::ElementForm.

Are you suggesting that each subsystem will maintain its own form of
Element class or should there be some generic mechanism to transfer
the object data between those subsystems (like XML)?

DK

Uncle Bob (Robert C. Martin) · Oct 19, 2003

Are there any code examples around of Model-View-Presenter-Controller that
would help illustrate this pattern?

The article "The Humble Dialog Box" is a good start.
http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

There is a more complete example in "UML for Java Programmers"
http://www.objectmentor.com/UMLFJP

Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python | http://fitnesse.org

Uncle Bob (Robert C. Martin) · Oct 19, 2003

(e-mail address removed) (dan) might (or might not) have written this

Does that mean that the presentation actually recognizes the business
objects and can access them directly? Or does that mean that the
presentation is built upon the business objects by some kind of
mediator?

Shane Mingins · Oct 19, 2003

The article "The Humble Dialog Box" is a good start.
http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

So (just clarifying as it is not explicitly stated in Michael's article)
this an example of Model-View-Presenter-Controller?

There is a more complete example in "UML for Java Programmers"
http://www.objectmentor.com/UMLFJP

Which example is that?

Thanks
Shane

H. S. Lahman · Oct 20, 2003

Responding to Dan...

The Element object in your example is not only a part of a class
hierarchy but also an object that lives within *one* subsystem and
should only be recognized in the context of this subsystem. an Element
object can't be passed between IH and OW as is. So this requires some
conversion on both interfaces: to/from IH::ElementForm from/to
OW::ElementForm.

Are you suggesting that each subsystem will maintain its own form of
Element class or should there be some generic mechanism to transfer
the object data between those subsystems (like XML)?

Exactly! The subsystems should reflect different subject matters that
deal with different <functional> requirements. As such, behaviors
should not be duplicated across the subsystems; otherwise the subsystem
subject matters would not be cohesive. So even if one is abstracting
the same underlying entity in both subsystems, the behavior
responsibilities one needs to abstract for the class representing it
will be different.

However, different functionality can chew on the same data. Therefore
the classes in each subsystem may share some knowledge responsibilities.
That is where the pure data transfer interfaces come into play. The
interfaces allow the knowledge to be transferred between subsystems for
initialization and synchronization. So, in a sense, pure data transfer
interfaces /are/ a generalized mechanism for transferring object data
between subsystems because it is very easy to decouple the data in
message packets from the knowledge in particular class abstractions in
either subsystem.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH

Uncle Bob (Robert C. Martin) · Oct 21, 2003

So (just clarifying as it is not explicitly stated in Michael's article)
this an example of Model-View-Presenter-Controller?

Yes, the class that controls the logic of the dialog is the presenter.
The class that actually draws the dialog on the screen is the view.

Which example is that?

business layer functionality in data layer	2	Oct 12, 2010
The business layer and data access layer	0	Mar 23, 2006
Web Layer & Business Layer communication	5	Oct 30, 2008
Presentation layer depends on ????	1	Jul 3, 2006
Data Layer, Business logic layer help	9	Oct 10, 2007
Persisting business layer objects	2	Jun 16, 2004
File Upload in Business Layer	2	Jan 23, 2009
Presentation layer has reference to data layer	2	Oct 13, 2006

Exposing Business Layer Objects to Presentation Layer

dan

H. S. Lahman

ns

Universe

Universe

Universe

H. S. Lahman

Universe

Uncle Bob (Robert C. Martin)

Nitsan

Shane Mingins

dan

dan

H. S. Lahman

dan

Uncle Bob (Robert C. Martin)

Uncle Bob (Robert C. Martin)

Shane Mingins

H. S. Lahman

Uncle Bob (Robert C. Martin)

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads