Facade pattern

[anonymous.user0]

I'm a little confused about the Facade pattern. As I understand
it, it's supposed to be a single, simplified interface into a larger
amount of subsystems. The question I have is basically how simple and
interface is it supposed to be? Lets say I've got an application with
multiple layers in differenct projects. I've got a Core project that
contains the core business objects and Managers for those objects.
Managers are responsible for locating, saving, and deleting objects of
a certain type (eg. XXManager manages XX objects). Each Manager
implements a IXXManager interface that defines these functions (Thanks
to the newsgroup for helping me decide on that arch.). Does it make
sense to have a CoreModelFacade that encapulates all the functionality
of the individual Managers and have my forms (the view) communicate
solely with the Facade? This would lead to having a very large class
that would basically implement all of the IXXManager's interfaces and
just pass the requests on down the line to the individual managers.
What I don't like about this is that it's not very extensible.
Every time I add a new Core object, I have to modify this Facade to add
the new functionality. Basically this Facade would end up being a
single class that represents the whole API. Am I interperating this
correctly? One thing I do like about this is it creates a nice
seperation between the Model and everything else. Each View (form,
control, etc) would hook up to the Model through the Facade and apply
its filter to the data, listen for events from the Model of when data
changes, see if the changes effect the data it's displaying. But
following an arch. like that leads me to ask where the filter would be,
in the View or in the Model. Would the Model have a function
Employee_List getSalesEmployees(), or would the Model just have an
Employee_List getEmployees() function and the View would filter out all
non Sales Employees? In the second case, it would seem like alot of
extra data is going to be passed around, while in the first case alot
more functions will be in the interface.
Are there any good books out there describing different (non
enterprise/distributed) application architectures?

[Michael Nemtsev]

Hello anonymous,

The key idea of facade to give unified interfaces for subsitems bases on
some subject logic
In your case, for example, there could be CoreModelADMINFacade and CoreModelUSERFacade.
First incapsulates interfaces from componets that is used only by admin -
this give u isolation and secure way to protect your components from guest
users. Other incapsulates interfaces for all users

See facade sample over there http://www.dofactory.com/Patterns/PatternFacade.aspx

au> I'm a little confused about the Facade pattern. As I
au> understand
au> it, it's supposed to be a single, simplified interface into a larger
au> amount of subsystems. The question I have is basically how simple
au> and
au> interface is it supposed to be? Lets say I've got an application
au> with
au> multiple layers in differenct projects. I've got a Core project
au> that
au> contains the core business objects and Managers for those objects.
au> Managers are responsible for locating, saving, and deleting objects
au> of
au> a certain type (eg. XXManager manages XX objects). Each Manager
au> implements a IXXManager interface that defines these functions
au> (Thanks
au> to the newsgroup for helping me decide on that arch.). Does it make
au> sense to have a CoreModelFacade that encapulates all the
au> functionality
au> of the individual Managers and have my forms (the view) communicate
au> solely with the Facade? This would lead to having a very large
au> class
au> that would basically implement all of the IXXManager's interfaces
au> and
au> just pass the requests on down the line to the individual managers.
au> What I don't like about this is that it's not very extensible.
au> Every time I add a new Core object, I have to modify this Facade to
au> add
au> the new functionality. Basically this Facade would end up being a
au> single class that represents the whole API. Am I interperating this
au> correctly? One thing I do like about this is it creates a nice
au> seperation between the Model and everything else. Each View (form,
au> control, etc) would hook up to the Model through the Facade and
au> apply
au> its filter to the data, listen for events from the Model of when
au> data
au> changes, see if the changes effect the data it's displaying. But
au> following an arch. like that leads me to ask where the filter would
au> be,
au> in the View or in the Model. Would the Model have a function
au> Employee_List getSalesEmployees(), or would the Model just have an
au> Employee_List getEmployees() function and the View would filter out
au> all
au> non Sales Employees? In the second case, it would seem like alot of
au> extra data is going to be passed around, while in the first case
au> alot
au> more functions will be in the interface.
au> Are there any good books out there describing different (non
au> enterprise/distributed) application architectures?
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche