现在我有一个ASP MVC web应用程序,还有一个models项目,一个Service项目,一个Utilities项目,以及几个数据存储项目,它们充当一个或多个域模型的存储库。我对每一层的分离都很满意,但我被困在从服务层返回到web应用程序的问题上。
例如,当用户尝试注册时,控制器接收到RegisterViewModel。单个项目(电子邮件、密码等)被发送到服务层,服务层使用guid、状态、创建日期等构造成员域对象,然后将其发送到存储库进行存储,最后将成员对象返回给web应用程序重定向到/ Member /{guid}。
但是,如果电子邮件已经存在,服务层应该如何通知web应用程序?在更复杂的情况下,我可能必须检查多个域对象和业务规则的存在/有效性,因此必须一次性返回多个错误。此外,我不希望异常冒泡到web层,因此服务层捕获所有异常,但需要通知web层一些方法。
即使我找到一种方法来返回所有这些内容,web层也会负担起处理所有这些内容并为用户提供各种反馈的负担。控制器代码会很笨重,而且会产生错误。演示文稿的服务结果是否有最佳实践?我是否应该去掉单独的服务层,并将代码放在控制器中?欢迎任何想法。
发布于 2012-01-25 15:02:55
为此,我编写了operation model库,它允许您编写如下代码:
public OperationResult Register(RegisterInput input) {
var errors = new ErrorBuilder();
if (errors.NotValid(input) // Invoke DataAnnotations validation
|| errors.Not(this.repo.FindUserByEmail(input.Email) == null, "Email '{0}' already exists.", () => input.Email))
return errors;
// Do stuff
return HttpStatusCode.OK;
}在控制器中的...and错误消息被复制到ModelState:
[HttpPost]
public ActionResult Register(RegisterInput input) {
var result = this.service.Register(input);
if (result.IsError)
return View().WithErrors(result);
// Do stuff
}查看使用此模式编写的MvcAccount项目的源代码。
发布于 2012-01-25 10:40:25
首先,您需要决定是否要为分布式目的编写服务层。
如果您不打算将服务层分发到不同的进程/机器,
中使用它
在请求的整个生命周期内,HttpContext.Items都是可用的,您可以一直使用它直到视图。
如果您使用DI框架,则可以通过使用每个生命周期对象的请求来实现相同的功能。
如果你想发布对象,从你的服务层抛出异常没什么错。
https://stackoverflow.com/questions/8997148
复制相似问题