@@PlatinumTechTalks стоит C# for Visual Studio Code (powered by OmniSharp). Но, к сожалению, реализовать интерфейс по клику так и не выходит( Лампочка даже не появляется. Кстати, а данный проект не удобнее будет писать в Visual Studio? Там рефакторинг и InteliSence работает получше на мой взгляд для C#.
Странно, что с расширением не подсказывает.. может криво встало или с настройками чего… да, можно проект писать и в Visual Studio, там много чего из коробки работает, можно и в Rider, он тоже очень прикольный нынче и ничем не уступает VS (но тут кому что больше нравится). В рамках этого курса была идея использовать VS Code, чтобы продемонстрировать, что разработку можно вести в легковесном редакторе кода. А так это не обязательно, можно использовать что угодно, хоть блокнот и консоль :)
действительно, EF Core уже реализует паттерн Репозиторий и писать ещё один слой необязательно. Однако многие всё равно его реализуют и в этом случае видео может быть полезным. Из этих соображений и добавили репозиторий. Но если бы причина "другие так делают" была единственной, то она была бы странной причиной. Почему другие так делают? Есть причины, почему реализация репозитория поверх EF Core может быть полезной: 1. Изолировать код для работы с БД. Таким образом мы точно знаем, где лежит весь наш код для работы с базой. 2. Агрегация: у нас есть сущность Отель. Как единая точка, вокруг которой всё вертится. И, например, у каждого отеля есть отзывы на него. Отзывы имеют смысл, только если они связаны с отелем. Если мы используем DDD подход, то он предполагает, что отзывы должны меняться только через отель. В рамках репозитория легко можно это сделать. 3. Можно легко замокать отдельно взятый репозиторий и протестировать его. Хотя это не сильно большой плюс. Можно найти и другие плюсы..
@@PlatinumTechTalks обычно холивары идут между контекстом и репозиторием. Типа DbContext и так предполагает работу с базой и т.п. Но у репозитория есть интерфейс, а у контекста - нет. Это мешает в тестировании порой
@@govorun5909 что это за желание )) При сложной логике с различными валидациями и кучей сервисов во всём этом будет трубно разобраться. Потому и минимал апи, видимо. Так что усложнять не надо ))
@@kslmPtr Добавляй контроллеры более нормальную архитектуру проекта и разберешься во всем насчет кучи сервисов у тебя будет выбор монолит или микро сервис
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
я даже не понял что такое репозиторий, отличный туториал))
Надо же для репозитория отдельный файл )) прогресс
А зачем в репозитории делать Dispose контекста БД ? вроде у контекста БД lifetime scoped и контейнер сам его удалит в конце запроса
Спссибо
не совсем понял: с данным репозиторием, если запись не найдена в базе, то клиент об этом не узнает и всё равно получит Results.NoContent()?
Подскажите кто-нибудь, как сделать реализацию интерфейса как в видео? У меня нет такого действия. Приходится вручную методы описывать.
Что вы имеете в виду? Чтоб автоматически методы добавились?
@@PlatinumTechTalks да, при клике на иконку рефакторинга, чтобы был пункт "implement interface..."
А расширение C# в VS Code стоит? (прежнее название OmniSharp)
@@PlatinumTechTalks стоит C# for Visual Studio Code (powered by OmniSharp). Но, к сожалению, реализовать интерфейс по клику так и не выходит( Лампочка даже не появляется. Кстати, а данный проект не удобнее будет писать в Visual Studio? Там рефакторинг и InteliSence работает получше на мой взгляд для C#.
Странно, что с расширением не подсказывает.. может криво встало или с настройками чего… да, можно проект писать и в Visual Studio, там много чего из коробки работает, можно и в Rider, он тоже очень прикольный нынче и ничем не уступает VS (но тут кому что больше нравится). В рамках этого курса была идея использовать VS Code, чтобы продемонстрировать, что разработку можно вести в легковесном редакторе кода. А так это не обязательно, можно использовать что угодно, хоть блокнот и консоль :)
Почему редактор не Microsoft VS?
просто так, можно и в VS
А зачем репозиторий, если еф кор и так репозиторий уже?
действительно, EF Core уже реализует паттерн Репозиторий и писать ещё один слой необязательно. Однако многие всё равно его реализуют и в этом случае видео может быть полезным. Из этих соображений и добавили репозиторий. Но если бы причина "другие так делают" была единственной, то она была бы странной причиной. Почему другие так делают? Есть причины, почему реализация репозитория поверх EF Core может быть полезной:
1. Изолировать код для работы с БД. Таким образом мы точно знаем, где лежит весь наш код для работы с базой.
2. Агрегация: у нас есть сущность Отель. Как единая точка, вокруг которой всё вертится. И, например, у каждого отеля есть отзывы на него. Отзывы имеют смысл, только если они связаны с отелем. Если мы используем DDD подход, то он предполагает, что отзывы должны меняться только через отель. В рамках репозитория легко можно это сделать.
3. Можно легко замокать отдельно взятый репозиторий и протестировать его. Хотя это не сильно большой плюс.
Можно найти и другие плюсы..
@@PlatinumTechTalks обычно холивары идут между контекстом и репозиторием. Типа DbContext и так предполагает работу с базой и т.п. Но у репозитория есть интерфейс, а у контекста - нет. Это мешает в тестировании порой
По факту этот api просто сахар без скобочек.
Наверное это может использоваться в самых простых апи без сложной логики
По желанию усложнить можно
@@govorun5909 что это за желание ))
При сложной логике с различными валидациями и кучей сервисов во всём этом будет трубно разобраться. Потому и минимал апи, видимо.
Так что усложнять не надо ))
@@kslmPtr Добавляй контроллеры более нормальную архитектуру проекта и разберешься во всем насчет кучи сервисов у тебя будет выбор монолит или микро сервис