Re: Exposing Business Layer Objects to Presentation Layer

From: dan (dan_kreitzer_at_hotmail.com)
Date: 10/17/03 

Date: 17 Oct 2003 03:27:12 -0700

"H. S. Lahman" <h.lahman@verizon.net> wrote in message news:<3F8DA7CA.6040408@verizon.net>...
> 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
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindersol.com
> (888)-OOA-PATH

Relevant Pages

  • Re: Exposing Business Layer Objects to Presentation Layer
    ... >> business layer according to the presentation needs. ... > Facade that is constructed around that subject matter. ... > matter drives the interface syntax appropriate for that subject matter. ...
    (comp.lang.java.programmer)
  • Re: List casting question
    ... I have an interface in my business layer called IArchivable which includes ... functions and properties for 'deleting' an object in the database without ... I created a function with the following signature, ...
    (microsoft.public.dotnet.general)
  • List casting question
    ... I have an interface in my business layer called IArchivable which includes functions and properties for 'deleting' an object in the database without actually deleting it. ... Public Shared Function FilterArchived) As Generic.IList ... Message="Unable to cast object of type 'System.Collections.Generic.List`1' to type 'System.Collections.Generic.List`1'." ...
    (microsoft.public.dotnet.general)
  • Re: whats the point of an interface?
    ... > just leave the class as it is, without the interface, and it would still ... the database, but they don't want to have to know the details, nor even ... your business layer defines an interface that contains the methods ...
    (microsoft.public.dotnet.languages.csharp)