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

Question

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

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

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

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

1. UserName
2. Идентификатор_пользователя
3. Email
4. TemplatePath ("~/Templates")
5. Электронная почта Тема

В пределах служебного слоя у меня есть m y static method SendUserEmail(), который использует класс Template - который берет путь, загружает его как строку и имеет метод AddToken().

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

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

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

Создавать ли методы, специфичные для электронной почты, которые необходимо отправить? то есть. 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 будет знать что взять с этого токена.

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