Репозиторий в контроллере или модели? - PullRequest
Новая
       15

Репозиторий в контроллере или модели?

5 голосов
/ 16 мая 2009

Я работал над NerdDinner Tutorial, и большая часть его имеет смысл. В чем я не уверен, так это в том, почему хранилище используется непосредственно в контроллере, а не в объектах модели. Например, если мы хотим внедрить нашу собственную систему членства и в ней есть AccountController с методом Login, что будет лучшим решением для его подключения? например, 

Login(username,password){

    repo = AccountRepository

    account = repo.getLogin(username,password)

    //check account isn't locked

    //check account has been verified etc etc 

    //throw error or proceed to secure area

}

OR 

Login(username,password){

    repo = AccountRepository

    account = repo.getLogin(username,password)

    account.login() //business logic is handled in Account (Model)

}

OR 

Login(username,password){

    //no reference to repository

    account = Account

    //Account (Model) uses repository and handles business logic
    account.login(username,password) 

}

Я предлагаю, чтобы объект Account использовал прямое использование AccountRepository вместо того, чтобы AccountController получал информацию из AccountRepository и затем передавал ее объекту Account, например

Стиль NerdDinnner:

1 Запрос на вход приходит
2 AccountController использует AccountRepository для получения данных для входа в систему на основании запроса
3 AccountController использует объект Account и передает информацию с шага 1
4 Объект Account обрабатывает запрос и уведомляет AccountController

Что я предлагаю:

1 Запрос на вход в систему приходит
2 AccountController использует объект Account для обработки входа в систему по запросу
3 Объект Account использует AccountRepository для получения данных для входа в систему
4 Объект Account обрабатывает запрос и уведомляет AccountController

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

Account.Login(username,password){
    repo = AccountRepository

    account = repo.GetLogin(username,password)

    //check account isn't locked

    //check account has been verified etc etc

    //throw error or proceed to secure area
}

Надеюсь, это имеет смысл.

Ответы [ 5 ]

4 голосов
/ 16 мая 2009

«Модель» в mvc - это презентационная модель, а не модель предметной области. Вы можете рассматривать модель в MVC как объект передачи данных, используемый контроллером для подачи в механизм представления. Контроллер является единственным действующим лицом, связанным с уровнем обслуживания.

2 голосов
/ 05 октября 2009

По крайней мере, у вас должен быть другой уровень (не контроллер), который отвечает за взаимодействие с интерфейсом репозитория. Thil позволяет изменить de UI (контроллер является его частью) на другой. Таким образом, не имеет значения, является ли это командной строкой, рабочим столом или веб-интерфейсом.

В ASP.NET MVC я предпочитаю иметь модель (не модель моего домена, модель MVC) в отдельном проекте, а не в проекте MVC. Это позволяет совместно использовать DTO (модель MVC) с другими видами интерфейсов.

1 голос
/ 16 мая 2009

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

В Domain Driven Design есть место для бизнес-логики, которая не вписывается в класс Account: это называется сервисом. Вы можете прочитать больше об услугах DDD, например, здесь .

1 голос
/ 16 мая 2009

Хранилище является инфраструктурным концерном. То, что вы делаете, заставляет вашу модель полагаться на вашу инфраструктуру. Это своего рода отсталый способ сделать это. Это означает, что если вы хотите сделать что-то, например, использовать внедрение зависимостей, вам придется разрешить вашу модель из вашего контейнера, что не имеет для меня большого смысла.

Кроме того, дело не в том, чтобы держать все в одном месте. Вы должны стремиться разделить свои проблемы на логические единицы. Таким образом, вы можете легко определить, какая часть приложения делает что. Он также пригоден для тестирования.

0 голосов
/ 16 мая 2009

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

Я рассматриваю модель предметной области как группу игрушек или инструментов, которые вы подбираете, используете, манипулируете и т. Д. Игрушки на самом деле не заботятся о том, где они хранятся, и не должны. Вы должны иметь возможность положить игрушку на полку или в ящик для инструментов. Это не влияет на игрушку.

...