Designing a multi layered API architecture: An easy way to code nice.
Introduction
Writing perfect code is the dream of every developer. The definition of good code not only comprises running a functional code but also consists of writing code that is extensible, debuggable, logged, and catches exceptions well. Dividing it into multiple parts and making it maintainable reduces a lot of debugging. Since the code is converted into smaller chunks, changing the particular component becomes easier. Even the changes we are making become localized, simpler, and less extensive than they would otherwise be.
Designing effective multi-layered architecture is a common way to avoid unnecessary problems and write high-quality code.
Project Structure
Multi-layered architecture must be represented by the Project structure designed. Every layer should be enclosed in a particular package where each component should have the same name as the layer itself. This way, getting down to a class where logic is implemented becomes very easy and intuitive. Parallely, this also resolves the problem of where to place a new class.
What are the different layers we are talking about
● Controller Layer: This layer adopts the request from the client browser or presentation layer and dispatches UI elements or event handlers. UI element represents object state or business logic. It notifies any observer when data changes. Every request passes via a controller and retrieves visual object values. A controller:
- manages the incoming work HTTP requests
- decides which worker should do the work
- splits up the work into sizable units
- passes that work the necessary data from the HTTP requests off to the service(s)
● Service Layer: This layer mainly contains the business logic of the application. The service layer is the place that is connected to the data layer to get raw data and get mapped as the response is expected. A Service class typically:
- receives the requested data it needs from the manager in order to perform its tasks
- figures out the individual details algorithms/business logic/database calls/etc involved in completing the request
- is generally only concerned with the tasks he/she has to complete
- not responsible for making decisions about the “bigger” picture and orchestrating the different service calls
- does the actual work necessary to complete the tasks/request
- returns the completed work a response to the manager
● Data Layer: This layer mainly deals with databases, creating connections, executing SQLs, and other data-related operations.A Data layer typically:
- While changing a persistence mechanism, the service layer doesn’t even have to know where the data comes from. For example, if you’re thinking of shifting from using MySQL to MongoDB, all changes need to be done in the DAO layer only.
- DAO pattern emphasizes the low coupling between different components of an application. So, the View layer has no dependency on the DAO layer, and only the Service layer depends on it, even with the interfaces and not from concrete implementation.
- As the persistence logic is completely separate, it is much easier to write Unit tests for individual components. For example, if you’re using JUnit and Mockito for testing frameworks, it will be easy to mock the individual components of your application.
- As we work with interfaces in the DAO pattern, it also emphasizes the style of “work with interfaces instead of implementation,” which is an excellent OOPs programming style.
● Model Layer: The model represents real-world objects. Thus, these objects are referred to as Models. JPA (Java Persistence API) provides reference or details about ORM( Object Relation Mapping) which means the class can be related to the database table.
● Utils Packages: This layer contains classes that have methods to be used across the applications, the constant values, and the validation methods
