Каков лучший шаблон для реализации этих функций в ASP.NET MVC3?

Question

У нас есть несколько функций, которые следуют очень похожим образцам:

1. Пользователь отправляет адрес электронной почты
2. Пользователь получает письмо с секретным кодом
3. Пользователь возвращает секретный код ввыполнить безопасное действие

Например, наша функция регистрации / регистрации следует этому шаблону.Пользователь отправляет адрес электронной почты, получает электронную почту, а затем использует секретный код для создания пароля и учетной записи пользователя.Другой пример - сброс пароля.Пользователь отправляет адрес электронной почты, получает электронную почту, затем использует секретный код для изменения пароля и доступа к учетной записи пользователя.

Pattern # 1

У нас может быть 1 контроллер, который управляет каждой функциейиндивидуально.Так, например, SignUpController, который обрабатывает все связанные действия (отправка электронной почты, выкуп кода и создание пароля).Тогда у нас может быть PasswordResetController, который также обрабатывает отправку электронной почты, выкуп кода и изменение пароля.

Pattern # 2

Альтернативой может бытьдействия распределяются по контроллерам.В этом шаблоне у нас будет SendEmailController, который будет отправлять электронные письма для обеих функций, CodeRedemptionController, который будет обрабатывать погашения кода для обеих функций, и PasswordController, который будет обрабатывать операции с паролями для обеих функций.

Какой подход лучше и почему?Нашей основной целью является достижение высокой простоты кода, ясности / открытости и СУХОСТИ.Я вижу преимущества и недостатки обеих моделей.

Преимущества Pattern # 1

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

Недостатки Pattern # 1

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

Преимущества и недостатки Pattern # 2 будут противоположны.Мы могли бы упростить зависимости для контроллеров, но функции могли бы быть распределены по нескольким контроллерам, размывая ясность того, какие функции пытается достичь приложение в целом.

Answer 1

Я бы использовал один контроллер учетной записи для управления всеми соответствующими функциями управления пользователями.Этот контроллер будет точкой доступа пользователя для обработки этих типов функций.

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

/models/EmailManager.cs
/models/PasswordManager.cs
/models/SecretCodeGenerator.cs
/models/AccountManager.cs

Это позволит вам иметь сводный синтаксис URL.Это не даст вам иметь много контроллеров только с одним методом.И это избавит вас от большого количества логики типа модели в контроллерах.

www.mydomain.com/account/signup/
www.mydomain.com/account/confirm/
www.mydomain.com/account/resetpassword/

(с пользовательскими маршрутами вы можете даже удалить / account / part, если хотите)

Однако у меня может возникнуть соблазн создать собственный контроллер для обработки секретных кодов.(redeemController) Таким образом, вы можете контролировать доступ к большей части accountController только для авторизованных / существующих пользователей, тогда как контроллер выкупа (в зависимости от вашего дизайна) может быть открыт для анонимного доступа для новых клиентов.

Наконец, большинствологики в модельных классах делает их гораздо более дружественными к тестам.