我目前正在从 UI 编写一个 ASP.Net 应用程序。我正在实现一个 MVP 架构，因为我厌倦了 Winforms，并且想要更好地分离关注点的东西。
因此，对于 MVP，Presenter 处理 View 引发的事件。这是我用来处理用户创建的一些代码：
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 验证控件完成了主要表单验证，但现在我需要验证数据是否充分满足服务层的标准。
假设可以显示以下服务层消息：
- 电子邮件帐户已存在（失败）
- 输入的引用用户不存在（失败）
- 密码长度超过数据存储允许的长度（失败）
- 成员创建成功（成功）
我们还假设 UI 无法预期的服务层中将有更多规则。
目前，如果事情没有按计划进行，我会让服务层抛出异常。这是一个足够的策略吗？这段代码对你们来说有味道吗？如果我写了一个这样的服务层，你会不会因为必须编写以这种方式使用它的 Presenter 而感到恼火？返回代码似乎太老套了，布尔值不够丰富。
不由 OP 编辑：合并由 OP 作为答案发布的后续评论
Cheekysoft，我喜欢 ServiceLayerException 的概念。对于我没有预料到的异常，我已经有了一个全局异常模块。您是否觉得让所有这些自定义异常变得乏味？我在想捕获基本异常类有点臭，但不确定从那里进展如何。
tgmdbm，我喜欢那里巧妙地使用 lambda 表达式！
感谢 Cheekysoft 的跟进。因此，如果您不介意在未处理异常的情况下将用户显示为单独的页面（我主要是 Web 开发人员），那么我猜这将是策略。
但是，如果我想在用户提交导致错误的数据的同一视图中返回错误消息，那么我必须在 Presenter 中捕获异常？
以下是 Presenter 处理 ServiceLayerException 时 CreateUserView 的样子：
对于这种错误，最好将其报告给同一个视图。
无论如何，我认为我们现在超出了我原来的问题的范围。我会玩弄你发布的内容，如果我需要更多详细信息，我会发布一个新问题。