Ссылочная целостность данных обеспечивается на уровне СУБД. Проще писать миграции. Проще потом работать с этими данными, строить аналитику и т.п.
Пока что, на уровне СУБД я тоже до последнего стараюсь сохранить общую схему с внешними ключами - я изолирую только код, если у меня нет чёткого понимания когда и почему я буду пилить систему на отдельные сервисы.
Да, и распиливание на отдельные проекты или тем более микросервисы особо ничего не даёт.
А вот тут не согласен. Возможно, дело в личном опыте, но мой говорит, что нарезка даёт очень многое. Если для каждого бита информации нет одного явного места, откуда с ним можно работать и это ограничение не реализовано технически, то очень быстро весь код начинает работать со всей схемой. А в след за этим идёт экспоненциальный рост стоимости разработки, из-за кучи регрессий в неожиданных местах, "волновых эффектах", когда изменение в одной таблице требует изменений во всей кодовой базе.
А, во-вторых, и это наверное даже более важная причина, за схему данных должен отвечать один человек.
Тут я в целом с вами согласен, но зависит от масштабов. У меня нет отсечки в таблицах, но в есть в людях - имхо, при появлении пятого бакэндера в команде надо начинать всё пилить пополам - команду, схему, систему. И там за схему снова будет отвечать один человек.
А в идеале ещё и распиленными на отдельные микросервисы. Обычно это доходит до полного абсурда, когда, например, 3 отдельных микросервиса: пользователи, товары, заказы.
Угу, мне прямо щяс такой легась прилетел, последний баг отлаживал запустив 6 (шесть) микросервисов. Надеюсь продать идею тотального реинженеринга:) Так вот я даже на уровне модулей не это предлагаю, боже упаси - моя идея в том, чтобы провести "транзакционный анализ" и в идеале так нарезать систему, чтобы в выполнении любой транзакции задействовался код только одного модуля.
С одной стороны, против *Controller, *Repo, *DTO я ничего не имею.
С другой стороны *Service - ну как-то так... Не ООП-но и в итоге это часто превращается ПП-подход с процедурами внутри сервисов и структурами данных в сущностях.
С другой стороны, этот суффикс действительно удобен. В результате я для себя пришёл к такой схеме - я нарезаю проект на подсистемы, интерфейс каждой подсистемы определяется классом *Service, а имена вспомогательных классов для реализации этой подсистемы разработчик определяет сам.
Не придуман еще тот язык, на котором можно выразить необходимость явно сохранять изменения в базу или, наоборот, нежелательность при том, что метод есть.
Не уверен, что правильно вас понял, но возможно есть такой язык - Haskell. Если дали IO-монаду - надо сохранять, не дали - не надо:)
Зато придуманы юнит-тесты
У меня в черновике была заметка про тесты, но я решил убрать её, чтобы не размывать фокус поста:)
Проблема Артемия была в том, что он был сторонником лондонской школы тестирования, тестировал отдельные методы, а в тестах сервиса репозитории замокал.
После этого случая он стал сторонником детроицкой школы тестирования и больше у него таких проблем не будет:)
И вот тут я процитирую один комментарий с сайта Роберта Мартина:
А почему вы не цитируете ответ Мартина?:)
You begin by talking about OOD and by the end of the first paragraph have made the most critical of errors: equating OOD with OOP. OOA/D is about THINKING. OOP is about DOING. The two are separate.
* It took me over half a decade to realize that this wasn't true. OOP and OOD are inseparable. OOA is undefined.- UB
К сожалению сама картинка здоровая получилась, а хабр, кажется, не может нормально увеличивать в превью. Могу предложить открыть по прямой ссылке - у меня в ФФ она нормально масштабируется
Ну и с альтернативами, по моему опыту, новичёк скорее просто не сможет решить задачу и придёт с вопросом.
А в JPA новичёк вполне может с полной уверенностью в себе решить задачу, но попутно разложить гору грабель, которые в тесте будут тихонько лежать, а в проде начнут больно бить, если ревью проскочат.
Ну, ваш пост не портит даже то, что вы декларируете ненависть к хибернейту в самом начале.
Спасибо:)
я склонен игнорировать предложения работы, где мне либо предлагают нелюбимые технологии
Да, согласен с вами, но мне кажется, что разработчиков, которые могут и согласны работать с JPA существенно больше тех, кто могут и согласны работать с Spring Data JDBC/jooq и т.п.
Другое дело (опять же имхо), что благодаря простоте их устройства, знание этих технологий не обязательно при найме - даёшь человеку день прочитать мануал и он уже способен их использовать на вменяемом уровне, месяц чуть пристальнее смотришь на ревью и всё, эксперт готов.
Во-первых ещё раз обращу ваше внимание, что это первая версия и в ней действительно могут быть противоречия.
Во-вторых я ещё помедитирую на эту тему, но сходу я не вижу противоречия - при смене реализации, структура диаграммы сохранится, изменятся только тексты внутри блоков.
Но тут действительно есть над чем подумать - кажется надо как-то разделить поведение, которое наблюдаемо через взаимодействия с ресурсами внешних систем (которые фиксированы и не могут изменяться) и поведение, которое наблюдаемо через изменение результатов эффектов чтения внутренних ресурсов (и тут не важно как этот ресурс реализован).
В любом случае, думаю вы правы, в том, что надо разделить краткую и полную нотацию. У них разные контексты и цели.
Взгляд все же предполагает некоторое исследование, доказательства и т.п
я как минимум ожидаю, что будут приведены явные и несомненные плюсы ORM
Тогда вам, возможно, больше понравится мой пост против JPA, где я и признаю бесспорные плюсы JPA, и, на мой взгляд, аргументированно критикую её подход.
Есть ещё черновик поста с критикой подхода к моделированию данных связным графом объектом.
В качестве альтернативы я предлагаю использовать Агрегаты и Spring Data JDBC.
К текущему моменту, я применил Spring Data R2/JDBC в 4 коммерческих проектах, есть определённы сложности (больше всего не хватает Specification), но в целом доволен и намерен и дальше использовать их в качестве технологии работы с БД по умолчанию.
У меня каждый воркспейс — это отдельный "проект". А на стандартный набор окон (браузер, терминал, саблайм, файловый менеджер) навешены шорткаты, которые их разворачивают/сворачивают:) Плюс есть шоткат который работает с "прочими" окнами которые, как правило это как раз являются тулами для работы над "проектом" данного воркспейса (IDE, скайп, почта).
А виджетами/запускалками я не пользуюсь.
Т.е. изменилось только то, что я свой чудо-скрипт написал:)
Возможно бенчи прводились на HDD и значительная доля времени ушла чтение кода с диска, а на SSD разница будет меньше.
Но в любом случае в обмен на это богатый рантайм позволяет вам писать приложение на смеси языков с динамической и статической типизацией и во время разработки использовать JRebel и Plumbr и ещё пачку различных тулов, которые базируются на том, что рантайм может многое рассказать о состоянии программы.
Так же я хз как это с АОТ компиляцией согласуется, но опять же благодаря богатому рантайму можно делать такие вещи: Quasar.
gTmp[0] = -999;
for (int i = 0; i < n; i++) {
for (int j = 0; j < n; j++) {
System.out.print(g[i][j] + " ");
}
System.out.println();
}
И видим, что на самом деле у нас в двумерном массиве используется N ссылок на один и тот же массив gTmp, т, е. используется в N раз меньше памяти. И правильный вариант такой:
st = System.nanoTime();
for (int i = 0; i < n; i++) {
gTmp[i] = 1;
}
for (int j = 0; j < n; j++) {
System.arraycopy(gTmp, 0, g[j], 0, n);
}
en = System.nanoTime();
Один прогон которого даст примерно одинаковые времена:
промахнулся
или нет?♂️
Вам спасибо за комментарий:)
Пока что, на уровне СУБД я тоже до последнего стараюсь сохранить общую схему с внешними ключами - я изолирую только код, если у меня нет чёткого понимания когда и почему я буду пилить систему на отдельные сервисы.
А вот тут не согласен. Возможно, дело в личном опыте, но мой говорит, что нарезка даёт очень многое. Если для каждого бита информации нет одного явного места, откуда с ним можно работать и это ограничение не реализовано технически, то очень быстро весь код начинает работать со всей схемой. А в след за этим идёт экспоненциальный рост стоимости разработки, из-за кучи регрессий в неожиданных местах, "волновых эффектах", когда изменение в одной таблице требует изменений во всей кодовой базе.
Тут я в целом с вами согласен, но зависит от масштабов. У меня нет отсечки в таблицах, но в есть в людях - имхо, при появлении пятого бакэндера в команде надо начинать всё пилить пополам - команду, схему, систему. И там за схему снова будет отвечать один человек.
Угу, мне прямо щяс такой легась прилетел, последний баг отлаживал запустив 6 (шесть) микросервисов. Надеюсь продать идею тотального реинженеринга:) Так вот я даже на уровне модулей не это предлагаю, боже упаси - моя идея в том, чтобы провести "транзакционный анализ" и в идеале так нарезать систему, чтобы в выполнении любой транзакции задействовался код только одного модуля.
Я с вами частично согласен, частично нет.
С одной стороны, против *Controller, *Repo, *DTO я ничего не имею.
С другой стороны *Service - ну как-то так... Не ООП-но и в итоге это часто превращается ПП-подход с процедурами внутри сервисов и структурами данных в сущностях.
С другой стороны, этот суффикс действительно удобен. В результате я для себя пришёл к такой схеме - я нарезаю проект на подсистемы, интерфейс каждой подсистемы определяется классом *Service, а имена вспомогательных классов для реализации этой подсистемы разработчик определяет сам.
Не уверен, что правильно вас понял, но возможно есть такой язык - Haskell. Если дали IO-монаду - надо сохранять, не дали - не надо:)
У меня в черновике была заметка про тесты, но я решил убрать её, чтобы не размывать фокус поста:)
Проблема Артемия была в том, что он был сторонником лондонской школы тестирования, тестировал отдельные методы, а в тестах сервиса репозитории замокал.
После этого случая он стал сторонником детроицкой школы тестирования и больше у него таких проблем не будет:)
Добавил переводы, спасибо
Бесстыжий плаг
С одной стороны я с вами согласен - многие принципы, включая солид, действительно слишком абстрактные.
С другой стороны есть вполне конкретные - принцип ацикличных зависимостей, например.
Согласованный набор таких принципов я пытаюсь собрать в Эргономичном подходе: https://azhidkov.pro/posts/22/04/220409-ergo-approach-v10m1/
А почему вы не цитируете ответ Мартина?:)
Но вообще я с вами согласен ООП != ООД.
К сожалению сама картинка здоровая получилась, а хабр, кажется, не может нормально увеличивать в превью. Могу предложить открыть по прямой ссылке - у меня в ФФ она нормально масштабируется
Ну и с альтернативами, по моему опыту, новичёк скорее просто не сможет решить задачу и придёт с вопросом.
А в JPA новичёк вполне может с полной уверенностью в себе решить задачу, но попутно разложить гору грабель, которые в тесте будут тихонько лежать, а в проде начнут больно бить, если ревью проскочат.
Спасибо:)
Да, согласен с вами, но мне кажется, что разработчиков, которые могут и согласны работать с JPA существенно больше тех, кто могут и согласны работать с Spring Data JDBC/jooq и т.п.
Другое дело (опять же имхо), что благодаря простоте их устройства, знание этих технологий не обязательно при найме - даёшь человеку день прочитать мануал и он уже способен их использовать на вменяемом уровне, месяц чуть пристальнее смотришь на ревью и всё, эксперт готов.
мастер йода деткед?♂️
Вам спасибо за комментарий - я узнать рад, что вы нашли пост полезным:)
Спасибо за замечание
Во-первых ещё раз обращу ваше внимание, что это первая версия и в ней действительно могут быть противоречия.
Во-вторых я ещё помедитирую на эту тему, но сходу я не вижу противоречия - при смене реализации, структура диаграммы сохранится, изменятся только тексты внутри блоков.
Но тут действительно есть над чем подумать - кажется надо как-то разделить поведение, которое наблюдаемо через взаимодействия с ресурсами внешних систем (которые фиксированы и не могут изменяться) и поведение, которое наблюдаемо через изменение результатов эффектов чтения внутренних ресурсов (и тут не важно как этот ресурс реализован).
В любом случае, думаю вы правы, в том, что надо разделить краткую и полную нотацию. У них разные контексты и цели.
Бесстыжий плаг
Тогда вам, возможно, больше понравится мой пост против JPA, где я и признаю бесспорные плюсы JPA, и, на мой взгляд, аргументированно критикую её подход.
Есть ещё черновик поста с критикой подхода к моделированию данных связным графом объектом.
В качестве альтернативы я предлагаю использовать Агрегаты и Spring Data JDBC.
К текущему моменту, я применил Spring Data R2/JDBC в 4 коммерческих проектах, есть определённы сложности (больше всего не хватает Specification), но в целом доволен и намерен и дальше использовать их в качестве технологии работы с БД по умолчанию.
Вам спасибо за комментарий, рад что статья оказалась полезной для вас:)
У меня каждый воркспейс — это отдельный "проект". А на стандартный набор окон (браузер, терминал, саблайм, файловый менеджер) навешены шорткаты, которые их разворачивают/сворачивают:) Плюс есть шоткат который работает с "прочими" окнами которые, как правило это как раз являются тулами для работы над "проектом" данного воркспейса (IDE, скайп, почта).
А виджетами/запускалками я не пользуюсь.
Т.е. изменилось только то, что я свой чудо-скрипт написал:)
Возможно бенчи прводились на HDD и значительная доля времени ушла чтение кода с диска, а на SSD разница будет меньше.
Но в любом случае в обмен на это богатый рантайм позволяет вам писать приложение на смеси языков с динамической и статической типизацией и во время разработки использовать JRebel и Plumbr и ещё пачку различных тулов, которые базируются на том, что рантайм может многое рассказать о состоянии программы.
Так же я хз как это с АОТ компиляцией согласуется, но опять же благодаря богатому рантайму можно делать такие вещи: Quasar.
И видим, что на самом деле у нас в двумерном массиве используется N ссылок на один и тот же массив gTmp, т, е. используется в N раз меньше памяти. И правильный вариант такой:
Один прогон которого даст примерно одинаковые времена:
One time 56.96192 msc
Two time 50.87872 msc