用户登录逻辑属于哪里？ 3层应用

Question

我想知道用户登录逻辑在典型应用程序中的位置。在我目前的应用程序中，似乎最好的地方是UI层。因此，如果业务层被移植到新平台（例如桌面WPF到网页），各个平台将处理它们自己的安全性。这似乎也符合责任原则。例如，我的业务层不关心用户是否已登录，它只关心组件是否已请求一段已处理的数据。同样，我的UI层肯定关心用户是否已登录，因为它必须知道要显示哪些控件或操作。

问题是，记录用户需要访问数据层。 UI层显然没有。

如果我将用户登录组件放在共享的“公共”项目中，则会出现循环依赖。

最佳做法是将用户登录逻辑放在业务层吗？

我只是对常见的练习模式感兴趣，或者是你在UI层与商业层相对应的理由，反之亦然或者我没有想过的事情。

谢谢！

Answer 1

我见过的大多数企业级应用程序都实现了某种形式的安全层，它通常是独立的，可能包含角色，权限和登录方法。这通常是安全保护，它返回用户是否有权访问指定的资源。此安全层通常也有自己的数据访问层。

Answer 2

以下是我为应用程序规划安全性的示例。

1. 传入的用户凭据。演示者将凭据转发到安全层
2. 安全层与DAL保持自己的通信。可以与提单的其余部分分开。
3. DAL将数据返回给安全性，该安全性被标记化或被赋予安全密钥。
4. 安全性将令牌或安全密钥传递回应用程序的演示者/控制器
5. 应用程序包含或包含所有事务的令牌或安全密钥。

此处的提单可以在处理任何交易之前使用安全性验证令牌/密钥。

我的推荐基本上是这样的：