Ищете хорошую технику для хранения почтовых шаблонов

Question

Я создаю сайт, на котором мы умеренно используем шаблоны электронной почты. Например, шаблоны HTML, в которые мы передаем токены, такие как {UserName}, {Email}, {NameFirst} и т. Д.

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

Я создал шаблоны HTML в папке с именем /Templates/.

Я вызываю статический метод на своем сервисном уровне, который принимает следующие аргументы:

1. UserName
2. Идентификатор_пользователь
3. E-mail
4. TemplatePath ("~ / Templates")
5. Тема сообщения

На уровне сервиса у меня есть статический метод SendUserEmail (), который использует класс Template - который берет путь, загружает его как строку и имеет метод AddToken ().

В моем статическом SendUserEmail () я строю список токенов из сигнатуры метода и отправляю электронное письмо.

Это делает довольно длительный вызов метода при моем фактическом использовании, тем более что я вызываю из web.config «TemplatePath» и «Email Subject». Я мог бы создать утилиту с более коротким вызовом метода, чем ConfigurationManager.AppSettings, но меня больше беспокоит то, что я обычно не вижу подписи методов так долго, и мне кажется, что это происходит из-за того, что я что-то делаю неправильно.

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

Я создаю методы, специфичные для письма, которое нужно отправить? то есть. SendNewUserRegistration (), SendMarketingMaterial (), и у каждого своя сигнатура для параметров?

Я использую членство в ASP.NET, которое, вероятно, содержит все поля, которые мне когда-либо понадобятся. Существует три основных объекта: aspnet_User, aspnet_Mebership и aspnet_profile. Если бы все это содержалось в одном объекте, я бы просто передал это. Есть ли проблемы с производительностью при передаче всех 3, чтобы получить все нужные мне поля? Это по сравнению с передачей aspnet_User.UserID, aspnet_User.Email и т. Д.?

Я мог видеть переход в словарь с записями токена, но мне просто интересно, не слишком ли много, чтобы спросить страницу вызова?

Есть ли способ вставить их в собственный файл конфигурации с именем Templates.config, который имеет такие теги, как -

<Templates>
<EmailTemplate Name="New User Registration">
<Tokens>
<UserName>
<UserID>
<Email>
</Tokens>
<Message Subject="Hi welcome...">
   Hi {UserName}...
</Message>
</EmailTemplate>
</Templates>

Думаю, главная причина, по которой я спрашиваю, состоит в том, что мне трудно определить, где должна лежать ответственность, а именно, какой шаблон использовать и как передать параметры. Это нормально, если вызывающая страница должна создать словарь TokenName, TokenValue? Или метод должен принимать каждый в качестве определенного параметра? Это выглядит неуместно в файле web.config, потому что у меня есть 2 записи для и, и кажется, что он должен выглядеть более вложенным.

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

Answer 1

Прежде всего я хотел бы предложить вам использовать NVelocity в качестве движка шаблонов. Что касается основной проблемы, я думаю, что вы можете создать абстрактный класс MailMessage и получить каждый для каждого необходимого сообщения (с уникальным шаблоном). Таким образом, вы будете использовать это следующим образом:

MailMessage message = new UserRegistrationMessage(tokens);
//some code that sends this message

Поступая таким образом, вы заставляете каждый конкретный класс XXXMessage отвечать за хранение шаблона и заполнение его данными токенами . Как бороться с токенами? Самый простой способ - создать словарь перед передачей его в сообщение, чтобы каждый конкретный класс сообщения знал, как обращаться с передаваемым словарем и какие токены он должен содержать, но вам также необходимо помнить, какие токены он должен содержать. Другой способ (мне это нравится больше) - создать общий абстрактный тип TokenSet и производный для каждого необходимого уникального набора токенов. Например, вы можете создать UserMessageTokenSet: TokenSet и несколько свойств в нем:

UserNameToken
SomeUserProfileDataToken

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

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