а че там помойка

как реакт но нужно больше строк кода и поэтому больше платят

Проституция - это женская привилегия. Вот у меня денег нет, был бы бабой пошел бы торговать собой, но меня не хотят трахать, говорят я педик уродливый. ЧЯДНТ? Думаю нужно не запрещать проституцию, а наоборот, заставлять мужиков трахать других мужчин, вроде меня, за деньги, чтобы разбавить женскую монополию.

помоему он заработал на бан...

мб шутом работает. я даже думаю, что это бот какой-то.

Проституция - это женская привилегия. Вот у меня денег нет, был бы бабой пошел бы торговать собой, но меня не хотят трахать, говорят я педик уродливый. ЧЯДНТ? Думаю нужно не запрещать проституцию, а наоборот, заставлять мужиков трахать других мужчин, вроде меня, за деньги, чтобы разбавить женскую монополию.

добро пожаловать в RO

тут уже не РО, тут бан. За два дня это уже втторая такая херня.

да я не против, чтобы он читал и просвещался

да я не против, чтобы он читал и просвещался

да тут не поможет

:D

да хватит уже его обсуждать ну

обидеть Эванса может каждый

Хочешь я тебе на React тоже самое напишу?

А что в ангуларе плохого ?

Он сам?)

А что в ангуларе плохого ?

Че пацаны, вьйу?

Че пацаны, вьйу?

Да

еее

Он сам?)

Может просто ты плох?)

Может просто ты плох?)

Может, но одно не исключает второго)

Он сам?)

Можно конкретики? Тоже самое можно сказать про мерседес

Можно конкретики? Тоже самое можно сказать про мерседес

Какой конкретики? Я же не утверждал, просто пошутил. Мнение юзабилитей всегда разное. Я не работаю с ангуларом, знаю что stable 1.5-1.6 ок, но в виду печальности angular html и перенасыщенности всем чем не надо во 2 - меня туда не тянет. Я лучше на реакте посижу

> 2018 > angular 1.6 Ну такое

что-то с чатиком...

вас покусал жаваскрипт?

это про то с какой версией я сталкивался лично и та, после которой мне лично стало не комфортно работать. Исключительно мое мнение, опять же и не претендую на мнения остальных

А что в ангуларе плохого ?

Меняют часто

скажи, насколько сильно похожи структуры в этих твоих слоях?

а скажи, как красивее поступить, если моделька начинает обрастать «сервисной» логикой и в ней начинают появляться поля, которые нужны только в рантайме? и чтобы не делать «отдельный» DO и не писать мапперы обратно. Сделать DO а в нём полем модельку? ¹ Сделать DO потомком модельки? ²

а скажи, как красивее поступить, если моделька начинает обрастать «сервисной» логикой и в ней начинают появляться поля, которые нужны только в рантайме? и чтобы не делать «отдельный» DO и не писать мапперы обратно. Сделать DO а в нём полем модельку? ¹ Сделать DO потомком модельки? ²

плохо понимаю о чем ты

у меня были две очень похожих сущности — DO и Модель базы я убрал DO и мапперы, остаив модель но в процессе работы у меня появляются поля, которые не нужно сохранять в базе и которые нужны только в рантайме. сейчас я их определяю в модели через @Transient, но, кажется, это не очень красиво. мне хочется сделать что-то более высокоуровневое. например DO в который переехали бы поля, нужные только в рантайме и при этом он имел состояние, которое можно сохранить в базу. я не знаю как это сделать красивее. и нужно ли.

я хз нафига нужны такие поля

у меня были две очень похожих сущности — DO и Модель базы я убрал DO и мапперы, остаив модель но в процессе работы у меня появляются поля, которые не нужно сохранять в базе и которые нужны только в рантайме. сейчас я их определяю в модели через @Transient, но, кажется, это не очень красиво. мне хочется сделать что-то более высокоуровневое. например DO в который переехали бы поля, нужные только в рантайме и при этом он имел состояние, которое можно сохранить в базу. я не знаю как это сделать красивее. и нужно ли.

Приведи пример таких полей - интересно.

у меня есть сценарий, в сценарии есть шаги вот сейчас в каждом шаге есть поле «выполнились ли хоть раз условия» это нужно только в рантайме, чтобы по таймеру активировать следующий шаг и этот флаг нужен только в рантайме

у агрегата есть некоторое внутреннее состояние, которое он сам себе установил. может ли это состояние «описываться» моделями базы? если да, то корень агрегата обычно наследник модели или модль лежит в поле?

> по таймеру, только в рантайме а если процесс упадет(деплой, рестарт сервака и т.д.)?

агрегат это просто объект, который вы “сериализуете” в базу

ну как сказать. "сериализация" в базу вещь вынужденная. мне не нравится точка зрения, что агрегат это просто "обьект, который идет в базу". Другое дело в том, что состояние его почти всегда надо полностью в базе хранить. если уж он изменился, то одной транзакцией в базу должно все уйти. и никаких "только в рантайме, а не в базе".

у меня есть сценарий, в сценарии есть шаги вот сейчас в каждом шаге есть поле «выполнились ли хоть раз условия» это нужно только в рантайме, чтобы по таймеру активировать следующий шаг и этот флаг нужен только в рантайме

