Is your feature request related to a problem? Please describe.
The ConnectionInterface class is conflating business logic and data-layer logic into one class. This violates the SR(single-responsibility) principle, which makes it hard to extend, test and refactor a component(evident w/ the lack of tests and even difficulty to write tests)
Describe the solution you'd like
A clear boundary needs to be defined between business logic and data-layer logic.
Introduce two separate components.
-
One that's responsible purely for interacting with the database(fetching and persisting data).
This provides an interface containing methods to support the business logic component.
It also makes it easier to replace this component for a different one(if you wish to use a different DB implementation such as NoSQL)
-
The second business service, which performs business logic(applying blocks/rounds, verifying transactions, updating del stats, etc) while leveraging the data-layer component only when it needs to interact with the data models
This makes it easier to write tests(stubbing is much easier), refactor, or extend said logic as needed.
Is your feature request related to a problem? Please describe.
The
ConnectionInterfaceclass is conflating business logic and data-layer logic into one class. This violates the SR(single-responsibility) principle, which makes it hard to extend, test and refactor a component(evident w/ the lack of tests and even difficulty to write tests)Describe the solution you'd like
A clear boundary needs to be defined between business logic and data-layer logic.
Introduce two separate components.
One that's responsible purely for interacting with the database(fetching and persisting data).
This provides an interface containing methods to support the business logic component.
It also makes it easier to replace this component for a different one(if you wish to use a different DB implementation such as NoSQL)
The second business service, which performs business logic(applying blocks/rounds, verifying transactions, updating del stats, etc) while leveraging the data-layer component only when it needs to interact with the data models
This makes it easier to write tests(stubbing is much easier), refactor, or extend said logic as needed.