ASP.NET MVC: сервисный уровень, уровень данных и контроллеры - как они взаимодействуют?

Question

Хорошо, я пытаюсь переписать огромную часть кода в этом приложении ASP.NET MVC, которое было плохо разработано. Я много читал о многих концепциях и шаблонах, некоторые из них были немного более продвинутыми, но я был озадачен очень простым персоналом.

Так какой должна быть общая структура приложения MVC?

У меня есть что-то, что оборачивает доступ к данным - давайте назовем это «слоем данных». Это может быть реализация шаблона Repository или просто некоторый контекстный класс Entity Framework или ...

Тогда у меня будет бизнес-логика обертывания уровня сервисов.

Какой должен быть сценарий обслуживания http-запроса? Контроллер создается для запроса -> выполняется действие над ним. А потом ? Я создаю экземпляр «слоя данных» и передаю его на уровень обслуживания методов, фиксирует изменения и отображает результаты?

Таким образом, каждый метод во всех сервисах (принадлежащих к сервисному уровню) должен принимать некоторый класс «уровня данных» в качестве параметра, чтобы он мог общаться с «уровнем данных»? Или я передаю ссылку «слой данных» на сервисы в конструкторе? В таком случае я должен создать новый сервис для каждого запроса, верно?

Я читал об использовании ключевого слова using в контроллере для передачи ссылки «уровень данных» на сервисы. Другой подход использует внедрение зависимости. Я не очень понимаю разницу ... А почему бы просто не создать его в конструкторе контроллеров и не упростить его?

Answer 1

Фактический ответ на вашу проблему

Без обид @drasto, но, похоже, вы не тот человек, который занимается рефакторингом плохо разработанного существующего приложения, поскольку вы сами боретесь с довольно простыми вещами.По крайней мере, вы не должны делать это в приложении, предназначенном для развертывания.

Справка

Было бы лучше поговорить с аналитиком по разработке, который уже работает EF / Asp.net MVC/ repository / service pattern и знает, как они общаются друг с другом и как их следует реализовывать.Хорошо, что вы можете многому научиться таким образом и научиться так, как нужно.Зачем вам заново изобретать все колесо?

Вы также можете узнать из примеров, представленных на http://www.asp.net/mvc, которые покажут вам, как нужно делать шаг за шагом с хорошей архитектурой приложения.

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

Я создал упрощенный пример архитектуры приложения Asp.net MVC в .из моих ответов , который представляет эти понятия на очень поверхностном уровне.но может быть полезным.

Answer 2

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

MVC, EF - экземпляр Singleton DataContext для каждого веб-запроса в Unity

В моем примере контроллеры «вводят» необходимые зависимости, в данном случае необходимые репозитории,После обработки запроса контроллеры располагаются вместе с хранилищами.

Кроме того, я предлагаю вам сохранить ваш слой данных в отдельной сборке (проекте).