Exposing Business Layer Objects to Presentation Layer

Discussion in 'Java' started by dan, Oct 14, 2003.

  1. dan

    dan Guest

    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
     
    dan, Oct 14, 2003
    #1
    1. Advertising

  2. dan

    H. S. Lahman Guest

    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

    Pathfinder Solutions -- Put MDA to Work
    http://www.pathfindersol.com
    (888)-OOA-PATH
     
    H. S. Lahman, Oct 14, 2003
    #2
    1. Advertising

  3. dan

    ns Guest

    "H. S. Lahman" <> wrote in message news:<>...
    > 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
     
    ns, Oct 15, 2003
    #3
  4. dan

    Universe Guest

    (ns) wrote in message

    > "H. S. Lahman" <> 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!
     
    Universe, Oct 15, 2003
    #4
  5. dan

    Universe Guest

    Elliott
     
    Universe, Oct 15, 2003
    #5
  6. dan

    Universe Guest

    (ns) wrote in message

    > "H. S. Lahman" <> 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!
     
    Universe, Oct 15, 2003
    #6
  7. dan

    H. S. Lahman Guest

    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

    Pathfinder Solutions -- Put MDA to Work
    http://www.pathfindersol.com
    (888)-OOA-PATH
     
    H. S. Lahman, Oct 15, 2003
    #7
  8. dan

    Universe Guest

    (dan) wrote in message news:<>...
    > 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!
     
    Universe, Oct 16, 2003
    #8
  9. 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
     
    Uncle Bob (Robert C. Martin), Oct 16, 2003
    #9
  10. dan

    Nitsan Guest

    (dan) wrote in message news:<>...
    > 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
     
    Nitsan, Oct 16, 2003
    #10
  11. "Uncle Bob (Robert C. Martin)" <> wrote in
    message news:...
    > 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

    --
    hes

    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
     
    Shane Mingins, Oct 17, 2003
    #11
  12. dan

    dan Guest

    "Uncle Bob (Robert C. Martin)" <> wrote in message news:<>...
    > 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
    #12
  13. dan

    dan Guest

    "H. S. Lahman" <> wrote in message news:<>...
    > 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.



    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


    >
    > > 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
    >
    > Pathfinder Solutions -- Put MDA to Work
    > http://www.pathfindersol.com
    > (888)-OOA-PATH
     
    dan, Oct 17, 2003
    #13
  14. dan

    H. S. Lahman Guest

    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

      Pathfinder Solutions -- Put MDA to Work
      http://www.pathfindersol.com
      (888)-OOA-PATH
     
    H. S. Lahman, Oct 18, 2003
    #14
  15. dan

    dan Guest

    "H. S. Lahman" <> wrote in message news:<>...
    > 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
     
    dan, Oct 19, 2003
    #15
  16. "Shane Mingins" <> might (or might not)
    have written this on (or about) Fri, 17 Oct 2003 15:54:58 +1300, :

    >"Uncle Bob (Robert C. Martin)" <> wrote in
    >message news:...
    >> 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?


    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
    #16
  17. (dan) might (or might not) have written this
    on (or about) 17 Oct 2003 02:06:01 -0700, :

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


    Either way. If the business rules are volatile, then you might want
    to shield the GUI from them with a mediator or a facade.



    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
    #17
  18. "Uncle Bob (Robert C. Martin)" <> wrote in
    message

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


    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
     
    Shane Mingins, Oct 19, 2003
    #18
  19. dan

    H. S. Lahman Guest

    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

    Pathfinder Solutions -- Put MDA to Work
    http://www.pathfindersol.com
    (888)-OOA-PATH
     
    H. S. Lahman, Oct 20, 2003
    #19
  20. "Shane Mingins" <> might (or might not)
    have written this on (or about) Mon, 20 Oct 2003 09:34:42 +1300, :

    >"Uncle Bob (Robert C. Martin)" <> wrote in
    >message
    >
    >> >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

    >
    >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.
    >
    >>
    >> There is a more complete example in "UML for Java Programmers"
    >> http://www.objectmentor.com/UMLFJP

    >
    >Which example is that?


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


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

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Learner
    Replies:
    5
    Views:
    652
    Karl Seguin
    Dec 21, 2005
  2. et
    Replies:
    2
    Views:
    1,935
  3. Universe
    Replies:
    1
    Views:
    485
    Universe
    Oct 24, 2003
  4. Ily
    Replies:
    2
    Views:
    349
    Robert Haken [MVP]
    Oct 13, 2006
  5. Dhananjay
    Replies:
    1
    Views:
    1,149
    sloan
    Dec 18, 2006
Loading...

Share This Page