在基于消息的设计中放置业务逻辑的最佳实践是什么?
我使用servicestack来构建我的api .
The wiki显示了将 RequiredRole
属性放在消息上而不是处理它的服务的示例 .
从某种意义上说, [RequiredRole]
/ [Authenticate]
是附加到消息的业务逻辑/安全性 .
具体例子
比如说我会添加 DeleteAddress
消息:
public class DeleteAddress : IReturn<bool>
{
public int AddressId { get; set; }
}
但为了确保安全,我想检查管理员角色,ManageAllAddresses的权限或者AddressId链接到此用户(可能在会话中,可能通过数据库调用) .
我怎么会最好的呢?
命题
下面的代码是好的做法,如果是这样,我将如何实现它?
[RequiredRole("Admin")]
[RequiredPermission("ManageAllAddresses ")]
[RequiredAddressLinkedToAccount]
public class DeleteAddress : IReturn<bool>
{
public int AddressId { get; set; }
}
2 回答
完成这个问题 . 我可以创建一个请求过滤器并将其添加到服务上 .
从AuthenticateAttribute继承或直接从RequestFilterAttribute继承 .
ServiceStack的建议是保持ServiceModel不依赖,因此我们建议您注释您的Service实现类,您可以在Service类上注释以应用于所有Operations,也可以注释单个方法仅适用于该操作,例如:
请注意ServiceStack要求您的服务返回 reference 类型,这通常是响应DTO,但也可以是
string
,例如: