что вы несете вообще

Rich models никто не отменял

Rich models must have

Какой то aspnet mvc головного мозга что модель это только dto. Например patern active record как в django, laravel и т.д еще и data access через модель юзает

Active record вообще зашквар

Какой то aspnet mvc головного мозга что модель это только dto. Например patern active record как в django, laravel и т.д еще и data access через модель юзает

модель из мвц != модели в асп нет

сука

какие же вы тут дауны

пиздец

стыдно за .нет

а кто говорит что это так?

даже ПХПшники более умные вещи говорят

ты хуйню несёш

asp.net это всего лиш Presenter

морда, нечего больше

Хрен знает как вы делаете. Но у меня выворачивает, когда я вижу логику в моделях даннных

Jit

Вот ты тут говоришь про jit, говоря про язык, разве язык как то связан с имплементацией рантайма? И почему ты думаешь что например у v8 нет компиляции в рантайме?

Хрен знает как вы делаете. Но у меня выворачивает, когда я вижу логику в моделях даннных

это плохой признак, тебе бы к хорошей книжке по ооп на приём попасть

это плохой признак, тебе бы к хорошей книжке по ооп на приём попасть

а как связана архитектура приложения и ООП подход?

морда, нечего больше

asp.net это морда?

Хрен знает как вы делаете. Но у меня выворачивает, когда я вижу логику в моделях даннных

Rich model один из ключевых составляющих DDD. Как минимум подход такой имеет место быть, остальное дело вкуса.

да, морда

точно, уверен?

Он короче не троллит, я понял

Rich model один из ключевых составляющих DDD. Как минимум подход такой имеет место быть, остальное дело вкуса.

хоть один адекватный человек здесь есть)

но просто когда люди не видевшие нечего кроме анемичной модели, строят из себя гуру програмирования, это огорчает =\

Как вы живете после этого, когда вы пихаете логику в модели данных. Модель данных - это само собой подразумевает только данные

не ну сириозли, не ужели мне чтоб создать сущьность "Собака", мне нужна тупая модель Собака и СобакаСервис?

пиши как хочешь, я вообще против репозитория

На счёт репозитори согласен, и тут все согласны что это спорный паттерн

Как вы живете после этого, когда вы пихаете логику в модели данных. Модель данных - это само собой подразумевает только данные

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

но просто когда люди не видевшие нечего кроме анемичной модели, строят из себя гуру програмирования, это огорчает =\

сказал гуру программирования

Реально переписать прогу с фокс про на шарп или пиздец?

ахах, у тебя ещё и EF по всему приложению твоему гуляет?)

не серьёзно?) поцоны что вы тут за хелоувордщики блять)

А че вы делаете, когда логика выходит рамки данной модели?

Спор ниочем

ORM и любая технология хранения данных должна быть инкапсулирована в репозитории

А че вы делаете, когда логика выходит рамки данной модели?

в сервис ее и хай там... главное чтобы тебе было удобно в дальнейшем

Пятница

Перегрелись

ORM и любая технология хранения данных должна быть инкапсулирована в репозитории

Не должна, просто там ее удобнее поддерживать

когда выходит, значит это логика другой модели, либо сервиса

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

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

для бложика и n-tier нехер раскатывать, в одном проекте нахуячить можно

Я ниче што dbContext подтягивается через DI? и его просто заменяешь и все работает дальше. А??

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

и велосипедо строитель

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

до тех пор, пока ты говнокодишь петпроект

и велосипедо строитель

ну кто как

до тех пор, пока ты говнокодишь петпроект

заорал

так и есть

а не чё что DbContext это кусок от EF?

а в нгибернейте сессия например

репозитории не нужны

не 2008 год за окном всё-таки

а не чё что DbContext это кусок от EF?

а не че што его можно обернуть и в реализацию пихать уже все что захочешь?

А че вы делаете, когда логика выходит рамки данной модели?

Ddd не отменяет сервисы это так же один из составляющих как и репозитории. Неплохая книга ddd a step by step или курс по ней на pluralsight. Не обязательно использовать все принципы ddd в проекте, а брать что подходит и нравится

а не че што его можно обернуть и в реализацию пихать уже все что захочешь?

можно, но это уже unitOfWork будет, а не DbContext

в реализации можешь хоть sql конекшены юзать и на чистом sql фигачить

да можеш, но ты должен DbContext скрыть уровнем абстракции

Угу

а репозиторий это и есть эта абстракция

так и делает

кто LazyLoading юзает?

ну так о чем спор?

ERROR: S client not available

лучше бы никто

кто LazyLoading юзает?

надеюсь его выпилят

надеюсь его выпилят

в EFCore его и не впилили

надеюсь его выпилят

для вновь прибывих в ef - почему LazyLoading не оч? :)

для хелоу вордщиков оставляют

я никогда его не юзал особо. а че в нем плохого?

в EFCore его и не впилили

ура

на самом деле если ты прототипируешь что то и накидываешь на скорую руку - полезная тема

Не контролируешь что там происходит и что там из базы вообще подгружается.

для вновь прибывих в ef - почему LazyLoading не оч? :)

ну он тянет все связанные данные сразу, хоть и отложенно но дохера конеш вытягивает

а. типо тупить начинает?

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

ибо он имеет проблему n + 1

да, всё должно заинклюдиться явно

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

да

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

во время работы тянет все связи для конкретной сущности, вроде так... я всегда раньше LazyLoading юзал, он в EF по умолчанию... так что ты его и юзаешь сейчас

так Queryable тянется материализуется уже внутри у тебя, по условию, что еще нужно то? :))

вроде в codefirst его по умолчанию нет

он везде по умолчанию

вроде в codefirst его по умолчанию нет

а коде фёрст то при чем

он везде по умолчанию

кроме EFCore конеш

Ну у меня првычка сначала все скоупом подгрузить, все зависимости к которым будут обращаться через Includ. И потом больше никак подтягиваний из базы

EFCore вообще харош, он в обычный аспешный проект становиться?

EFCore вообще харош, он в обычный аспешный проект становиться?

я не знаю например, я его тока с кором пробовал

Ну у меня првычка сначала все скоупом подгрузить, все зависимости к которым будут обращаться через Includ. И потом больше никак подтягиваний из базы

так и надо

ну ты явно выключал LazyLoad?

а есть же ещё какое то дерьмо помимо LazyLoad и EagerLoad

кто его юзает?

а коде фёрст то при чем

хм... и правда руками отключаю

надор в EF6 всё-таки как оно по умолчанию работает, но мне лень

надор в EF6 всё-таки как оно по умолчанию работает, но мне лень

ахаха, можешь тогда и не задумываться о изучении паттернов и говнокодить дальше))))