feat: add dao layer #2276
feat: add dao layer #2276
Conversation
TheoPascoli
force-pushed
the
feat/poc-add-dao-layer-v2
branch
2 times, most recently
from
41a8416 to
71e988b
Compare
TheoPascoli
force-pushed
the
feat/poc-add-dao-layer-v2
branch
from
71e988b to
c2413a9
Compare
TheoPascoli
force-pushed
the
feat/poc-add-dao-layer-v2
branch
from
c2413a9 to
24e826c
Compare
…sSimulatorTeam/AntaREST into feat/poc-add-dao-layer-v2
# Conflicts: # tests/variantstudy/model/command/test_create_link.py
| def __init__(self, storage_service: StudyStorageService) -> None: | ||
| self.storage_service = storage_service | ||
| def __init__(self, dao_factory: DAOFactory) -> None: | ||
| self.composite_dao = dao_factory.create_link_dao() |
There was a problem hiding this comment.
It's important that we keep an abstract class DAO here, because the manager layer should not know what implementation of DAO it's using.
Typically, for unit tests we could use an in-memory DAO implementation which does not know anything about caching or the study file format or a databse
| from antarest.study.storage.storage_service import StudyStorageService | ||
|
|
||
|
|
||
| class CompositeLinkDAO: |
There was a problem hiding this comment.
See other comment:
I think the composite DAO et the storage DAO should both implement the same interface (abstract class), so they can be used interchangeably.
The cache "DAO" is better separated because actually it's not really a DAO (it has different methods).
| def __init__(self, storage_service: StudyStorageService): | ||
| self.storage_service = storage_service | ||
|
|
||
| def create_link(self, study: Study, link_dto: LinkDTO) -> LinkDTO: |
There was a problem hiding this comment.
After more thought about the design of our "layers":
I think we should try to have business domain classes with plain names like Link, Area, etc.
The DAO will be in charge of implementing "CRUD" operations for those objects.
We should keep "DTO" naming for pure web layer objects.
However, it's something we can change later on, I think.
This PR is a second iteration of a previous one #2248 , which I'm about to close because it is too complex to modify.
I am implementing a DAO (Data Access Object) layer between the business layer (manager) and the storage layer. Additionally, I have implemented a caching logic to accelerate data retrieval, reducing the overhead of fetching frequently accessed data directly from the storage layer.
The goal is to create a clean separation of concerns, allowing the business logic to interact with the data through well-defined interfaces. This approach will make it easier to:
One of the next steps is to reverse the current behavior of the commands. Instead of having the StorageDAO call the commands, I want the commands to directly invoke the DAOs. This inversion will improve modularity and make the system more flexible to extend or modify in the future.
If you have suggestions or see potential improvements, feel free to share them