You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, application performs database operations directly in the handler layer. This architecture presents several challenges:
Database Connection Management: It becomes difficult to efficiently manage and configure database connections when they are scattered throughout the handler layer.
Limited Maintainability: Making modifications to database-related methods becomes cumbersome and error-prone since the logic is not centralized.
Business Logic Constraints: The current structure makes it challenging to write and test pure business logic independently of database operations.
Potential Side Effects: Since the request object contains direct database access capabilities, database operations can be performed from any location in the code, potentially leading to unexpected side effects.
Also some database-related methods are functioning as "super methods" that accept a wide range of parameters and perform multiple responsibilities in a single operation. This increases code coupling and reduces maintainability, necessitating the decomposition of these methods into smaller, focused methods within the repository layer.
Required Features
To address these issues, we need to implement repository layer that will:
Design layer that injected minimum dependencies (not root context)
Encapsulate all database access logic (focusing CRUD in this issue)
Analyze ‘super method’ and split them into small methods
Encapsulate all database access logic (focusing CRUD in this issue)
Use case of resolve_vfolder_rows can be organized like below table. But as resolve_vfolder_rows is a wrapper method of query_accessible_vfolders(for parsing aiohttp.web.Request and pass value to query_accessible_vfolders), resolve_vfolder_rowscan be integrated refactoredquery_accessible_vfoldersmethods
Motivation
Currently, application performs database operations directly in the handler layer. This architecture presents several challenges:
Also some database-related methods are functioning as "super methods" that accept a wide range of parameters and perform multiple responsibilities in a single operation. This increases code coupling and reduces maintainability, necessitating the decomposition of these methods into smaller, focused methods within the repository layer.
Required Features
To address these issues, we need to implement repository layer that will:
Encapsulate all database access logic (focusing CRUD in this issue)
Analyze ‘super method’ (such as
query_accessible_vfolders
) and split them into small methodsquery_accessible_vfolders
are!스크린샷 2025-02-03 오후 6.10.47.png|width=100%,alt="스크린샷 2025-02-03 오후 6.10.47.png"!
so we can split them with their own concerns like below. Validation logics must be implemented in service layer, not repository layer
resolve_vfolder_rows
Use case of
resolve_vfolder_rows
can be organized like below table. But asresolve_vfolder_rows
is a wrapper method ofquery_accessible_vfolders
(for parsingaiohttp.web.Request
and pass value toquery_accessible_vfolders
),resolve_vfolder_rows
can be integrated refactoredquery_accessible_vfolders
methods!스크린샷 2025-02-03 오후 6.21.41.png|width=100%,alt="스크린샷 2025-02-03 오후 6.21.41.png"!
Impact
This architectural change will help establish a more robust and maintainable system while reducing the risk of unexpected database interactions.
Testing Scenarios
The text was updated successfully, but these errors were encountered: