Так, наверное, даже правильней будет проводить аналогию) А UML — это просто еще один удобный способ показать внутренний процесс или структуру, там где с помощью кода это не так наглядно или не так быстро
Вам не кажется подозрительным тот факт, что гибкая методология не прижилась нигде, кроме контрактных разработок программного обеспечения? Ну не делают по Scrum-у ни подводные лодки, ни самолёты, ни автомобили. Мудрость предков учит нас, что даже нормальную собачью будку нельзя сколотить без этапа проектирования (карандашный набросок с размерами) и подготовки ТЗ (перечень материалов и инструментов).
Не кажется)
Why do architects, aerospace engineers, and structural engineers all draw blueprints. The reason is that one person can draw the blueprints for a home that will require five or more people to build. A few dozen aerospace engineers can draw blueprints for an airplane that will require thousands of people to build. Blueprints can be drawn without digging foundations, pouring concrete, or hanging windows. In short, it is much cheaper to plan a building up front than to try to build it without a plan. It doesn't cost much to throw away a faulty blueprint, but it costs a lot to tear down a faulty building.
Once again, things are not so clear-cut in software. It is not at all clear that drawing UML diagrams is much cheaper than writing code. Indeed, many project teams have spent more on their diagrams than they have on the code itself. It is also not clear that throwing away a diagram is much cheaper than throwing away code. Therefore, it is not at all clear that creating a comprehensive UML design before writing code is a cost-effective option.
Apparently, architecture, aerospace engineering, and structural engineering do not provide a clear metaphor for software development. We cannot blithely use UML the way those other disciplines use blueprints and models
Diagrams are most useful for communicating with others and for helping you work out design
problems. It is important that you use only the amount of detail necessary to accomplish your goal.
Loading a diagram with lots of adornments is possible but counterproductive. Keep your diagrams
simple and clean. UML diagrams are not source code and should not be treated as the place to
declare every method, variable, and relationship.
Martin C. Robert, Martin Micah. Agile Principles, Patterns, and Practices in C#
Да нет проблемы, можно вообще хоть все запросы делать POST или только PUT, кто ж запретит.
Мне вообще, кстати, кажется что слишком много внимания уделяется транспортному уровню, слишком много телодвижений, что бы просто вызвать процедуру на сервере и получить результат ее выполнения. Лично для себя я больше нашел привлекателен подход RPC через WebSocket с автоматической генерацией удаленных прокси над use case'ами (как хотите их называйте: модели, сервисы, фасады или как угодно). Получается так что я просто пишу новый метод на сервере и фронт просто вызывает этот же метод удаленного прокси и все общение сводится к словно локальному вызову функций. При этом мне вообще не нужно описывать никаких схем, роутов и прочего. Правда пока так, только на своих личных пэт-проектах такое пробовал.
Кстати, не обязательно WebSocket использовать, просто привел пример, так как я это делал. Пусть хоть через HTTP удаленный прокси общается с сервером, но основную идею, думаю, понятно выразил.
Минусовал не я, но, как я понимаю, основные фичи graphQL по сути две:
1. Можно указывать серверу какие поля вернуть в запросе, чтобы убрать лишнюю нагрузку на сеть (такая себе оптимизация)
2. Можно получать вложенные данные одним запросом (например пост и коментарии к нему)
REST ничего такого не подразумевает.
Хотя фичу номер один можно в рест легко добавить скажем как query в url, что-то вроде projection в mongoDB. То вторая фича все же, как по мне, идет несколько в разрез с философией REST, так как пост и комментарии к нему — это два разных ресурса, а значит у них должны быть два разных URL для их получения.
Да похоже на VS Code с перенесенным сайдбаром влево, кастомной темой для подсветки синтаксиса и без панели табов. Вот как у меня выглядит с темой One Dark Pro:
Код придётся рефакторить если поля классов, которые используются в системе один в один соответствуют полям таблиц БД.
Да дело даже не в том соответствуют они один в один или нет, а дело в направлении зависимости. Если ваша бизнес логика зависит от БД, то еще как придется менять. А если ваша бизнес логика скажем использует всего лишь интерфейс, что-то вроде такого IOrderDataAccess и у этого интерфейса есть допустим методы: saveOrder(Order o), findOrdersByDate(Date d), где Order — это как раз и есть entity, то какая разница как имплементация этого интерфейса хранит данные Order — в одной таблице, в 10-ти, в обычном файле или вообще на марсе через http api third party сервиса какого нибудь. Тут как раз направление зависимости другое — имплементация IOrderDataAccess зависит от вашей бизнес логики, а не наоборот.
Я не Java разработчик, по этому не знаю что там в JPA и как.
Это не те Entity, в которых поля один в один соответствуют полям таблиц в БД, да?
Не, не те. Они вообще не имеют никакого отношения к способу хранения информации в постоянной памяти. Вы их можете сохранять хоть в обычном файле вместо БД. Код бизнес логики это вообще никак не затронет.
Что делать, если нужно порефакторить структуру БД? Править код во всех местах, которые используют Entity?
Править код во всех местах вам придется, если вы используете паттерн Active Record, дяд Боб же в своей книге рекомендует отделять зависимости бизнес-логики от деталей (БД или что вы там используете для персистентности) и юзать паттерн Data Mapper, таким образом вам не придется править код во всех местах, если поправите структуру БД или вообще решите сменить какой-нибудь MySql на Mongo, это затронет только имплементацию модуля доступа к данным.
Логика в Entity, пусть даже немного, это как-то стрёмно. Вообще интересно, что автор доклада имел в виду под Entity.
Не скажу что имел ввиду автор статьи, но Роберт Мартин в своей книге разделяет бизнес логику на две:
1. application-specific business rules — они же юз кейсы, они же интеракторы.
2. application independent business rules — они же entities — это соединение в одной сущности критических бизнес данных и критических бизнес правил, которые оперируют на этими данными. Как он сказал: «мы называем эти правила так, потому что они критические непосредственно по отношению к самому бизнесу и будут существовать даже если не будет никакой системы автоматизирующей их». С критическими бизнес данными тоже самое, они будут существовать в бизнесе, даже если не будет автоматизирующей системы для этого бизнеса.
БД по-прежнему должна прочитать данные вплоть до OFFSET
Вы хоть раз с файлами работали? Ничего БД не должна прочитать до OFFSET, если ты знаешь размер каждой записи и количество записей, которые нужно пропустить, то ты просто делаешь сдвиг от начального адреса на количество записей умноженных на размер одной записи — это происходит мгновенно в файловой системе благодаря последовательной адресации, а бд в конечном счете хранит ваши данные как раз в файловой системе и работает в конечно счете именно с ней и я уверен что она оптимизирует данные и старается каждую запись из таблички выравнивать по размеру
Все же дядя Боб рекомендует, что бы был один класс на один use case, а не один класс на 8 use case'ов как у вас. Ну и слово «Interactor» не обязательно добавлять в название класса. Ну и интерфейс репозиториев тоже странный (sendCode, notifyConfirmHashListener и т. д.), он должен отображать работу по обеспечению персистентности бизнес сущностей, а не повторять, почти один в один, интерфейс интерактора
Я так понимаю у Hyperapp никакого Virtual DOM нет, но при этом он сравним по производительности с React и Vue, судя по цифрам в вышеприведенных табличках. Тогда где же все это хваленное преимущество наличия Virtual DOM?
Ну инвиз вроде они тоже как-то обрабатывают, там на видео (в статье по ссылке) есть момент когда бот гонится за игроком и предсказывает примерно в каком месте тени игрок
А что как не энтропия входящих данных и количества возможных ходов из каждой ситуации является той самой сложностью? Вон в шашках ни одно, ни другое не является слишком большим, вот и решили шашки тупым перебором всех возможных ситуаций.
Не кажется)
Мне вообще, кстати, кажется что слишком много внимания уделяется транспортному уровню, слишком много телодвижений, что бы просто вызвать процедуру на сервере и получить результат ее выполнения. Лично для себя я больше нашел привлекателен подход RPC через WebSocket с автоматической генерацией удаленных прокси над use case'ами (как хотите их называйте: модели, сервисы, фасады или как угодно). Получается так что я просто пишу новый метод на сервере и фронт просто вызывает этот же метод удаленного прокси и все общение сводится к словно локальному вызову функций. При этом мне вообще не нужно описывать никаких схем, роутов и прочего. Правда пока так, только на своих личных пэт-проектах такое пробовал.
Кстати, не обязательно WebSocket использовать, просто привел пример, так как я это делал. Пусть хоть через HTTP удаленный прокси общается с сервером, но основную идею, думаю, понятно выразил.
1. Можно указывать серверу какие поля вернуть в запросе, чтобы убрать лишнюю нагрузку на сеть (такая себе оптимизация)
2. Можно получать вложенные данные одним запросом (например пост и коментарии к нему)
REST ничего такого не подразумевает.
Хотя фичу номер один можно в рест легко добавить скажем как query в url, что-то вроде projection в mongoDB. То вторая фича все же, как по мне, идет несколько в разрез с философией REST, так как пост и комментарии к нему — это два разных ресурса, а значит у них должны быть два разных URL для их получения.
Да дело даже не в том соответствуют они один в один или нет, а дело в направлении зависимости. Если ваша бизнес логика зависит от БД, то еще как придется менять. А если ваша бизнес логика скажем использует всего лишь интерфейс, что-то вроде такого IOrderDataAccess и у этого интерфейса есть допустим методы: saveOrder(Order o), findOrdersByDate(Date d), где Order — это как раз и есть entity, то какая разница как имплементация этого интерфейса хранит данные Order — в одной таблице, в 10-ти, в обычном файле или вообще на марсе через http api third party сервиса какого нибудь. Тут как раз направление зависимости другое — имплементация IOrderDataAccess зависит от вашей бизнес логики, а не наоборот.
Не, не те. Они вообще не имеют никакого отношения к способу хранения информации в постоянной памяти. Вы их можете сохранять хоть в обычном файле вместо БД. Код бизнес логики это вообще никак не затронет.
Править код во всех местах вам придется, если вы используете паттерн Active Record, дяд Боб же в своей книге рекомендует отделять зависимости бизнес-логики от деталей (БД или что вы там используете для персистентности) и юзать паттерн Data Mapper, таким образом вам не придется править код во всех местах, если поправите структуру БД или вообще решите сменить какой-нибудь MySql на Mongo, это затронет только имплементацию модуля доступа к данным.
Не скажу что имел ввиду автор статьи, но Роберт Мартин в своей книге разделяет бизнес логику на две:
1. application-specific business rules — они же юз кейсы, они же интеракторы.
2. application independent business rules — они же entities — это соединение в одной сущности критических бизнес данных и критических бизнес правил, которые оперируют на этими данными. Как он сказал: «мы называем эти правила так, потому что они критические непосредственно по отношению к самому бизнесу и будут существовать даже если не будет никакой системы автоматизирующей их». С критическими бизнес данными тоже самое, они будут существовать в бизнесе, даже если не будет автоматизирующей системы для этого бизнеса.
Тут элементарно высчитать размер одной записи, средняя температура по больнице не причем.
Вы хоть раз с файлами работали? Ничего БД не должна прочитать до OFFSET, если ты знаешь размер каждой записи и количество записей, которые нужно пропустить, то ты просто делаешь сдвиг от начального адреса на количество записей умноженных на размер одной записи — это происходит мгновенно в файловой системе благодаря последовательной адресации, а бд в конечном счете хранит ваши данные как раз в файловой системе и работает в конечно счете именно с ней и я уверен что она оптимизирует данные и старается каждую запись из таблички выравнивать по размеру