如何使用 WCF 通过 StructureMap 为自定义角色提供程序提供依赖注入?

发布于 2024-08-17 01:56:13 字数 311 浏览 7 评论 0原文

我们将在 WCF 中使用自定义角色提供程序。重写的方法 GetRolesForUser 将需要使用已经存在的 RoleRepository。

现在,对于一个普通的类,我们将使用 StructureMap 来构造它,并且 RoleRepository 依赖项将通过构造函数注入。

然而,WCF 负责构建自定义角色提供程序类,并且通过 web.config 中的 roleManager 属性以声明方式“完成”。

我真的不想将 RoleRepository 依赖项硬连接到自定义角色 probvider 类中,但看起来我必须这样做。

有什么想法吗?

We're going to be using a custom role provider with WCF. The overridden method GetRolesForUser will require the use of an already existing RoleRepository.

Now, with a run-of-the-mill class, we'd construct it using StructureMap and the RoleRepository dependency would be injected via the constructor.

However, it's WCF that does the constructing of the the custom role provider class and that's 'done' declaritavely via the roleManager attribute in the web.config.

I don't really want to hard-wire the RoleRepository depndency into the custom role probvider class but it's looking like I'll have to.

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

╭ゆ眷念 2024-08-24 01:56:13

RoleProvider 和相关类型是 ASP.NET 的遗产,它们因不适合 DI 而臭名昭著。它们需要一个默认的构造函数,并且没有提供用于初始化它们的钩子。这很糟糕,但事情就是这样。

在这种情况下,最好的补救措施是将 RoleProvider 实现为 Humble 对象。换句话说,RoleProvider 必须连接所有依赖项,但从那里,它将所有实现委托给您自己的开放且可扩展的 API。

The RoleProvider and related types are legacies of ASP.NET which are infamous for not being DI-friendly. They require a default constructor and there are no hooks offered to initialize them. It sucks, but that's the way it is.

In such situations, the best remedy is to implement the RoleProvider as a Humble Object. In other words, the RoleProvider must wire up all dependencies, but from there, it delegates all implementation to your own open and extensible API.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文