как вы проектируете репозиторий
95
27
Rionnag сказал(а):↑Все, что создаётся в результате сборки проекта, не должно хранится в репо. Обычно .gitignore сам туда все расширения вписывает, но никто не мешает дополнить
Нажмите, чтобы раскрыть...ты не понял, репозиторий - это такой интерфейс в слое данных
YoshkinKot сказал(а):↑ну мусор там не храню: логи, сторонние библиотеки
Нажмите, чтобы раскрыть...я так понял, суть статьи, которую прочитал: типа хранить весь апи и подключения к бд как отдельные сущности
и инжектить их в репозиторий, например в конструктор
pyles сказал(а):↑ты не понял, репозиторий - это такой интерфейс в слое данных
я так понял, суть статьи, которую прочитал: типа хранить весь апи и подключения к бд как отдельные сущности
и инжектить их в репозиторий, например в конструктор
Нажмите, чтобы раскрыть...соре я тогда тоже не так понял
я думал как репу гитовую свою красиво уложить
MEDI_OFF сказал(а):↑Ты про репозиторий паттерн или репозиторий как VCS?
Если про паттрен то хз что там проектировать, это же самый простой для понимания, это по факту тупо фасад для доступа к данным (CRUD) а какая там реализация это вообще плевать
Нажмите, чтобы раскрыть...дочитал я значит статью. там была месседж в том, что создаются три одинаковых по содержанию дата класа:
домеин, дб ентити и дто. а надо типа сделать разные сущности и мапить одно в другое.
типа дто мапим в ентити, ентити мапим в домеин и так далее
я просто не думал, что можно делать как то по другому
Я бы избегал слова "надо", ибо все по хорошему от задач, но ты сейчас описал не репозиторий, а 2 подхода для работы с БД, можешь погуглить если интересно, Active record и Data mapper
Репозиторий как паттрен вообще не имеет отношения к бд, он лишь устанавливает интерфейс для доступа к данным, а то как доступ реализован Active record, data mapper, голубиная почта, api вообще не про репозиторий
pyles сказал(а):↑я просто не думал, что можно делать как то по другому
Нажмите, чтобы раскрыть...Можно по всякому, если ты один разработчик на проекте, а делаешь ты сайты визитки с обратной связью, то вообще забей на это все и просто делай максимально быстро, а если у вас большой нагруженный проект, и он работает, то там уже скорей всего есть какой то подход, и не обязательно тот который ты описал, тебе нужно лишь следовать ему, можешь конечно это все изучать чисто в позновательных целях, есть книги по DDD, но по опыту скажу что без практики на реальном проекте где такое применяется и ты знаешь подводные камни, с 0 затащить куда то в новый проект такое переусложенение это выстрел в ногу потому что - 1. Получиться гавно, 2. Оно скорее всего будет очень плохо работать и тебе придеться каждому объяснять что ты имел ввиду
Репозиторий, UnitOfWork - антипаттерны.
Если говорить про .net, то все действия разделяю через mediatr(команды/запросы) и уже в каждом действии напрямую обращаюсь к контексту бд. Перед обработкой каждого действия идет валидация параметров для этого действия, если настроен пайплайн для этого. Ну и в самой обработке действия дополнительно использую спецификации. Такой способ применяю как для asp.net, так и для десктоп wpf приложений.
UPD:
Если для обработки действия(запрос, команда) нужен какой-то специальный сервис, например, генерация jwt, то в конструктор этого действия пробрасываю интерфейс, а саму реализацию объявляю либо на этом уровне(что редко), либо на внешних слоях, т.к использую луковичную архитектуру.
MEDI_OFF сказал(а):↑
Интересно как ты пришел к такому умозаключению
Нажмите, чтобы раскрыть...Куча статей от умных людей в гугле на эту тему есть. Про UnitOfWork мало кто будет спорить, но в чем смысл репозитория? Это же всего лишь еще один ненужный слой абстракции над контекстом с данными. Что мешает делать напрямую все действия? Если нужно проводить какие-либо действия при выполнении методов, то можно в реализации контекста их переопределить.
Lapish72 сказал(а):↑Куча статей от умных людей в гугле на эту тему есть. Про UnitOfWork мало кто будет спорить, но в чем смысл репозитория? Это же всего лишь еще один ненужный слой абстракции над контекстом с данными. Что мешает делать напрямую все действия? Если нужно проводить какие-либо действия при выполнении методов, то можно в реализации контекста их переопределить.
Нажмите, чтобы раскрыть...погуглил
в статьях говорится про Generic Repository. Возможно, он как раз и плох, не использовал
А вот конретные репозитории под сущности - по мне отличная штука
Прекрасно изолируют бизнес-модель данных от модели их хранения
Для меня репозиторий это способ реализовать CRUD и кэшировать загруженные сущности
Lapish72 сказал(а):↑Куча статей от умных людей в гугле на эту тему есть.
Нажмите, чтобы раскрыть...Ну хз где ты такое вычитал, если только не гуглил напрямую такой запрос, но я так про каждый паттерн могу найти тогда
Lapish72 сказал(а):↑Это же всего лишь еще один ненужный слой абстракции над контекстом с данными. Что мешает делать напрямую все действия? Если нужно проводить какие-либо действия при выполнении методов, то можно в реализации контекста их переопределить.
Нажмите, чтобы раскрыть...Ничего не мешает тебе делать все напрямую, вопрос в будущей поддержке кода и его сопровождении
Ты выше пишешь что используешь использую луковичную архитектуру, но в этом своем сообщении спрашиваешь зачем лишний слой абстракции
, если у тебя мало-мальски нормальный проект то у меня сразу куча вопросов на которые я хотел бы получить ответ, если у тебя доступ к данным происходит в бизнес слое как вы это все тестируете, как вы вносите изменения и потом у вас ничего не падает, как дебажите, какой у вас Time to market, как часто конфликты на мердже солвите, как с дублированием справляетесь?
Если ты просто пишешь свои проектики на 200 строк кода это все может работать но когда у тебя реальный проект с тысячями юзеров и куча разрабов, у вас монорепозиторий (что очень частый кейс, потому что не у всех есть время и ресурсы все распиливать), я хз как ты собрался так работать с таким подходом.
Я не говорю что твой подход плохой, все зависит от задач и ресурсов, но не надо выставлять его как единственно верный и другие вещи это антипаттерны, и не противоречь сам себе
MEDI_OFF сказал(а):↑Ну хз где ты такое вычитал, если только не гуглил напрямую такой запрос, но я так про каждый паттерн могу найти тогда
Нажмите, чтобы раскрыть...Лень искать, но даже были конференции на эту тему в РФ пару лет назад мб. Один из главных тезисов репозитория - мол мы в будущем поменяем субд на другую и все сломается.
В чем смысл, если я добавляю новую сущность через контекст напрямую и вызову сохранение изменений ИЛИ я вызову метод репозитория на добавление этой сущности, которая сделает все тоже самое, но я получил еще 100500 ненужных абстракций. ВОЗМОЖНО они имеют смысл, если это не просто дублирование crud операций, как догадался человек выше.
MEDI_OFF сказал(а):↑Ты выше пишешь что используешь использую луковичную архитектуру, но в этом своем сообщении спрашиваешь зачем лишний слой абстракции
, если у тебя мало-мальски нормальный проект то у меня сразу куча вопросов на которые я хотел бы получить ответ, если у тебя доступ к данным происходит в бизнес слое как вы это все тестируете, как вы вносите изменения и потом у вас ничего не падает, как дебажите, какой у вас Time to market, как часто конфликты на мердже солвите, как с дублированием справляетесь?
Нажмите, чтобы раскрыть...В чем сложность замокать контекст и бд. Вызвать команду/запрос и проверить ее тестом? Вроде 0 проблем?
Lapish72 сказал(а):↑В чем сложность замокать контекст и бд. Вызвать команду/запрос и проверить ее тестом? Вроде 0 проблем?
Нажмите, чтобы раскрыть...Расскажи ка мне как ты мокаешь Insert запросы которые у тебя прямо в слое бизнес логики, или ты на честном слове вставляешь их в моке миную бизнес логику которую нужно проверить? И что ты понимаешь пож контекстом БД, у меня складывается впечатление что мы понимаем разные вещи под этим
UPD:
Скинь примеры тестов, где ты такое делаешь, и что насчет других вопросов?
MEDI_OFF сказал(а):↑Расскажи ка мне как ты мокаешь Insert запросы которые у тебя прямо в слое бизнес логики, или ты на честном слове вставляешь их в моке миную бизнес логику которую нужно проверить? И что ты понимаешь пож контекстом БД, у меня складывается впечатление что мы понимаем разные вещи под этим
UPD:
Скинь примеры тестов, где ты такое делаешь, и что насчет других вопросов?
Нажмите, чтобы раскрыть...Для тестов делаю свою реализацию контекста, которая либо используют другую бд/субд, либо хранит всё в памяти. Регистрирую ее в di контейнере. Вся обработка запросов хранится в слое приложения, потом слой инфраструктуры и представления.
Все команды/запросы через конструктор получают реализацию этого контекста. Контекст.
Lapish72 сказал(а):↑Все команды/запросы через конструктор получают реализацию этого контекста. Контекст.
Нажмите, чтобы раскрыть...
Дядя, ты говоришь что Репозиторий и unitofwork антипатерны, рассказываешь тут про свой подход, а сам используешь и то и то просто терминологию не знаешь
A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.
Это же прямо первая строчка из определения того что ты называешь "Контекст"
UPD:
Вопросы тогда мои отпали, ибо ты юзаешь репозиторий который все эти вопросы и закрывает)
MEDI_OFF сказал(а):↑
Дядя, ты говоришь что Репозиторий и unitofwork антипатерны, рассказываешь тут про свой подход, а сам используешь и то и то просто терминологию не знаешь
A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.
Это же прямо первая строчка из определения того что ты называешь "Контекст"
UPD:
Вопросы тогда мои отпали, ибо ты юзаешь репозиторий который все эти вопросы и закрывает)
Нажмите, чтобы раскрыть...
Дядя, в Java если что тоже самое) Просто "знающие" люди поверх контекста лепят репозитории и unit-of-work'и. Ну и не знать, что такое контекст странно вроде, не?
UPD:
А, забыл. Возможно в 2к23 еще существуют языки без удобной orm
, где нужно лепить антипаттерны
Lapish72 сказал(а):↑
Дядя, в Java если что тоже самое) Просто "знающие" люди поверх контекста лепят репозитории и unit-of-work'и. Ну и не знать, что такое контекст странно вроде, не?
Нажмите, чтобы раскрыть...Странно думать что ты все знаешь, я поэтому и спросил что ты имеешь ввиду под контекстом, просто ты опять сам себе противоречишь, используешь репозиторий и UoW но называешь это контекстом, и пишешь что это все анитпатерны, выучи терминологию и не будет никаких непоняток
Lapish72 сказал(а):↑А, забыл. Возможно в 2к23 еще существуют языки без удобной orm
, где нужно лепить антипаттерны
Нажмите, чтобы раскрыть...Чел не позорься, судя по тому что ты пишешь ты никогда не работал на крупном проекте, и тогда понятно откуда у тебя такие убеждения, но поверь что ORM далеко не панацея, и на большинстве проектов тебе все равно приходиться писать RAW SQL, ибо орм очень часто где не справляется
Ну и опять же получается что в .net нет нормальной орм и поэтому ты используешь антипатерны?
MEDI_OFF сказал(а):↑Странно думать что ты все знаешь, я поэтому и спросил что ты имеешь ввиду под контекстом, просто ты опять сам себе противоречишь, используешь репозиторий и UoW но называешь это контекстом, и пишешь что это все анитпатерны, выучи терминологию и не будет никаких непоняток
Нажмите, чтобы раскрыть...
Я ни разу не противоречил. Можешь посмотреть типичную реализацию UoW и репозитория и сравнить их с контекстом. Мало найдешь сходств)
Чтобы ты не гуглил поясню.
Репозиторий
В контексте ты указываешь параметры подключения к бд, сущности бд и много чего еще(начальные данные, действия после сохранения и.т.п). При обращении к сущности из контекста у тебя есть доступ к crud операциям ИМЕННО этой сущности. Если у тебя 10 сущностей, то у тебя будет 10 репозиториев(чаще всего). А 100 сущностей? Все 100 репозиториев получать через di?
UoW
Типичная реализация - свойства-репозитории. Кусок
^3
Если приложить максимум усилий, то от UoW можно взять, что свойства-сущности - свойства-репозитории, а сама сущность внутри контекста - этакий репозиторий. Но все это сделано настолько гениально насколько другие яп не могут сделать. Zero говнокода.
MEDI_OFF сказал(а):↑и на большинстве проектов тебе все равно приходиться писать RAW SQL, ибо орм очень часто где не справляется
Нажмите, чтобы раскрыть...Мб еще хранимые процедуры вызываешь, запивая все это антипаттернами?
UPD:
Хотя какие ты проекты там делаешь, если не знаешь про мок, тесты и прочее? Далее консультация платная: 5000р/ч от будущего архитектора.
Тема закрыта
-
ЗаголовокОтветов ПросмотровПоследнее сообщение
-
Hoodwink 18 Jun 2024 в 01:04Сообщений: 2 18 Jun 2024 в 01:04
Сообщений:2
Просмотров:2
-
Сообщений:13
Просмотров:21
-
Сообщений:9
Просмотров:10
-
Сообщений:10
Просмотров:12
-
Сообщений:8
Просмотров:8