Pull to refresh

Comments 17

Вот опять запихали репозиторий. Вот зачем? Ну когда возникает необходимость изменить ORM? Даже если такое потребуется, то все равно придется менять репозиторий, к гадалке не ходи. А так над EF, который и так реализует UoW+Repository ещё один «обвес». Опять же, все объяснения репозитория работают только с этими «лабораторными» приложениями (ToDo, People и т.п.). Когда появляются множественные связи, все рушиться, как карточный домик

Обязательно впихнуть репозиторий, это уже клише :)

В данном примере такая реализация соответствует паттерну «Хранилище». В реальных проектах паттерны реализуются с некоторыми изменениями, свойственные предметной области, но суть такого подхода — исключить связанность компонентов, как раз и подразумевает облегчение работы со «множественными связями».
Эм, замечание от КЭП — там можно выбрать шаблон с Angular. Там выбрать тип аутентификации Individual User Accounts и все. Создастся приложение с авторизацией и Агуляр гуем где можно прям брать и уже забыв про этот весь бойлерплейт писать код нашей бизнес логики. Там сразу будет и авторизация, и регистрация пользователей и все остальное. Буквально пару галочек и пару кликов мышкой.
Отлично) Шаблон с Angular замечательная вещь и дает ощущение неразрывности использования Angular с платформой .NET, что не есть хорошо при описании технологии. На мой взгляд, при разборе работы некоторой технологии все-таки лучше рассматривать ее обособленно))

Ну почему не в VS Code, чтобы и в Linux можно было бы попробовать?!

Возможно следует описать построение проекта и в VS Code)))
Статья была бы интересней, если бы дополнили рассказ описание логгирования (например, те же запросы к БД), также можно было бы раскрыть нюанс использования контекста из контейнера как Scoped и Transient сервис, описать как конфигурировать маппинг таблиц, использование в миграциях Raw SQL, Automapper. На мой взгляд это немаловажные вопросы для тех, кто начинает работать с данными типом проектов. Возможно неплохо бы добавить информацию об использовании 3rd-party IoC контейнеров. Это бы выделило статью из ряда таких же обычных руководств, коих уже написано десятки.
services.AddDbContext регистрирует контекст, как scoped. Transient сервис делать смысла особенного нет, потому что он зависит только от EFTodoDBContext, который scoped.
В Web-окружении вообще всё имеет смысл делать scoped.
Разница в lifetime у DbContext только в том, что при долгом времени жизни DbContext насобирает в себя очень много tracked-объектов и начнёт тормозить и жрать память.
Спасибо за ответ. Было бы неплохо это отметить в статье для тех разработчиков, которые будут строить проект по данному руководству. ИМХО, это добавит понимания.
Спасибо за замечания!) В скором времени дополню статью некоторыми из ваших идей. Что касается маппинга таблиц, то в плане было описание этой возможности в последней части курса
Автор упомянул ASP.NET Core MVC: WebApi.
Имхо: думаю, что автору необходимо разобраться в стэке ASP.NET Core (https://docs.microsoft.com/ru-ru/aspnet/overview), прежде чем писать статьи именно по данной тематике. Такой заголовок может повествовать о некоем существующем приложении ASP.NET Core MVC и отдельном приложении ASP.NET Core WebAPi + Angular + EF.
Да, действительно не совсем корректное упоминание… исправил)
А зачем ITodoRepository регистрировать как Transient?
Очередной бесполезный хелуворд:
Метод Update так нельзя писать, потому что не учитывает коллизии.
Просто попробуйте реализовать правильное управление ACID деревом объектов.
Ну там invoice -> chart -> product
И увидите, что ваш подход окажется бесполезным.
Даже если вы станете делать eventual consistency, то вам ещё много чего прийдётся написать.
В репозитории смысл тоже нет: вам скорее захочется использовать RawSQL и Dapper, чем менять провайдер.

Хелуворд имеет смысл писать только если вы пишите, как правильно что-то сделать от начала до конца. Ну, например, как нормально добавить healthcheck в приложение, или управлять транзакциями. Иначе ненужно.
ORM позволяет абстрагироваться от БД. Паттерн «Хранилище» добавляет абстрагирование от ORM.
Мне вот интересен реальный пример, когда проект необходимо переводить на другую ORM.
Может скажете что на этапе проектирования не была учтена производительность ORM? Но тогда Вы просто не читали ТЗ.
Переход на другую ORM не праздный вопрос. Мне действительно интересна ситуация когда возникает необходимость перехода.
За все долгое время моего программирования пару раз сталкивался с ситуацией когда ORM просаживала производительность. Но каждый раз это были настолько нагруженные места, что и реляционная БД не справлялась с пиками, так что вопрос решался или построением очереди на запись в памяти или сбросом на диск с последующим переносом в БД. Объясните мне необходимость абстракции от ORM кроме желания прикрутить еще один паттерн.
Sign up to leave a comment.

Articles