Comments 9
:-) Абстрактная БД всегда более "медленная и потребляющая больше ресурсов" чем конкретная. Т.е. если вам масштабирование, производительность и экономия ресурсов не нужна для прикладного приложения - можете использовать абстрактную БД...
Речь не об абстрактной БД в принципе, а о возможности её заменить. Для того, чтобы можно было впоследствии заменить БД на другую похожую (речь не идёт о том, чтобы иметь возможность заменять "кита на кота"), надо так "нарезать" методы для работы с БД, чтобы каждый метод позволял внутри него написать полноценный оптимизированный запрос к БД, транзакцию в т.ч., пакетизированный запрос в т.ч. Тут приходит на помощь подход ("паттерн") т.н. адаптеров. И тогда в итоге потери сводятся к латентности сетевых запросов (вместо обращения в оперативной памяти), что итак неизбежно, если БД нужно делать отказоустойчивой.
"полноценный оптимизированный запрос к БД, транзакцию в т.ч. " можно написать только под конкретную БД. Мало того под конкретную БД нужно и объекты ее создавать (с учетом особенностей конкретной БД). Ровно так же, под конкретную БД, нужно обеспечивать отказоустойчивость и масштабирование. При этом твердо усвоив что "9 женщин не родят нормального ребенка за 1 месяц".
Заменить одну базу на другую? Серьёзно? Вот это один из самых нелепых аргументов в пользу CA. Это вот требуется да сейчас, когда все пересаживаются с Mssql на Postgre SQL. Во первых это специфический случай, никто и не мог подумать что такое произойдёт , других причин для обмена шила на мыло за кучу денег я не вижу. 2 даже с CA и красиво оформленым persistence layer перезд без тестов в интеграции с базой не полетит и приведёт к тоннам трудновылавливаемых багов. Вообще тезис, что готовится к перезду из нового дома в гипотетический дом в будущем нужно на стадии проекта мне кажется сомнительным:)
Можно как-то привести два примера кода (не говнокода) и показать, что в одном есть clean architecture, а в другом нет?
Я чем больше читаю, тем больше понятно, что критерий нефальсифицируемости clean architecture не пройдет.
Когда я был маленький , мы изучали в институте пораждение смутного гения Вирта - Модулу-2 . Там яйцеголовые изобрели всякие интерфейсы , эту раздельную компиляцию, сборку, линковку и нам студентам вдалбливали - что сначала интерфейс модуля ,его спецификация , а потом имплементация , прошли годы и яйцеголовые додумались до DI , это эволюция этой идеи (которую эксплуатировали бородатые парни, что писали на Си последние 60 лет в *.h файлах, они жили и не тужили без этого DI пописывая скрипты для линковщика ) короче CA я думаю не может без DI. если у вас нет точки в приложении где , вы собираете все проекты воедино, и говорите как разрешать зависимости у вас точно не CA . А пример . ну за пару строк кода не скажешь , СA Это вот как минимум три Проекта в решении . по проекту на слой. я люблю интерфейсы тоже в отдельный проект выносить (Что бы в имплементации лишнего не тянуть . ) А так, в точке сборке обычно прописываются как разрешать сотни интерфейсов какими имплементациями. И есть где то проект в приложении который содержит все ссылки на проекты за исключением тестовых и интерфейсы которые есть у вас в приложении .
Полезная штука, если делаешь сферическое приложение в вакууме. В реальности абстракции быстро начинают протекать и вместо просто системы со своими проблемами получаешь те же самые проблемы плюс сверху иллюзию clean architecture, которую нужно поддерживать
К сожалению, всегда приходится тратить некоторое количество усилий на поддержание порядка в коде. По сути, от кривых рук не спасёт ничего, кроме физических ограничений, аля "вот контракт микросервиса от ребят с большими головами, внутри делай что хочешь, всё равно можно за день будет разобраться и переписать".
Я честно потырил идеи для своих бэкендов из статьи Clean Architecture и не испытываю особых проблем в своих применениях.
А какие абстракции могут протекать? Хочу поупрожняться в том, как я бы это решил.
Я начну: у ентитей есть приватный конструктор, чтобы Dapper мог создать объект из бд.
Clean Architecture