История изменений
Исправление Nervous, (текущая версия) :
Это не ORM, а DAL (Database Abstract Layer).
Это и есть ORM здорового человека %)
Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.
В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).
Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…
Добавить Редис/Кликхаус/localStorage/S3/1С как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.
Когда cистема не разделена на компоненты и никто не задумывался над её архитектурой — всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом; нельзя даже примерно сказать, сколько займёт конкретная задача (зависит от того, что отвалится в процессе её выполнения); непонятно, на что писать тесты, а на что не надо (следовательно, скорее всего, тесты писаться не будут вообще) — получается типичная разработка на петоне %)
Исправление Nervous, :
Это не ORM, а DAL (Database Abstract Layer).
Это и есть ORM здорового человека %)
Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.
В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).
Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…
Добавить Редис/Кликхаус/localStorage/S3/1С как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.
Когда cистема не разделена на компоненты и никто не задумывался над её архитектурой — всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом; нельзя даже примерно сказать, сколько займёт конкретная задача (зависит от того, что отвалится в процессе её выполнения); непонятно, на что писать тесты, а на что не надо — получается типичная разработка на петоне %)
Исправление Nervous, :
Это не ORM, а DAL (Database Abstract Layer).
Это и есть ORM здорового человека %)
Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.
В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).
Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…
Добавить Редис/Кликхаус/localStorage/S3/1С как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.
Когда всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом; нельзя даже примерно сказать, сколько займёт конкретная задача (зависит от того, что отвалится в процессе её выполнения); непонятно, на что писать тесты, а на что не надо — получается типичная разработка на петоне %)
Исправление Nervous, :
Это не ORM, а DAL (Database Abstract Layer).
Это и есть ORM здорового человека %)
Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.
В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).
Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…
Добавить Редис/Кликхаус/localStorage/S3/1С как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.
Когда всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом и непонятно, на что писать тесты, а на что не надо — получается типичная разработка на петоне %)
Исправление Nervous, :
Это не ORM, а DAL (Database Abstract Layer).
Это и есть ORM здорового человека %)
Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.
В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).
Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…
Добавить Редис/Кликхаус/localStorage как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.
Когда всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом и непонятно, на что писать тесты, а на что не надо — получается типичная разработка на петоне %)
Исходная версия Nervous, :
Это не ORM, а DAL (Database Abstract Layer).
Это и есть ORM здорового человека %)
Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.
В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).
Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда… Добавить Редис/Кликхаус/localStorage как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.
Когда всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом и непонятно, на что писать тесты, а на что не надо — получается типичная разработка на петоне %)