ну блэт

если ты пишешь не по солиду

то ты всираешься где-то

в 90% случаев

прост ревьюэры разные бывают

Лучше всего по EF подскажет она - Julie Lerman http://thedatafarm.com/videos/

и ты врядли что-то докажешь на собесе

и ты врядли что-то докажешь на собесе

я так с конторы ушел

когда меня заставили логику в модели вернуть

откуда я её успешно выпиливал 2-3 недели

логику чего?

в доменную модель (entity) ?

в любую модель если это мвц

а не мввм

в доменной модели кроме полей нихуя быть не может

потому что по ней генерится скл

ефом

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

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

у тебя твоё говно неконсистентным будет

жидким не по солиду

неконсистентным к чему?

чем SOLID не угодил

надо в истории порыться

чтоб долго не мучаться

с обсуждениями

S - тут хорошо работает. Ничего другого нету.

Иначе получается объект "Кот" может только содержать свое имя и возраст. А ходить и спать за него будут другие.

Я за конструктивную критику, может что то не так.

я конечно нуб, но никогда в туториалах не видел чтобы в модель логику добавляли

Вообщето вся логика в домене и лежит, если про MVC. Домен это не только EF entity. https://habrahabr.ru/post/321050/

Ребят, я слышал что толстые модели это круто. Что думаете на этот счет xD?

Блядь у меня память отказывает

Что это противоречит принципам solid

например

Сука

А какому конкретно?

Single responsibility

сингл респонсибилити

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

да

в каком плане толстые?

и данные и логика

там

Это если в неё запихать ответственность по получению и сохранению в бд

это если в модели запихать ВООБЩЕ что либо кроме полей с данными

я чисто за POCO

в этом смысле

то уже нарушается

срп

Чтоб данные гонять dto придумали же

Так и назвали дата трансфер обджект

у классов dto есть вполне определенная цель - передавать их по сетям всяким. Но это не мешает рядом быть чистым классам поко

Не не, если модель имеет ответственность только контролировать саму себя, где тут нарушение срп?

Какого уровня контроль?

например какой метод

Просто если что-то можно в теории разделить, то это надо разделить

А почему только по сетям? Между уровнями если кидать это уже не дто?

Или между сервисами

а что ты будешь делать если у тебя логика включает в себя несколько моделей?)

Разбивать логику по моделям

Да от команды к команде. как повезет. Я видел чтоб дто юзалось только для вцф и мессаджей сетевых, а для между уровнями юзалось *Object

ага, а если тебе нужна логика которая включает в себя две модели сразу?)

И одни модели будут вызывать другие

и её не получится разбить

залюпа получается

тогда, сервис

ERROR: S client not available

тогда смотри

Но сервис уровня домена

у тебя есть модель

в ней логика

и есть сервис

и там ещё часть логики

не чувствуешь что говном запахло?

Так вот у нас было в Селеранте

Вот так

Два варианта, либо декомпозировать дальше, пока не отпадет потребность в таком сервисе

или потребность пихать что-то в модель

Либо смириться, но смириться только в том случае если действительно не удается эту логику добавить в конкретную модель

охуенно

Лол

мне ещё интересно как у тебя дела с производительностью будут

просто с запросами sql

Но, а где по вашему могут возникнуть проблемы с производительностью?

Я тоже шлепаю тонкие модели как и все) но пытаюсь перейти на светлую сторону)

Так что в ddd теоретик

а окей

вот смотри

как выглядит бизнес лапша обычно?

берем 10 таблиц мерджим и хуйарим всякие Where и Select

и вот тут возникают все проблемы

потому что тебе придется где это эту логику описывать

В сервисе xD

вот к нему и вернулись опять

ну т.е. как в теории по любому не получится

+ тестировать это все говно

Но сервис уровня Application ответственность которого ТОЛЬКО открыть транзакцию, получить данные, и запустить логику модели, результат сохранить

Никакой логики

на