[TECH] GUHADA Update: The Basic Coding Structure I
Another day for GUHADA’s update!
We apologize in advance for all the difficult to understand programming-based terms (if any).
Alright! With that being said, let’s go over GUHADA’s basic coding structure (Java).
Out of all the modules for GUHADA, we will use the example of the “product” module to explain the development structure.
For the development of the platform, the product module is one of the important parts of the platform, and as everyone knows that the first page of the website should show “products” in an open market platform. Also, the product page for the sellers, the registration of the products should be easily interactive. So, there is a lot of processes involved in the development of the product page and more.
So, let’s talk about the development of GUHADA by using product page development as an example.
GUHADA’s Overall Development Structure (java):
The GUHADA’s basic coding structure is divided into 7 parts as you can see below and each part will be explained.
1. Config: Swagger setting/base setting
2. Controller: Client request/dispatcherServlet return
3. Exception: Exception setting
4. Model: A domain model in problem-solving and software engineering is a conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain.
5. Utility: A helping function
6. Service: Practical logic implementation.
Configuration works as a basic swagger/base setting. The programming of the “config” is shown below.
This is where the user enters and decides how to process the selection. The controller only makes decisions and the actual processing is done by Layered Architecture.
In the service application, many tasks are processed as the controller object and the Repository are connected.
The service does not use unnecessary “Http” or the “HttpServlet” inheritance but uses java object itself.
(because of it, it cannot receive service, request, and/or response converted as parameters. The use of such parameters has to be done at the controller)
So, regardless of which type of signal, if only the necessary parameters are received, it can process at its own business logic. Which means that through the modulation, it is a class file that can be reused anywhere. So it is not simple Web-based, but afterward, used as the native app, even if the view unit changes, the service does not have subordinate code on view, which can be reused as it is.
The model creates software for solving issues with computer programming, such as defining the requests, languages, functions, the base concept of the model for the academic domain.
We have defined the function that is required for technical development. The information below is about the function that converts data to Json. Depending on the need, it converts the object to either String or Json. Other than that, the String conversion option for Date-Time option is defined.
So this wraps up the base coding structure for the currently developing GUHDA’s homepage of the product, order and the user section that are currently under development.
Thank you for reading!
Please stay tuned for the next development update of the GUHADA platform!
TEMCO: Innovative Supply Chain Data and E-Commerce Solution through Blockchain and Smart Contract Technology.
Please visit us to learn more about the world’s first Bitcoin smart contract based supply chain data/e-commerce platform!
▶TEMCO Official Website: https://temco.io
▶TEMCO Chatroom: https://t.me/temcolabs
▶TEMCO Twitter: https://twitter.com/TEMCOLABS
▶TEMCO Reddit: https://www.reddit.com/r/temcolabs