Контроллер. Должен ли он иметь дело с уровнем обслуживания или хранилищем напрямую?

Question

Существует так много противоречивых статей в Интернете. Каково ваше личное мнение по этому вопросу (для приложения предприятия) .....

В моей C#/приложение MVC Я насторить архитектуры, как предложено здесь, минус инъекции зависимостей и automapper: https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/

В общем , когда речь идет о контроллере MVC, следует ли использовать только служебный уровень напрямую? Или это все еще хорошая практика для непосредственного обращения с хранилищем? Что поможет вам решить?

Также, если класс UnitOfWork будет создан на уровне контроллеров, а затем передан в Service/repo?

Благодаря

Answer 1

Ну, блок работы, я думаю, что это бесполезно, как DbContext может быть единица работы, Кроме того, вы можете использовать DbContext в качестве хранилища. Нужен ли мне репозиторий и сервисные уровни, я думаю, что только один из них достаточно зависит от сложности проекта, а сервис - это слой, когда у вас более сложный проект. Вы должны подумать о том, как вы могли бы повторно использовать свой код, и сохранить его просто, но не создавать много слоев, с кодом, не используемым повторно

Answer 2

Лично я считаю, что уровень обслуживания имеет первостепенное значение для любого от среднего до большого API, и что на этом уровне вы должны иметь дело с единицей работы (если вы решите использовать ее). Причина, по которой вам не следует разбирать репозиторий на уровне контроллера, - это гибкость вашей архитектуры и предотвращение плотного связывания вашего сервиса с вашим протоколом или вашей реализацией.

В качестве примера предположим, что сегодня вы подвергаете свое обслуживание службе REST. Завтра вы можете использовать другой протокол (возможно, SOAP или что-то еще). Используя уровень обслуживания, уровень протокола (контроллеры) становится выбрасывающим и может быть легко заменен.

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

В конце дня, однако, вышесказанное представляет собой просто мнения и возможные сценарии, которые могут или не могут применяться к вашему проекту. Выбор, который вы делаете, должен зависеть от характера вашего конкретного проекта (размер, сложность, вероятность изменения, ...).

Answer 3

В общих хранилищах содержится минимально возможный код. Я имею в виду, что они содержат только код для вставки, обновления и удаления элементов из внутренней реализации. Они существуют, потому что вы хотите переключить реализацию DAL. Если вы хотите использовать репозитории непосредственно в контроллере, тогда вы должны написать логику домена в контроллере, и это не очень хорошая практика. Контроллеры должны быть небольшими и отправлять только запросы на логику или услуги домена.

Так что в моей идее лучше использовать службы в контроллере.

Если вы создаете экземпляр UOWs в своих сервисах, вы закончите работу с новой единицей работы в каждом сервисе. создание единицы работ может быть дорогостоящим. Поэтому, если вам нужно два или три сервиса в одном контроллере, у вас будет два, три единицы работы в одном контроллере.

Так что, опять же, в моей идее лучше вводить единицу работы в службы.

Я говорю снова Репозиторий и блок работы полезны, если вы хотите переключать реализации DAL (пример может быть проверен кодом с данными памяти).

Answer 4

Ну, это действительно зависит от вашего приложения.

Позвольте мне привести пример архитектуры, которую я бы использовал.

1. проект сайта MVC
2. Бизнес-слой проект
3. проект слоя Persisten
4. Общего слой проект
5. Тесты проект

1 Контроллеры, МНЕНИЕ, ViewModels. Здесь вы переходите от моделей BL в ViewModels.

2 Ваш бизнес-уровень. Это может быть опущено, если ваш BL находится в базе данных, и вас интересует только отображение данных. Однако, если вы начинаете новый проект, здесь вы должны быть BL. Все ваши бизнес-решения, валидации и так далее. Также, если модель BL не соответствует вашей базе данных, здесь вы преобразуете данные своей базы данных в модели BL

3 Этот уровень предназначен только для разговора с базой данных. С минимальной логикой.

4 Обычный объект. Как методы расширения. Или другие объекты, используемые приложением. Это должно быть как можно более легким!

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

Примечания:

1 - Здесь вы также должны думать о ваш взгляд и как вы будете разделять проблемы между контроллером, ViewModel и вашим HTML, javascript и т. д. Это действительно зависит от сложности ваших взглядов.

Я рекомендую вам использовать инъекцию зависимости, это отличный инструмент, особенно если вы строите корпоративное приложение.