Car Service Record Management System
Design Rationale
System Architecture Rationale
We have explained or pointed to a good deal of the thinking that went into a good number of the design choices throughout the entirety of this material. At the highest possible level, our primary concerns are the following: the data that the system needs to manage and store; the business logic; and an interface to the system. There is a distinct pattern emerging here for a layered architectural design. When we use a layered or three-tier architecture, we can take advantage of the following benefits:- It uses an architecture that has been proven to work for contemporary web apps.
- Separate layers make subsequent expansion less difficult. (that is, a single REST API may be utilized by a number of different front-end applications).
- Separation of code makes both development and maintenance much simpler.
- Scalability can be controlled separately by components.
Database Design Rationale
The relational database model is the one that we choose to use for the storage of the system's structured data. The main things that led to this conclusion were the level of development that relational databases reached and the ACID (atomicity, consistency, isolation, and durability) properties of these databases. In the end, what this comes down to is making sure that the data that is stored in the system is completely trustworthy.
We chose Azure SQL database service as our database platform because it can both run in the cloud and meet the need to standardize on a single platform. By using SQL standards, it may be possible to build the database without being tied to a specific database management system.Azure SQL database service platform is low-cost, scalable.
Web Application Design Rationale
The tech stack that we will be using for this will be React, HTML, JS, Java, and MySQL. A few
significant advantages of developing the application as an Single Page Application (SPA) deliverable
are - CDN can be used to develop and deploy the application, which will speed up the loading of
HTML,
JS,
and other resources;
we may create the user interface with React in manageable, reusable modules.
An alternative to our approach would be a more conventional web application such as using PHP, in
which requests are
made
to a server, the pages are created, and then the user is redirected to them. With such a strategy,
the loading of the Pages will be slower as we
would need to connect our frontend application with the REST API application and extra
resources will be required
to handle the entire stack. The SPA strategy best meets our needs due to these
factors.
Backend Design Rationale
The REST API is a critical component of our system. It decouples data storage from the user interface. Due to the separation, it is easier to run our front end and back end on different servers. This is not a requirement of our system, but the REST API gives us this freedom. Meanwhile, it allows other third-party apps to use our database's data for their own creations. Each application will run alone, with no interference from the others. Furthermore, it makes no difference what language the third-party developers are using.
They can use our service in the same way regardless of whether they have Python, Java, or PHP. Also, the separation will make it easier for different development teams to work on different parts of the system when we start making and putting it into action.
Our REST API will be built using Java and the DAO (Data Access Object) design pattern. It will be object-oriented and based on the design pattern. As explained in the high-level design section (the data access layer), DAO abstracts and wraps all data-related actions into a single layer. DAOs are the only objects that interact directly with the database. As a result, if the structure of our database changes, it will only affect the methods implemented within the DAO classes.
The DAO design pattern follows "coding to the interface," which is one of the best ways to write object-oriented code. The interface is the foundation of the DAO pattern. Other sections of the REST API concentrate on what each DAO does rather than how it does it. Within DAO classes, the implementation is free to alter as long as it provides the same functionality. This loosens the coupling between each component and better prepares us for future adjustments. Another benefit of using the DAO style is that the JUnit tests run faster. Because all data access is wrapped up in DAO classes, test data, often known as "mock data," can be used. In essence, the main benefits of the DAO pattern are the separation of roles and the loose connections between them. Because user demands Because science and technology are constantly evolving, this feature will make it easier for our system to accommodate changes.