Split them Up...
We've all been through it, having to deploy a gazillion number of files for a minor change in one or a few classes here and there. It's time consuming, expensive and most of all risky! In a well engineered piece of software, things shouldn't be like this. No matter how good of a software developer you are and how attentive to detail you've been during coding, chances are that you will have to open that project over and over again to change functionalities, visuals and other elements in the project so as to ensure your customers are always satisfied with their websites!
To make things more maintainable, scalable and flexible it is best practice to split the project into the necessary number of layers. The number of layers should be based on the type of project. As a standard example we may take the Three-Tier Architecture.
The Three-Tier Architecture consist of three basic layers:
- Presentation Tier
- Logic Tier
- Data Tier
Each tier can be developed and maintained independently! Let us briefly go through the purpose of each layer and explain what actually fits into each Tier.
The presentation layer is the topmost level of the application. It mostly consist of the user interface including web pages, design concepts and client side visual effects. The design team can code all html pages (with no actual business functionalities) and organize meetings with the client to verify if that's what he/she had in mind aesthetically
The business layer (sometimes also referred to as the Logic Tier) is where all the actual functionalities and processing take place. Mission critical business requirements are handled in this layer including complex algorithms and artificial intelligence techniques used in the project. This layer is the middle layer, it provides all the functionalities required by the presentation layer, and sends and retrieves information to the Data layer as required.
The Data Layer is responsible of storing the actual information in terms of data in database servers. This is the layer which directly interacts with the DBMS and contains all the necessary data handling tools and functionalities so as to make database calls as efficiently as possible.
To wrap it all up, the Data layer gets and retrieves raw data from the actual DBMS, the Business Layer transforms this raw data into useful information to meet the business requirements of the project while the Presentation layer presents this information as aesthetically pleasing as possible to the user.
Using this architecture, if a minor change is required in one of the layers, there is no need to build and test the whole project all over again. Changes can be implemented more specifically and testing can be targeted to a particular layer independently, hence improving Maintainability costs and most of all Software Quality which is what we're all after at the end day.