ASP.NET Контроллер MVC с несколькими репозиториями?

#c# #asp.net #asp.net-mvc #asp.net-mvc-3

#c# #asp.net #asp.net-mvc #asp.net-mvc-3

Вопрос:

У меня есть представление, в котором я ищу объект в своей базе данных (например, Книги)..

Мой контроллер для этого представления зависит от BooksRepository, который реализует метод поиска.

Все работает нормально. У меня также есть возможность выполнить расширенный поиск, который представляет увеличенную форму в модальном всплывающем окне. Эта форма содержит множество полей, включая выпадающее окно для выбора «Автора» для поиска.

Я хотел бы передать список authors в моей viewmodel, поэтому в моем контроллере управления я создаю экземпляр моей модели представления, мне нужно вызвать метод репозитория, чтобы вернуть список authors

Я думаю, что этот метод GetAuthors () должен находиться в AuthorRepository…

Плохая практика вводить несколько репозиториев в контроллер? или у меня должен быть контроллер Author, который вводится в репозиторий author … и вызывать метод в контроллере Author из моего контроллера BookSearch?

Ответ №1:

Я думаю, что совершенно нормально ссылаться на несколько репозиториев в контроллере. Задача контроллера — обернуть данные в модель и передать их в представление, независимо от того, как он получает данные. Выполнение вызовов между контроллерами может привести к беспорядку.

Комментарии:

1. да, если подумать, идея кросс-контроллера не показалась мне такой уж замечательной.

Ответ №2:

Я не думаю, что это плохая идея внедрить два необходимых вам репозитория в контроллер. На самом деле это звучит как хорошая практика.

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

Но в этом случае, я думаю, вы делаете это правильно.

Прочитайте эту книгу:http://www.infoq.com/minibooks/domain-driven-design-quickly

Ответ №3:

Лично я бы подумал, что книги и авторы — это довольно специфические сущности…. если вы не планируете, чтобы автор также писал песню, и вы хотите иметь хранилище музыки и хранилище книг, я бы, вероятно, сохранил авторов и книги в одном хранилище, поскольку они, скорее всего, понадобятся вам одновременно.

Даже тогда у вас может быть хранилище музыки и хранилище книг, которые извлекаются из одной и той же таблицы author. В этом нет ничего плохого. И нет, наличие более одного репозитория в контроллере не является «запретом», но если вы не используете внедрение зависимостей, это может начать усложняться по мере добавления новых репозиториев.

Комментарии:

1. о, и на самом деле это не так, Books и Authors это было только для примера, в моем реальном случае они должны быть в отдельном репозитории

2. Однако это нарушило бы правило root aggregate DDD. Авторы!= Книги. Эрику Эвансу бы это не понравилось.

3. Ознакомьтесь с этой книгой: infoq.com/minibooks/domain-driven-design-quickly Это чтение по вечерам, и оно охватывает большинство основ.

Ответ №4:

У меня есть несколько контроллеров, которые ссылаются более чем на один репозиторий. Просто будьте осторожны, если каждое из ваших репозиториев создает свой собственный контекст данных (или EF ObjectContext). Говоря в терминах Entity Framework, если вы начнете перемещаться по ссылкам на сущности с двумя открытыми контекстами, у вас возникнут проблемы.

В остальном у меня все работает нормально.

Ответ №5:

С точки зрения архитектора.

Если вы чувствуете, что ваши контроллеры mvc выходят из-под контроля из-за зависимостей, тогда пришло время подумать о двух вещах.

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

  2. посмотрите на некоторые другие шаблоны проектирования, которые могут помочь решить эту проблему, прежде чем она превратится в проблему (стратегия с DI, возможно, посетителем)

Кроме того, я уверен, что в этой ситуации модульные тесты доставляют больше хлопот, если вы не можете протестировать модуль простым способом, его следует пометить для улучшения

Удачи,