问授权在分层架构中适合哪里？

EN

我认为在您的服务层启用授权是绝对合理的方法。您需要保护您的服务不执行未经授权的活动(特别是数据修改)。您的服务层可以驻留在一个库中，并由不同的表示层使用(您可以有不同的UI应用程序，它们使用相同的服务层)。而且您不能依赖于特定的表示层执行必要的验证这一事实。如果您随后决定将您的服务层移动到单独的流程(例如，遵循SOA方法)，这一点尤其重要。

现在，关于如何以“干净的方式”实现这一目标。我不喜欢在授权检查中乱扔业务逻辑的想法，所以一些面向方面的编程方法的具体实现可能会有所帮助:它可以是用特殊属性装饰服务方法，也可以是使用动态代理来拦截。

更重要的是，我必须承认，在非常简单的项目中，你可以在没有单独验证的情况下生活，只是为了简化你的生活。但重要的是不要错过“简单项目”开始变成“复杂项目”的那一刻。

我喜欢把授权检查推低到他们可以去的地方！(但别再继续了！)

您仍然可以自由地编写针对“以上”层的自动授权测试。有些规则可能只适用于较高层，如服务层(CanView/CanSerialize?)。但是，我通常认为最安全的授权策略也是“最枯燥的”策略:尽可能低授权，尽可能使用最“通用”或“共享”的代码(而不是过于复杂的auth规则)。

想想另一种选择。如果您的授权规则仅在服务层中测试和强制执行，使您可怜的域对象屈从于喜怒无常的服务对象的意愿，那么您通常需要在每个对象中的多个对象和多个位置以及更复杂的代码中多次强制执行每个单独的规则。

此外，当您的分析团队雇用一家咨询公司使用您的域对象编写报告服务时，您不会想要信任那些开发人员！(或者别的什么。))以任何理由在相同对象上构建附加服务或调用。)您将不想翻开商业规则的大书，希望再次正确地执行这些规则；您希望您的领域已经知道并执行这些规则。

这是将授权检查从控制器中推出来的最有可能的好方法。控制器只是给定应用程序表示层中许多可能的实现部分之一。

如果在表示层中实现了其他API，则需要在现有控制器中找到现有的相应安全检查，并复制它们--而不是重复。这种方法容易出错，对安全性和规则的执行没有很高的信心。

为了对安全性和可靠性有很高的信心，表示层应该只对应用程序的数据和业务逻辑使用安全的接口。

我喜欢从文章DDD，六角形，洋葱，清洁，CQRS，…我是怎么把这一切组合在一起的中画出的六角形建筑图：

在整个系统的高层视图中，它是可见的，应用程序有多个不同前端的部件(API)。因此，控制器应该是尽可能薄的层，并且只做最低限度的工作，以便以所需的形式访问应用程序。