Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Exposing Business Layer Objects to Presentation Layer

Reply
Thread Tools

Exposing Business Layer Objects to Presentation Layer

 
 
dan
Guest
Posts: n/a
 
      10-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
 
Reply With Quote
 
 
 
 
H. S. Lahman
Guest
Posts: n/a
 
      10-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
http://www.velocityreviews.com/forums/(E-Mail Removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(88-OOA-PATH




 
Reply With Quote
 
 
 
 
ns
Guest
Posts: n/a
 
      10-15-2003
"H. S. Lahman" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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
 
Reply With Quote
 
Universe
Guest
Posts: n/a
 
      10-15-2003
(E-Mail Removed) (ns) wrote in message

> "H. S. Lahman" <(E-Mail Removed)> wrote in message


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


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.

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


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. ***

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


Generally I agree.

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


"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.

> > 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 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
--
Free, Free Palestine! Democratic Palestine!
 
Reply With Quote
 
Universe
Guest
Posts: n/a
 
      10-15-2003
Elliott
 
Reply With Quote
 
Universe
Guest
Posts: n/a
 
      10-15-2003
(E-Mail Removed) (ns) wrote in message

> "H. S. Lahman" <(E-Mail Removed)> wrote in message


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


Correctamundo!!

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


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
--
Free, Free Palestine! Democratic Palestine!
US Fat Cats Hands Off the World! US Fat Cats Hands Off of Our Backs!
 
Reply With Quote
 
H. S. Lahman
Guest
Posts: n/a
 
      10-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 Removed)
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(88-OOA-PATH




 
Reply With Quote
 
Universe
Guest
Posts: n/a
 
      10-16-2003
(E-Mail Removed) (dan) wrote in message news:<(E-Mail Removed). com>...
> 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
--
Free, Free Palestine! Democratic Palestine!
US Fat Cats Hands Off the World!
 
Reply With Quote
 
Uncle Bob (Robert C. Martin)
Guest
Posts: n/a
 
      10-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
 
Reply With Quote
 
Nitsan
Guest
Posts: n/a
 
      10-16-2003
(E-Mail Removed) (dan) wrote in message news:<(E-Mail Removed). com>...
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
business layer, data access layer , presentation layer for asp.net using C#.net Dhananjay ASP .Net 1 12-18-2006 11:35 PM
Presentation layer has reference to data layer Ily ASP .Net 2 10-13-2006 08:40 AM
Business Layer, Data Layer, Speed Issues, Classes, and all that et ASP .Net 2 03-06-2006 02:46 PM
My business class methods are not being exposed in my presentation layer :( Learner ASP .Net 5 12-21-2005 10:01 PM
Re: Exposing Business Layer Objects to Presentation Layer Universe Java 1 10-24-2003 09:40 PM



Advertisments