В настоящее время я пишу приложение ASP.Net из пользовательского интерфейса. Я реализую архитектуру MVP, потому что я устал от Winforms и хотел чего-то, что было лучше разделить интересы.
Таким образом, в MVP Presenter обрабатывает события, вызываемые представлением. Вот некоторый код, который я использовал для создания пользователей:
public class CreateMemberPresenter
{
private ICreateMemberView view;
private IMemberTasks tasks;
public CreateMemberPresenter(ICreateMemberView view)
: this(view, new StubMemberTasks())
{
}
public CreateMemberPresenter(ICreateMemberView view, IMemberTasks tasks)
{
this.view = view;
this.tasks = tasks;
HookupEventHandlersTo(view);
}
private void HookupEventHandlersTo(ICreateMemberView view)
{
view.CreateMember += delegate { CreateMember(); };
}
private void CreateMember()
{
if (!view.IsValid)
return;
try
{
int newUserId;
tasks.CreateMember(view.NewMember, out newUserId);
view.NewUserCode = newUserId;
view.Notify(new NotificationDTO() { Type = NotificationType.Success });
}
catch(Exception e)
{
this.LogA().Message(string.Format("Error Creating User: {0}", e.Message));
view.Notify(new NotificationDTO() { Type = NotificationType.Failure, Message = "There was an error creating a new member" });
}
}
}
Моя основная проверка формы выполнена с использованием встроенных .Net Validation Controls, но теперь мне нужно убедиться, что данные в достаточной степени удовлетворяют критериям для уровня обслуживания.
Допустим, могут отображаться следующие сообщения сервисного уровня:
- Учетная запись электронной почты уже существует (сбой)
- Введенный пользователь не существует (ошибка)
- Длина пароля превышает допустимую длину хранилища данных (ошибка)
- Участник создан успешно (успех)
Скажем также, что на уровне сервиса будет больше правил, которые пользовательский интерфейс не может предвидеть.
В настоящее время у меня есть сервисный слой, который выдает исключение, если все идет не так, как планировалось. Это достаточная стратегия? Парни, этот код пахнет? Если бы я написал такой сервисный слой, вы были бы раздражены необходимостью писать докладчики, которые используют его таким образом? Коды возврата кажутся слишком старыми, а бул просто недостаточно информативен.
Редактировать не OP: объединение последующих комментариев, которые были опубликованы как ответы OP
Cheekysoft, мне нравится концепция исключения ServiceLayer. У меня уже есть глобальный модуль исключений для исключений, которые я не ожидаю. Считаете ли вы делать все эти пользовательские исключения утомительными? Я думал, что ловить базовый класс Exception было немного вонючим, но я точно не знал, как продвигаться дальше.
tgmdbm, мне нравится умное использование там лямбда-выражения!
Спасибо Cheekysoft за продолжение. Поэтому я предполагаю, что это будет стратегией, если вы не против того, чтобы пользователю отображалась отдельная страница (я в первую очередь веб-разработчик), если исключение не обрабатывается.
Однако, если я хочу вернуть сообщение об ошибке в том же виде, в котором пользователь отправил данные, вызвавшие ошибку, мне бы пришлось перехватывать исключение в Presenter?
Вот как выглядит CreateUserView, когда Presenter обрабатывает исключение ServiceLayerException:
Для такого рода ошибок хорошо сообщить о том же виде.
В любом случае, я думаю, что мы сейчас выходим за рамки моего первоначального вопроса. Я поэкспериментирую с тем, что вы написали, и если мне понадобится дополнительная информация, я опубликую новый вопрос.