Architect Ideas, Feb 2nd, 2011

We know that a software system can be divided into front-side and back-side. Previously, many people agree that the back-side should take the key role of the development workflow, and somewhat, will decide the software development to live or to die.
Now, I found there are some different thought about it. Roughly, we can normally divide a software system into three layers, like many other schools of thought have done. The first is UI layer, the second is control layer, and the third is persistence layer. We regard the OS, DBMS and so on as other things, since generally we, as application developer do not handle more them – what we should do about them just develop some adapter layer to abstract them integrate into our developing system, and screen the differences from multiple persistence system, including in DBMS and OS-this is what we call as persistence layer-this is not data model layer as that is traditionally accepted popularly as the concept persistence layer. Now we don’t abandon the data model concept, it’s useful, but it is not just regarded as layer – yes, sometimes it really works as if a “layer”, but to design a data model layer usually isn’t a better solution for the architecture strategy. Both business logic and data model, which usually is bound with the business logic so firmly, are included in the control layer.
So, there are still three layers, but have different workflow “Hermeneutics”.

1. You should think your application logic leading by UI layer, and build some prototypes
2. The first abstracting should occur at control layer, but this abstraction is dynamic, somewhat like evolution. The abstracting process like this type usually can’t lead to a stable unified framework, instead that more and more frameworks based on the more and more application logic will be evolved , to adapt different application domain, with their data models framework.
3. Another abstracting exits where the persistence layer is. But this is a type of relatively stable abstracting, and differs from that in the control layer.

Based on those different ideas about the application software architecture, naturally, different design and development strategies should be developed. The first thing we can conclude is: for single application, the UI design and implementation will decide the project to live or to die, and the control layer abstracting enough or not, will decide the software to live or to die. As to persistence layer, it will just influence your system’s performance and compatibility, if you didn’t fail to design and develop it too much.
In the web world, there has been an outstanding sample to see the effect of the idea UI(presentation layer logic) lead and organize the control layer and perhaps, persistence layer logic, which make the project more simply and more successfully, in addition to more readily : PHP based web application.