在业务逻辑中使用 AOP 风格的 MVC 式授权的最佳免费方式

发布于 2024-10-18 09:23:34 字数 212 浏览 5 评论 0原文

我喜欢 ASP.NET MVC 中的授权属性。与其说是属性本身,不如说是应用它的方式。

我想在我的非 ASP MVC 服务层中使用它,最好是在我的纯 C# 业务逻辑库中,或者至少但不太优选在我的 WCF 服务端点的端点上。 PostSharp 是我唯一的答案还是有免费的类似解决方案?

I like the authorization attribute in ASP.NET MVC. Not so much the attribute itself, but the way you apply it.

I want to use it in my non-ASP MVC services layer preferably in my plain C# business logic library or at least but less preferably at the endpoints of my WCF service endpoints. Is PostSharp my only answer or is there a free similar solution?

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

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

发布评论

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

评论(5

寂寞花火° 2024-10-25 09:23:34

我处于类似的情况,最近研究了很多选择。

有一些针对 .NET 的 AOP 的开源项目,但大多数似乎已被放弃或不太活跃。 PostSharp 是迄今为止其中最成熟的。有一个免费的社区版本,可用于商业开发。

其他静态编织器(例如 PostSharp):

  • AspectDNG(已废弃)
  • Gripper-LOOM(自 2008 年以来未更新)
  • AOP.NET(似乎已废弃)

另一种选择是使用动态代理。有一些库使用了这种技术,但除了 Spring.NET 之外,它们似乎也或多或少已经死了。

我相信 Spring.NET AOP 可以在没有 Spring.NET 堆栈的其余部分的情况下使用,但我不完全确定。

如果您不介意在较低级别上工作,那么 Mono.Cecil 总是允许您像 PostSharp 一样重写程序集,但我不推荐它。这将是一项大量的工作,而且很难做到正确。

使用 Castle.DynamicProxy 或 LinFu 等生成动态代理可能是更好的方法,但仍然需要大量的工作才能使一切正常工作。另外,除非您已经在使用 IoC 容器,否则您可能需要考虑这一点,因为这将使在需要时注入代理变得更加容易。与使用 OnMethodInitationAspect 或 PostSharp 中的类似方法相比,这将需要更多的工作。

我目前倾向于使用 PostSharp(社区版),因为它可以满足我需要的一切并且非常易于使用。 Spring.NET 似乎有些有趣,但基于动态代理的解决方案不会像 PostSharp 那样优雅或易于使用。

I am in a similar situation and have recently researched quite a few options.

There are a few open source projects for AOP with .NET but most seems to be abandoned or not very active. PostSharp is by far the most mature of them. There is a community edition which is free and can be used for commercial development.

Other static weavers (such as PostSharp):

  • AspectDNG (abandoned)
  • Gripper-LOOM (not updated since 2008)
  • AOP.NET (seems to be abandoned)

The other option would be to used Dynamic Proxies instead. There are a few libraries which uses this technique but with the exception of Spring.NET they seem to be more or less dead as well.

I believe Spring.NET AOP can be used without the rest of the Spring.NET stack but I'm not entirely sure.

If you don't mind to work on a lower level there are always Mono.Cecil which allows you to rewrite assemblies just like PostSharp does but I wouldn't recommend it. It will be a lot of work and hard to get right.

Generating dynamic proxies with for example Castle.DynamicProxy or LinFu is probably a better approach then but it will still be quite a lot of plumbing to make everything to work. Also, unless you are already using an IoC-container you might want to consider that as it will make it much easier to inject the proxies where needed. Compared to using an OnMethodInvocationAspect or similar from PostSharp it will be a lot more work.

I currently leaning towards using PostSharp (Community Edition) since it does everything I need and is very easy to use. Spring.NET seems somewhat interesting but a dynamic proxy based solution won't be quite as elegant or easy to use as PostSharp.

生生不灭 2024-10-25 09:23:34

有一些解决方案 - 这是开源和的列表商业产品。唯一似乎不再存在的是 AspectSharp - 该链接已损坏。其中大多数似乎在一年左右的时间内都没有更新,但这可能是一个开始。 PostSharp 也在列表中。

希望这有帮助。

There's a few solutions out there -- here's a list of open source and commercial products. The only one that doesn't seem to exist anymore is AspectSharp - that link is broken. Most of these don't seem to have been updated in a year or so, but it could be a start. PostSharp is also on the list.

Hope this helps.

虚拟世界 2024-10-25 09:23:34

微软的Unity提供了通过方法拦截来编写AOP代码的能力。如果您的拦截方法检查了被拦截方法的属性,您应该能够准确地执行您想要的操作。

您可以在此处阅读有关 Unity 拦截的信息

Microsoft's Unity provides the ability to write AOP code through method interception. If your interception methods examined the attributes on the intercepted method you should be able to do precisely what you want.

You can read about Unity interception here

清风挽心 2024-10-25 09:23:34

NDecision 使决策树业务逻辑的实现变得非常简单,如果您是 Gherkin 语法和 Fluent 编码实践的粉丝,那么您会觉得使用它很自在。下面的代码快照来自项目站点,演示了如何实现业务逻辑。 NDecision.Aspects 是 NDecision 之上的 AOP 层。 NDecision.Aspects 实际上利用了 PostSharp 属性,并动态拦截代码执行以应用业务作为参数传递的对象(或拥有正在执行的方法的对象)的规则。

以下屏幕截图中的代码演示了如何在单独的类中编写业务逻辑:

在此处输入图像描述

然后您激活使用 NDecision.Aspects 属性之一自主应用规范(业务规则):

在此处输入图像描述

或者通过将属性应用于您的规范所适用的目标类型的方法:

在此处输入图像描述

您没有理由可以这样做不要再用你的“决策树”进行组装。 NDecision 的编写就是考虑到这一点,将逻辑分离到一个独立的层中,并且 NDecision.Aspects 部分允许在您需要的任何地方应用这些规则。

NDecision makes decision-tree business logic quite simple to implement, and if you're a fan of Gherkin syntax and Fluent coding practices you'll feel right at home using it. The code snapshot below is from the project site, and demonstrates how business logic could be implemented. NDecision.Aspects is the AOP layer on top of NDecision. NDecision.Aspects makes use of PostSharp attributes, in fact, and dynamically intercepts code execution to apply business rules on the objects being passed as parameters (or the objects that own the methods being executed).

The code in the following screenshot demonstrates how you would write your business logic in a separate class:

enter image description here

Then you activate the autonomous application of the specifications (the business rules) using one of the NDecision.Aspects attributes:

enter image description here

Or by applying the attributes to the method on the target type to which your specifications apply:

enter image description here

There's no reason why you can't have another assembly with your "decision tree." NDecision was written with that in mind, to separate the logic into one independent layer, and the NDecision.Aspects portion allows for the application of these rules wherever you need.

爱格式化 2024-10-25 09:23:34

PrincipalPermissionAttribute 是大约与 ASP.NET MVC 自己的 AuthorizationAttribute 非常接近。您可以以相同的方式使用它,只不过您装饰的是方法而不是操作。它允许您通过用户角色、用户名或仅通过她是否已通过身份验证来请求访问:

用户属于管理员角色:

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
public void YourMethod()
{
    // do something
}

用户名是john

[PrincipalPermission(SecurityAction.Demand, Name = "john")]
public void YourMethod()
{
    // do something
}

用户已通过身份验证:

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public void YourMethod()
{
    // do something
}

Thread.CurrentPrincipal 执行此操作时,它们会抛出 System.Security.SecurityException与您的访问规范不匹配。

PrincipalPermissionAttribute is about as close as it gets to ASP.NET MVC's own AuthorizationAttribute. You use it the same way, except you decorate methods instead of actions. It allows you to demand access by user role, by user name, or simply by whether she has authenticated or not:

User belongs to Administrators role:

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
public void YourMethod()
{
    // do something
}

User name is john:

[PrincipalPermission(SecurityAction.Demand, Name = "john")]
public void YourMethod()
{
    // do something
}

User is authenticated:

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public void YourMethod()
{
    // do something
}

These throw System.Security.SecurityException when Thread.CurrentPrincipal does not match your access specification.

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