Re: Exposing Business Layer Objects to Presentation Layer
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 10/14/03
- Next message: JDany: "Simple JTable Question"
- Previous message: Shane: "SCPJ2 question."
- In reply to: dan: "Exposing Business Layer Objects to Presentation Layer"
- Next in thread: ns: "Re: Exposing Business Layer Objects to Presentation Layer"
- Reply: ns: "Re: Exposing Business Layer Objects to Presentation Layer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 14 Oct 2003 17:25:32 GMT
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
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH
- Next message: JDany: "Simple JTable Question"
- Previous message: Shane: "SCPJ2 question."
- In reply to: dan: "Exposing Business Layer Objects to Presentation Layer"
- Next in thread: ns: "Re: Exposing Business Layer Objects to Presentation Layer"
- Reply: ns: "Re: Exposing Business Layer Objects to Presentation Layer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
