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.
{{ message }}
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.
Repository interfaces : They define an interface for persistence in terms of application level objects. The repository interfaces are not supposed to be gorm specific. The idea is to be able to replace the implementation in tests and to avoid coupling consumers to gorm.
Repository implementations : They implement the repository implementations in a gorm-specific way. They are free to convert app layer objects to a different form. For example, we store work items as JSON in the db, which only has very few data types (number, string, bool, etc.). The repository implementations convert and validate the work item fields according to a given work item type.
Gorm support stuff : Stuff like models.Lifecycle, GormTransactionSupport, etc. This is shared infrastructure for implementing repositories.
What layering means? (Ref)
Is it a bunch of related packages ? Or a layer is a package ?
No, a layer is more abstract: for example the API layer would take care of handling json requests via htttp, the database layer stores things in the db. The characteristics of a layered approach is that you can only call things from layers "beneath" you, not above you. The package structure must follow this layering to some extent in order for build system to know what to compile first.
Structuring a system in layers is a design choice we are free to make or not. Layering imposes certain restrictions on the code you write. The reason you would want those restrictions is to separate the system into parts with controlled interfaces. This reduces coupling between the layers. Code with uncontrolled coupling everywhere is what is generally referred to as "spaghettig code". It gets hard to change and to understand the possible consequences.
So, should we define layers in our system ?
The text was updated successfully, but these errors were encountered:
Problem Statement : Mailing-List Message
Discussion to be done with following inputs.
Kinds of code we have (Ref):
What layering means? (Ref)
Is it a bunch of related packages ? Or a layer is a package ?
No, a layer is more abstract: for example the API layer would take care of handling json requests via htttp, the database layer stores things in the db. The characteristics of a layered approach is that you can only call things from layers "beneath" you, not above you. The package structure must follow this layering to some extent in order for build system to know what to compile first.
Structuring a system in layers is a design choice we are free to make or not. Layering imposes certain restrictions on the code you write. The reason you would want those restrictions is to separate the system into parts with controlled interfaces. This reduces coupling between the layers. Code with uncontrolled coupling everywhere is what is generally referred to as "spaghettig code". It gets hard to change and to understand the possible consequences.
So, should we define layers in our system ?
The text was updated successfully, but these errors were encountered: