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