The Presentation-Abstraction-Control architectural pattern is widely used. I prefer this pattern over other patterns like Model-View-Controller, because it does not lack third party component integration and allows better decoupling of components. «The abstraction component retrieves and processes the data, the presentation component formats the visual and audio presentation of data, and the control component handles things such as the flow of control and communication between the other two components». As you see it has three main layers, as MVC does, but this pattern allows integration of third party components and it is not limited to database models. Think on such applications using third party APIs, where you are not using a Model, ideally you are designing an abstraction to that API to be integrated in your application. Here the PAC patter fits much better than MVC.
The PAC pattern and MVC pattern is composed by components, not single classes as you think. Each architectural pattern is built on top of components and design patterns, and design patterns are built on top of classes. The core pattern can be represented as follows, where you have several PACs interacting through the control component, using the abstraction to retrieve and store data, and using the presentation to render data.
For example if your presentation is a Web Service, that components that renders the XML is your presentation component, that component that modifies the data and process the input based on business logic is the control component and that component used to retrieve or store data as an abstraction of a well known storage like an RDBMS storage or NoSQL storage, is your abstraction component. The same applies to XSLT renders a template, that component that renders the XSTL is your presentation component, where it should be only doing presentation tasks, without business logic, even if it is a simple summation.
On large systems, is not so hard to see abstraction components connected to presentation components, implementing more layers in the system. That kind of multi-layered systems are more complex but can be easily integrated using the proper abstractions, like Service Bus and similar ones — mainly on Service Oriented Architectures — whether you can fit another architectural pattern like MVC if it is required. I think that day to day applications are using more complex architectures, requiring more complex patterns and integrations, but you must try to keep everything as simple as you can. Overarchitected applications are not easy to maintain.
Entries 