Относится ли отправка электронной почты к уровню представления или бизнес-уровня приложения?

Question

Я пытаюсь определить наилучшую область для размещения кода для отправки электронного письма в моем приложении Asp.net MVC.Прямо сейчас мое приложение настроено в двух проектах VS, отделяющих бизнес-уровень от уровня представления.Я пытаюсь настроить ситуацию, когда пользователь сбрасывает свой пароль, после того, как бизнес-логика меняет пароль, сервер отправит пользователю электронное письмо с его вновь сгенерированным паролем.отправить электронное письмо (включая данные о том, как оно выглядит) из бизнес-уровня (после того, как бизнес-уровень сбросит пароль) или из уровня представления (после того, как бизнес-уровень вернет успешный результат)?

Answer 1

Отправка электронных писем должна быть частью бизнес-уровня.

Я сталкивался с той же проблемой несколько недель назад ,,, я создаю веб-приложение с использованием asp.net mvc 3, которое состоит из трех проектов: Репозиторий(DAL), Услуги (BLL), Презентация (Web)

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

После некоторого поиска я нашел элегантное решение, которое было сделано KaziМанзур, где он создал подсистему электронной почты, которая использует Razor Views для отправки электронных писем в формате HTML / Text за пределы веб-проекта.

Использование Razor для шаблона электронной почты вне ASP.NET MVC

С тех пор я использую его подсистему, и она отлично справляется со своей работой.

Answer 2

Я частично согласен с BobTodd, потому что он предлагает вам абстрагироваться. Единственная часть, в которой я (частично) не согласен, касается того, что это происходит на бизнес-уровне.

Отправка электронной почты зависит от некоторой физической реализации - и вы не хотите связывать свой BL с внешними зависимостями, связанными с каким-либо почтовым провайдером.

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

На мой взгляд, есть два места, куда вы можете его поместить:

• В качестве общей службы, которую вы, возможно, захотите вызывать из любой точки мира, и поскольку она будет абстрагирована, вы сможете.
• Как / через «Внешний сервисный адаптер», который также абстрагируется, но доступен только из BL - который, в свою очередь, может предоставлять методы, которые может вызывать что угодно (например, пользовательский интерфейс) (если вы действительно этого хотите).

Примечание: оповещение о саморекламе! - взято из одной из моих статей: http://morphological.wordpress.com/2011/08/29/5-layer-architecture/

Answer 3

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

Создание интерфейса IEmailService с конкретной реализацией на вашем бизнес-уровне.

Внедрить его вваш контроллер.

Сделайте так, чтобы Контроллер создал и сгенерировал представление (электронное письмо из шаблона) с помощью Модели и вызвал реализацию IEmailService для фактической отправки.

Затем IEmailService легко поддается проверке при тестированииваш контроллер.

Answer 4

Отправка электронного письма не относится к уровню представления, однако «выделенный уровень представления» можно использовать для определения того, как выглядит сообщение (дизайн, тема и т. Д.).

Каждый «слой» можетна самом деле состоят из нескольких независимых сборок.Например, вы можете иметь более одного вида.

Answer 5

Отправка электронной почты - это функциональность бизнес-уровня. У вас будет класс mailhandler с методом, который будет отправлять сообщения и обрабатывать исключения.