звучит так как если бы тебе были нужны саги)

ну как сказать. "сериализация" в базу вещь вынужденная. мне не нравится точка зрения, что агрегат это просто "обьект, который идет в базу". Другое дело в том, что состояние его почти всегда надо полностью в базе хранить. если уж он изменился, то одной транзакцией в базу должно все уйти. и никаких "только в рантайме, а не в базе".

есть другие варианты хранения стэйта. Ивент сурсинг например. В этом ключе у тебя в "базе" будет тупо стрим событий, append only, последовательная запись (оч быстро), а весь стэйт приложения можно тупо ложить в память и просто делать снэпшеты в файловую систему периодически что бы меньше надо было проигрывать событий для восстановления стэйта. У фаулера в одном из докладов был похожий пример - там челы держали все тупо в оперативке и обрабатывали в один поток. И поскольку батлнеков было мало все выходило максимально быстро (у них все было критично по лэтенси потому локи не вариант). А для того что бы надежно было - рядом просто висела такая же система которая просто дублировала стэйт из ивентов. Если приложение падает - трафик переключается на другую и уже оно все делало пока первое восстанавливало по ивентам стэйт.

есть другие варианты хранения стэйта. Ивент сурсинг например. В этом ключе у тебя в "базе" будет тупо стрим событий, append only, последовательная запись (оч быстро), а весь стэйт приложения можно тупо ложить в память и просто делать снэпшеты в файловую систему периодически что бы меньше надо было проигрывать событий для восстановления стэйта. У фаулера в одном из докладов был похожий пример - там челы держали все тупо в оперативке и обрабатывали в один поток. И поскольку батлнеков было мало все выходило максимально быстро (у них все было критично по лэтенси потому локи не вариант). А для того что бы надежно было - рядом просто висела такая же система которая просто дублировала стэйт из ивентов. Если приложение падает - трафик переключается на другую и уже оно все делало пока первое восстанавливало по ивентам стэйт.

одна партия в квейк - это тоже агрегат. Но он никуда не сериализовывается.

одна партия в квейк - это тоже агрегат. Но он никуда не сериализовывается.

тут все чуть сложнее.

одна партия в квейк - это тоже агрегат. Но он никуда не сериализовывается.

почти уверен, что сериализовывается

ну и опять же - это все про риски. если у тебя игровой сервер упадет - самое страшное что случится парочка чуваков обматерят тебя и пойдут играть во что-то другое... временно

но это деталь работы персиста

с другой стороны партия в доту - сериализуется. именно потоком эвентов скорее всего. ну так то да. деталь реализации. и те же риски.

например у EA регулярно падают серваки - там даже прогресс не сохраняется)

я просто против фразы "агрегат - это обьект, который сериализуется"

я просто против фразы "агрегат - это обьект, который сериализуется"

ну агрегат это штука которая гарантирует консистентность стэйта

граница твоей бизнес транзакции

угу

а вот уже персистенс - это тупо сериализация этого стэйта

я просто против фразы "агрегат - это обьект, который сериализуется"

чего именно тут против?)

то есть в целом - агрегат должно быть можно тупо сериализовать

все можно тупо сериализовать :)

ну ладно. тупой спор...

все можно тупо сериализовать :)

не

в обычном мире это верно в общем. попросил агрегат чтото сделать - сохранил его стейт(потоком ли эвентов(это кстати не сериализация ни разу) или просто сохранением всего стейта напрямую)

> по таймеру, только в рантайме а если процесс упадет(деплой, рестарт сервака и т.д.)?

объект загрузится, получит актуальное состояние клиента и продолжит работу всё равно за время падения состояние может измениться

Нет

объект загрузится, получит актуальное состояние клиента и продолжит работу всё равно за время падения состояние может измениться

агрегат сам по себе и есть актуальное состояние

а партия в кваку очень ситуативна же. если всё упадёт нужен механизм, чтобы вернуть людей в то же состояние, в котором они были до падения, а это несколько неалгоритмическая задача

а партия в кваку очень ситуативна же. если всё упадёт нужен механизм, чтобы вернуть людей в то же состояние, в котором они были до падения, а это несколько неалгоритмическая задача

если все персистится как надо - то нет проблем.

но не все игры персистят стейт. в ранние годы это было дорого.

если все персистится как надо - то нет проблем.

а как же биологические объекты?

агрегат сам по себе и есть актуальное состояние

возможно, я опять смешиваю полномочия объектов. и рантайм стейт нужно где-то ещё хранить. где-то ближе к бизнес-логике а на каком уровне обычно живёт агрегат с сохраняемым стейтом? на уровне моделей базы? или пролезает на уровень домена?

забудьте про модели базы

почему?

потому что их нет

+

а у меня орм и они почему-то появились

установите орм посерьезнее)

приложение ничего не должно про них знать в таком случае.

т.е. агрегаты обычно живут на уровне приложения? и даже не в домене?

уровней тоже нет

они обман

корни агрегатов, сущности и vo это доменные штуки

но уровни это обман

как тортик? )