Реальный мир ASP.NET MVC Хранилища - PullRequest
Новая
       34

Реальный мир ASP.NET MVC Хранилища

8 голосов
/ 24 ноября 2010

В реальном мире контроллерам может понадобиться использовать данные из различных таблиц базы данных и других хранилищ данных.Например: 

[Authorize]
    public class MembersController : Controller
    {
        ICourseRepository repCourse;
        IUserCourseRepository repUserCourse;
        IMember member;
        public MembersController(ICourseRepository repCourse, IUserCourseRepository repUserCourse, IMember member)
        {
            this.repCourse = repCourse;
            this.repUserCourse = repUserCourse;
            this.member = member;
        }

Итак:

  1. Должен ли я использовать хранилище для каждой таблицы?

  2. Я думаю, этогде концепция агрегатов вступает в игру?Должен ли я иметь один репозиторий на агрегат?

  3. Должен ли я просто добавить столько репозиториев, сколько мне нужно, в конструктор контроллера?

  4. это признак того, что мой дизайн неправильный?

ПРИМЕЧАНИЕ:

Интерфейс IMember, по сути, представляет собой вспомогательный объект, который создает приятное лицо у поставщика Membership.Т.е. он размещает весь код в одном месте.Например: 

        Guid userId;
        public Guid UserId
        {
            get
            {
                if (userId == null)
                {
                    try
                    {
                        userId = (Guid) Membership.GetUser().ProviderUserKey;
                    }
                    catch { }
                }
                return userId;
            }
        }

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

РЕДАКТИРОВАТЬ:

Я использую Ninject для DI, и я довольно продан на всех DI, DDD и TDD.Ну вроде.Я тоже стараюсь быть прагматиком ...

Ответы [ 3 ]

6 голосов
/ 24 ноября 2010

1. Стоит ли использовать репозиторий для каждой таблицы?

Возможно, нет.Если у вас есть хранилище для каждой таблицы, вы, по сути, делаете Active Record.Лично я предпочитаю избегать называть эти классы «Репозитарием» из-за путаницы, которая может возникнуть между концепцией «Репозитория», разработанной Domain Driven Design, и «Репозиторием» для каждого класса таблиц, которая, кажется, стала широко использоваться в Linq2SQL, SubSonic.и т. д., а также многие учебные пособия по MVC.

2. Полагаю, здесь вступает в действие концепция агрегатов?Должен ли я иметь один репозиторий на агрегат?

Да и да.Если вы собираетесь идти по этому маршруту.

'3.'Должен ли я просто добавить столько репозиториев, сколько мне нужно, в конструктор контроллера?

Я не позволяю своим контроллерам напрямую касаться моих репозиториев.И я не позволяю своим представлениям напрямую касаться классов моего домена.

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

2 голосов
/ 24 ноября 2010

Хорошо @awrigley, вот мой совет:

В: Должен ли я использовать репозиторий для каждой таблицы?

A: Нет, как вы упомянули в вопросе 2. используйте репозиторий для агрегата и выполняйте операции только с корнем агрегата.

В: Мне просто добавить столько репозиториев, сколько мне нужно, в конструктор Контроллера?

A: Полагаю, вы используете IoC и конструктор-инъекцию, в этом случае убедитесь, что вы передаете только реальные зависимости. этот пост может помочь вам определиться с этой темой.

(pst! Этот пустой улов нехорошо !!);)

Ура!

0 голосов
/ 24 ноября 2010

Все зависит от того, каким будет «Доменно-управляемый дизайн». Вы знаете, что такое Совокупный Корень? Большую часть времени будет достаточно типизированного репозитория, который может выполнять все ваши основные CRUD. Только когда вы начинаете иметь толстые модели с контекстом и границами, это начинает иметь значение.

...