From 082490c440a628329fe8336b786d7acd9276b306 Mon Sep 17 00:00:00 2001 From: noQils <daffaaqilmahmud@gmail.com> Date: Thu, 27 Mar 2025 15:10:00 +0700 Subject: [PATCH] add Reflection Publisher-2 --- README.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/README.md b/README.md index 407a357..8c3d061 100644 --- a/README.md +++ b/README.md @@ -90,5 +90,17 @@ Using a `Vec` (list) would not be an efficient solution for ensuring uniqueness The Singleton pattern ensures that only one instance of a structure exists throughout the program, which is useful for maintaining a global state, such as the `SUBSCRIBERS` list. However, in Rust, simply using the Singleton pattern with a `Mutex<HashMap>` or `RwLock<HashMap>` would introduce locking overhead, which can degrade performance when multiple threads try to read or write simultaneously. `DashMap` is designed to provide fine-grained locking, allowing multiple threads to access different parts of the map concurrently without blocking each other. This makes `DashMap` a more efficient and scalable solution for a globally shared, thread-safe `HashMap`. While the Singleton pattern could be used, it would require additional synchronization mechanisms, making `DashMap` the better choice for managing concurrent access to subscribers in a high-performance application. #### Reflection Publisher-2 +### 1. Why Separate "Service" and "Repository" from a Model in MVC? + +Separating "Service" and "Repository" from the Model in MVC follows the **Separation of Concerns** principle, which improves maintainability and scalability. The **Repository** is responsible for interacting with the database, handling queries, and ensuring efficient data retrieval, while the **Service** layer processes business logic and enforces rules. This separation prevents the Model from becoming bloated with both business logic and persistence logic. Additionally, it enhances testability, as we can test business logic independently from the database. It also increases flexibility, making it easier to switch database implementations without modifying business logic. Encapsulation ensures that database operations do not leak into other parts of the application, leading to better security and stability. Without these layers, modifying one aspect of the system—such as changing the database structure—would require altering the entire Model, making the code harder to maintain and extend. + +### 2. What Happens if We Only Use the Model? + +If we only use the Model without separating the Service and Repository layers, the system quickly becomes tightly coupled and difficult to manage. The Model would need to handle database queries, business logic, and possibly even API interactions, leading to a complex and rigid structure. As the application grows, interactions between different models—such as `Program`, `Subscriber`, and `Notification`—would create tangled dependencies. For example, if `Notification` needs data from `Subscriber` but `Subscriber` also updates `Notification`, maintaining such relationships directly within the Model would increase code complexity and risk unintended side effects. Debugging and modifying such a system would be challenging since any change in one model could have unpredictable consequences across others. Additionally, testing would become cumbersome because unit tests would need to interact with the database, slowing down development and making the codebase more fragile. + +### 3. Exploring Postman for API Testing + +Postman is an invaluable tool for API development and testing, allowing developers to efficiently test their endpoints without needing to build a full frontend application. It enables sending HTTP requests such as GET, POST, PUT, and DELETE to interact with APIs, making debugging much faster. One of the most useful features is the ability to **automate tests** by writing pre-request and post-request scripts, ensuring API responses behave as expected. Postman also provides **environment management**, which allows switching between different API environments (development, staging, production) using variables. Additionally, the **Collection Runner** feature enables executing multiple API calls in sequence, which is beneficial for testing workflows such as authentication or transactions. In my current work and group project, Postman helps in validating API endpoints, testing authentication mechanisms, and documenting API specifications for better collaboration. Features like **mock servers, automated testing, and scheduled API monitoring** make it an essential tool for ensuring API reliability in future software engineering projects. + #### Reflection Publisher-3 -- GitLab