【问题标题】:simplemembership provider tied to system.web绑定到 system.web 的 simplemembership 提供程序
【发布时间】:2014-03-24 21:57:22
【问题描述】:

我们想在我们的应用程序中使用 simplemembership 提供程序。但是,我们觉得验证用户是否处于某个角色应该是业务逻辑的一部分。 Simplemembership 需要对 System.web 的依赖,我们不想在业务逻辑中引用它。

有没有办法将 System.web 与 simplemembership 提供程序分离?

【问题讨论】:

    标签: asp.net membership-provider simplemembership n-tier-architecture


    【解决方案1】:

    我不确定我是否同意验证用户是否属于某个角色应该是业务逻辑的一部分。我想听听关于这个推理的更多细节。但是,如果您要将授权放在业务逻辑here is a method that still decouples the security model from your business model 中。本文解释了如何使用 MVC 5 中使用的新 ASP.NET 标识来实现,但同样的概念也适用于 SimpleMembership。取决于您将授权转移到业务逻辑中的原因,the approach described here may also meet your requirements

    从您的 cmets 看来,您正试图通过将授权逻辑放在业务逻辑中来重用它,因此不必为您放入的每种类型的客户端重写授权逻辑。但事实是逻辑会因客户而异。仅举一个比较 MVC 视图与 Web API 授权的示例。 MVC 框架实际上为每个提供了两个不同的 AuthorizeAttribute,因为您希望在授权失败时表现不同。如果在要重定向到登录页面的视图上授权失败。如果 Web API 调用上的授权失败,您希望返回 HTTP 未经授权的错误。可以访问完全相同的业务逻辑的不同类型的客户端的两种不同行为。

    我认为将您的安全逻辑与业务逻辑结合起来实际上会降低业务逻辑在不同实现中的可重用性。在 Microsoft 的 Business Layer Guidelines 中,他们明确指出,“不要在同一个组件中混合授权代码和业务处理代码。”我会通过使用 approach described here 进一步将您的安全模型与应用程序分离。这将允许您在运行时更改您的安全模型,而不必重新编译和重新部署您的应用程序。并且安全模型将会改变。

    【讨论】:

    • 我想,如果我要为我的应用程序构建另一个界面,并且有一条规则说“只有管理员可以删除产品”,那么该规则将存在于业务逻辑中,并且不会重复前端。我是不是搞错了?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-10
    • 2015-02-11
    • 1970-01-01
    • 2020-05-23
    相关资源
    最近更新 更多