Presentation Abstraction Control (PAC) pattern is similar
to the Model View Controller (MVC) pattern. The main difference between the
patterns is that in MVC there is a coupling between the model and the view, the
model and the controller and the controller and the view and in the PAC pattern
there is only a coupling between Model and Controller and View and Controller.
There is no coupling between the Model and the View. The other main difference
is that PAC is broken up into a series of 'Agents' that work with each other in
a hierarchy. The P-A-C objects that work together form an Agent. Those are
then organized in a hierarchy based on responsibilites (more later).
The model of MVC is similar to the abstraction of PAC. They
both serve to hold information that is needed by the Controller/Control of each
pattern. The difference is that an abstraction is only the subset that the
Control(ler) needs to work with for that particular PAC layer.
The controller of the MVC and the control of PAC are
similar as well. The difference is that control directly updates the
presentation as well as responding to external events and updating the
abstraction.
The presentation of PAC and view of MVC both handle
displaying the data. The view recieves updates from the model direclty and the
controller. The presentation is only getting its updates from the control.
You can read more about PAC from here: http://www.dossier-andreas.net/software_architecture/pac.html
I am currently using this architecture for the current
project that I am on. We are responsible for a windows form line of
business app. The architecture works very well for a number reasons.
First, it is extremely testable. Since each memeber of a PAC hierarchy is an implemented interface,
it is easy to substitue mock objects that allow you to isolate what it is that
you are testing. For instance, if I want to test the controller functionality
and how it interacts with the view, I can easily create a mock IView and Im off
to asserting the functionality. Alternatly, since the controller can talk to
other controllers I can also mock an IController test wether or not the
controller is sending messages as expected.
Second, because there are a hierarchy of controllers for
the views that are presented, it is possible to reuse entire sets of logic and
move application sections around and share them with different parts
of the application. So for instance if I had a PAC agent that knew how to
get and display customer information, that agent could be a child of a master
customer management agent but could also participate in other agents such as an
Order View agent. Since the logic to handle and manipulate the
presentation is part of the agent, I do not have to duplicate code in a
controller or presenter when I want to have the viewlet in two places in the
application.
Thats it for now. Have you used PAC
architecture? How do you see it being different than MVC/MVP? Let me
know.
Rich