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

действительно. Хотя хочется избежать рефакторинга архитектуры.

ioc

1-1 репозитори паттерн

имхо бест практика

1-1?

1 сущность 1 репозиторий

аа

на иоке

автофак нинжект

только репозитории делай по потребности

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

очень удобно будет

я гарантирую это

1 сущность 1 репозиторий

тогда проще иметь базовый репозиторий с базовыми методами типа Find, GetAll и прочее

тогда проще иметь базовый репозиторий с базовыми методами типа Find, GetAll и прочее

++

с оверрайдом

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

тогда проще иметь базовый репозиторий с базовыми методами типа Find, GetAll и прочее

это история вечного холивара :)

ну в общем это и есть вся суть

1 бейз репозитори с классикой, оверрайды по нужде

будет удобно и просто скаффолдить

хуйню написал

расширять

вот господа, скажите мне, кто из вас, после того как насоздавал репозиториев и кучу других абстракций типа юнит оф ворка, хоть раз в жизни менял EF на что-то другое или хотябы писал юнит тесты на эти репозитории с моками? :)

вечер пятницы спасибо что живой

вот господа, скажите мне, кто из вас, после того как насоздавал репозиториев и кучу других абстракций типа юнит оф ворка, хоть раз в жизни менял EF на что-то другое или хотябы писал юнит тесты на эти репозитории с моками? :)

Даппер + еф гибрид

Не менял

Но, можно работать без репозиториев впринципе

вот господа, скажите мне, кто из вас, после того как насоздавал репозиториев и кучу других абстракций типа юнит оф ворка, хоть раз в жизни менял EF на что-то другое или хотябы писал юнит тесты на эти репозитории с моками? :)

> менял EF на что-то другое сейчас набегут адепты EF НИНУЖОН

Люблю еф

На бестпрактисах хорошая ормка

was is dast EF?

ааа

следует ли создавать в сервисе отдельно два репозитория для каждой сущности, соответствующей таблице в БД?

Мое мнение - один репозиторий на корень агрегации

В синергии с даппером на узких местах по пефомансу 10000/10

Enitity Framework

а нафига тогда поверх еф городить эти абстракции? (если у вас только еф и нет тестов) датасет в еф == репозиторий датаконтекст == уов

а нафига тогда поверх еф городить эти абстракции? (если у вас только еф и нет тестов) датасет в еф == репозиторий датаконтекст == уов

Удобства ради

Удобства ради

сомнительное удобство, хуячить бойлерплейт

а нафига тогда поверх еф городить эти абстракции? (если у вас только еф и нет тестов) датасет в еф == репозиторий датаконтекст == уов

В лишней абстракции не вижу смысла

Мое мнение - один репозиторий на корень агрегации

а чиво такое корень аггрегации?

Контекст ef уже uow

а нафига тогда поверх еф городить эти абстракции? (если у вас только еф и нет тестов) датасет в еф == репозиторий датаконтекст == уов

у меня, конечно, не было кейсов уровня "поменяй ef на что-то другое", но разве не проще будет это сделать, когда у нас вся работа с контекстом инкапсулирована в репозитории?

а не раскидана по коду как дурная

сейчас покурю и включусь в беседу обратно. холодно :)

Вопрос

Зачем менять еф на что-то другое?

На чайник можно поменять

Потому что чайник вроде классный говорят

https://github.com/docevaad/Chain

Но мне допустим доставляет еф кодфирст

Т.к его очень удобно использовать в связке

С микроормками которые по пефомансу делают еф

Ef очень монструозен и медленен, когда нужно тащить сущность с кучей инклудов, запросы становятся просто адовыми

Ef очень монструозен и медленен, когда нужно тащить сущность с кучей инклудов, запросы становятся просто адовыми

Потому связки

Микроормки очень быстрые в таких вот вопросах

А еф предоставляет хороший костяк

Там все в подзапросы оборачивается

+

Даппер тот же пюр скл

пефоманс зависит от твоего скл скилла

Ef очень монструозен и медленен, когда нужно тащить сущность с кучей инклудов, запросы становятся просто адовыми

queryable и select только того, что нужно разве не решает эту проблему?

queryable и select только того, что нужно разве не решает эту проблему?

ну зависит от связей :) лейзи лоада.. легко можно получить select n+1

Очень нужно почти все) приходится делить на подзапросы и loadcollection

ERROR: S client not available

просто у многих миссюз всех этих паттернов (репозитория, уов) поверх еф кто-то вообще не парится и из репозитория возвращает IQueryable ну и нафиг оно надо тогда?

кек

ради иока, что бы юнит тесты написать? проще сделать аксептанс тест, он наверное будет более показателен

я не говорю что оно не нужно просто зачастую обычно зачем то все всё усложняют

чтобы соответствовать SOLID

ну именно заменямости фреймворка

мало ли что

чтобы соответствовать SOLID

HUELID

все знают солид

но инкто его не соблюдает

все знают о тестах

но их никто не пишет

за тесты не плотят

ebani pizdec vsratost

ну тогда в репозитории надо не поко классы совать, а бизнес объекты а репозиторий уже знает как бизнес объекты раскидать в поко и заперсистить

ага

а когда у тебя объект = поко энтитя, да еще с атрибутаим от еф - нахуй надо эти репозитории? :)

мм clean code

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

+

везде гуид

короче это спорный момент и зависит от апликухи

да, зависит от..

а еще момент про репозитории... :) а что, если нужно вернуть объект лишь с 2-мя полями и не тащить 10 остальных полей? .GetUserByIdWithoutExtraFields? :)

а промизы в c# любите юзать?

(я просто вкатываюсь в с# из swift)

а промизы в c# любите юзать?

ты жаваскриптер чтоле? :)

айосник

(я просто вкатываюсь в с# из swift)

а.. свифт

в шарпе это таски

без тасков никак :)