In PVC archiecture, does each system (or agents) should have Presentation, Abstraction, Control component within it? How it differs from MVC architecture? I'm more confused between the two.
Can someone help me with an example?
1 Answers
Modular design Modular design is a generally recognized Good Thing(tm) in software engineering. As in science in general, breaking a problem down to smaller, bite-sized pieces makes it easier to solve. It also allows different people to solve different parts of the problem and still have it all work correctly in the end. Each component is then self-contained and, as long as the interface between different components remains constant, can be extended or even gutted and rewritten as needed without causing a chaotic mess.
I should note that modular design is not the same thing as plugin-based design, which is what many many open source projects use. Drupal "modules" are actually plugins. The Linux kernel, Apache, Eclipse, and many other high-profile projects with "loadable modules" are plugin-based architectures. Plugin-based architectures are not incompatible with modular design and in fact complement it well, but I digress...
Most software architectural patterns are based around the idea that modular design is a good thing, rather by definition. There are lots of architectural patterns for systems depending on what it is they're supposed to do. For interactive systems, the usual breakdown of components is "display component", "data storage component", and "business logic".
MVC The most commonly-known interactive system architecture is Model-View-Controller, or MVC. Most good desktop applications use MVC or a variant of it, sometimes with the Controller partially merged into the View. In MVC, as the pretty picture at the other end of that links shows, the Model holds data, the View is the part the user sees, and the Controller is an intermediary for business logic. Seems reasonable, right? Now take a closer look.
In MVC, the View component has direct access to the Model. The Controller itself doesn't enter the picture unless there is actual change to the data. Simply reading and displaying data is done entirely by the View component itself. As a result, a system can have many View components active at once, all reading and displaying data in a variety of different ways, even on different systems or in different languages or different modes (GUI vs. textual vs. web). On the flipside, however, that means the View component has to have some rather complex logic in it. It needs to know how to pull data out of the Model, which means it needs to know what the data structure is (or at least a rich API in front of the Model). It needs to be able to handle user interaction itself, with its own event loop.
Well, that rules out most would-be web-MVC setups. One of the most common cries of such systems is to "get database stuff away from HTML". Instead, everything is handled through a smart controller that uses a template layer to render and display output. That's not a bad design necessarily, but it is not MVC. If the display component does not have direct, random-access, pull-access to the data store, then it is not MVC.
PAC A less publicized but still widely used architecture is Presentation-Abstraction-Control, or PAC. The two main differences between MVC and PAC are that in PAC the Presentation component is "dumb" while all the intelligence resides in the Controller and PAC is layered. Again, see the pretty picture.
You'll notice that the Presentation and Abstraction components never speak to each other. The Controller takes input, not the display component. The Controller has all the business logic and routing information. The Presentation component is essentially just a filter that takes raw data that the Controller pushes through it and renders it to HTML (or WML, or XML, or text, or an icon in a graphical monitoring system, or whatever). It's just a templating system.
The classic example of a PAC architecture is an air traffic control system. One PAC Agent takes input from a radar system about the location of an incoming 747, and uses the Presentation component to paint a picture of that blip on a canvas (screen). Another Agent independently takes input about a DC-10 that is taking off, and paints that blip to the canvas as well. Still another takes in weather data and paints clouds, while another tracks the incoming enemy bomber and paints a red blip instead. (Er, wait...)
Related