Re: Exposing Business Layer Objects to Presentation Layer

From: ns (nitsans_at_savantis.com)
Date: 10/15/03 

Date: 15 Oct 2003 01:44:00 -0700

"H. S. Lahman" <h.lahman@verizon.net> wrote in message news:<3F8C3193.4040708@verizon.net>...
> 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

Relevant Pages

  • Re: Exposing Business Layer Objects to Presentation Layer
    ... >> those interfaces do the mapping of the data to their own paradigm. ... layer OSI reference model for communication. ... C++, Eiffel, Ada, Modula, etc, that means a SAP should be an abstract ... >> case the implementation of the Xout Facade interface implementation ...
    (comp.object)
  • Re: Exposing Business Layer Objects to Presentation Layer
    ... >> those interfaces do the mapping of the data to their own paradigm. ... layer OSI reference model for communication. ... C++, Eiffel, Ada, Modula, etc, that means a SAP should be an abstract ... >> case the implementation of the Xout Facade interface implementation ...
    (comp.lang.java.programmer)
  • Re: Interface complexity problem in game
    ... In that case it is a subsystem interface. ... Using the GoF Facade pattern is a common way to implement subsystem interfaces. ... Subsystem interfaces should be pure data transfer interfaces. ... That is, one just has {message id, data packet} where the data packet contains by-value data. ...
    (comp.object)
  • Re: Exposing Business Layer Objects to Presentation Layer
    ... > those interfaces do the mapping of the data to their own paradigm. ... > (think: Facade pattern). ... > to the relevant objects that implement the subsystem. ... > layer view of things. ...
    (comp.lang.java.programmer)
  • Re: What would be a truly relational operating system ?
    ... lower physical layer (I mean on current disks, RAM, and CPU ... One perhaps tangential problem is that mainstream OS designers aren't really into making coherent interfaces, let alone applying information theory, even though some of them jabber about that. ... I had to cope with an IBM mainframe OS called MVS. ...
    (comp.databases.theory)