我想问一下这里3的信息：

有没有集成的解决方案作为面向方面编程（AOP）在C＃（.NET）的微软是正确的？是否有正在开发的任何这样的解决方案或计划？

有什么解决办法是有的允许面向方面编程（AOP）在C＃（.NET）一起使用？它们是什么 /缺点优点？我还没有找到任何comprihensive列表将包含所有avatable选项和一些资料给我来决定这是一款使用。最接近的是此列表。

什么是（在您看来）的最好的AOP 解决方案的C＃（.NET）考虑下面的标准：

在它schould工作类似于AspectJ和具有类似的语法 在简单的使用：XML配置应是必要的 - 只是写一些普通班，某些方面的类和编译编织它一起，然后运行 应包括AspectJ中的所有功能。支持泛型。 解决方案应该是稳定的，广泛使用和mainteine​​d。 应提供二进制文件的织（所以可以使用）或C＃源$ C ​​$ C。 在GUI工具，可视化（甚至更好 - 插件，VS）是一个优点

我觉得，如果事情fullfils大部分在3标准，那么它是一个generaly使用的解决方案的候选人。我无法找到任何地方，如果一些现有的解决方案，适合我的需要。

解决方案

正如亚当Rackis指出，邮政＃是要走的路，这是接近你会得到AspectJ的.NET平台上。

主要区别是很明显的AspecJ具有语言方面的支持，而帖子＃是一个后编译织工的.NET程序集。 （因此没有语言集成）

不过，邮政＃可以使用的连接点，如字段访问，尝试catch块，两个通话和功能（即主叫方和被叫方）

没有，甚至不敢靠近，AspectJ是一种语言，发表＃可以使用自定义的切入点，但最常见的是使用属性装饰方法加以pointcutted（eh..grammar？）

检查

一切，但语言支持

检查

检查 - 这是一个后编译韦弗

有限，韦弗将生成智能感知信息，并显示什么方法都受到了影响。

如果你想支持方面.NET语言，请 http://aspectsharpcomp.sourceforge.net /samples.htm

对于不同的方法，有几个：

邮编编织，这就是邮政＃一样。 它只是轧液.NET程序集并注入方面code。

真实代理/ MarshallByRefObject。 基于远程处理的基础设施。 要求你的类从基类继承。 极坏的表现，并没有自我拦截

动态代理。 这是我的老图书馆NAspect使用。 您使用一个工厂来创建要在其应用方面的类型的子类。 子类将使用接口增加混入code和重写虚方法，并注入拦截code。

来源$ C ​​$ C编织。 顾名思义，它把编译前的源$ C ​​$ C。

我忘了这一个添加到列表：

接口代理 类似于动态代理，但不是应用截取code键的子类，截取code为加入到生成的运行接口代理。 也就是说，你得到一个对象来实现给定的接口，该对象则代表每次调用任何的接口方法首先给AOP拦截code，然后将其委托的调用真正的对象。 也就是说，你有两个对象在这里打球，代理和主题（你真正的对象）。

客户端 - ＆GT;接口代理 - ＆GT; AOP拦截 - ＆GT;目标/主题

这是AFAIK什么春呢。

1）和3）是最常见的。 他们都有优点和缺点：

后编译：

优点：

可以切入点pretty的每样东西，静态，封闭，私有 仍可使用被创建的对象的新

缺点：

基于上下文无法应用的方面，即，如果一个类型的影响，它会受到影响为整个应用程序

Pointcutting私有，静态的，封闭的结构可能会导致混乱，因为它打破了面向对象的基本规则。

动态代理：

优点：

语境，一是典型值可以有不同方面的应用型环境。

易于使用，无需配置或建立步骤。

缺点：

有限公司切入点，网卡成员和虚拟成员可以被拦截

必须使用工厂来创建对象

I would like to ask for 3 information here:

There is no integrated solution for Aspect Oriented Programing (AOP) in C# (.Net) from Microsoft is that correct ? Is there any such solution under development or planned ?

What solutions are there that allow Aspect Oriented Programing (AOP) to be used in C# (.Net) ? What are they advantages/disadvantages ? I haven't find any comprihensive list that would contain all avatable options and some information for me to decide which is the one to use. The closest is this list.

What is (in your opinion) the best AOP solution for C#(.Net) considering following criteria:

it schould work similar to AspectJ and has similar syntax simplicity of use: no XML configuration should be needed - just write some regular classes, some aspect classes and compile to weave it all together, then run. should include all features of AspectJ. Support for generics. solution should be stable, widely used and mainteined. should offer weaving of binaries (so could be used ) or C# source code. GUI tool for visualising (or even better - plugin to VS) is an advantage.

I think that if something fullfils most of criteria in 3. then it is a candidate for a generaly used solution. And I cannot find anywhere if some of existing solutions fits to my needs.

解决方案

As Adam Rackis points out, Post# is the way to go, it is as close you will get to AspectJ on the .NET platform.

Main differences is obviously that AspecJ has language support for aspects while Post# is a post compile weaver for .NET assemblies. (thus no language integration)

However, Post# can use join points such as field access, try catch blocks, both calls and functions (that is, caller and callee)

No not even close, AspectJ is a language, Post# can use custom pointcuts but the most common is to use attributes to decorate methods to be pointcutted(eh..grammar?)

check

everything but language support

check

check - it is a post compile weaver

limited, the weaver will generate intellisense information and show what methods have been affected

If you want a .NET language that supports aspects, check out http://aspectsharpcomp.sourceforge.net/samples.htm

Regarding different approaches, there are a few:

Post compile weaving , this is what Post# does. It simply mangles the .NET assembly and injects the aspect code.

Real Proxy / MarshallByRefObject. Based on remoting infrastructure. Requires your classes to inherit from a base class. Extremely bad performance and no "self interception"

Dynamic Proxy. This is what my old library NAspect used. you use a factory to create a subclass of the type on which you want to apply aspects. The subclass will add mixin code using interfaces and override virtual methods and inject interceptor code.

Source code weaving. As the name implies, it transforms your source code before compilation.

[edit] I forgot to add this one to the list:

Interface proxies Similar to Dynamic Proxy, but instead of applying the interception code to a subclass, the interception code is added to a runtime generated interface proxy. That is, you get an object that implements a given interface, this object then delegates each call to any of the interface methods first to the AOP interception code and then it delegates the call to the real object. That is, you have two objects at play here, the proxy and the subject(your real object).

Client -> Interface Proxy -> AOP interception -> Target/Subject

This is AFAIK what Spring does.

1) and 3) are the most common. They both have pros and cons:

Post Compilation:

Pros:

Can point cut pretty much everything, static , sealed, private Objects can still be created using "new"

Cons:

Can not apply aspects based on context, that is , if a type is affected, it will be affected for the entire application.

Pointcutting private, static, sealed constructs may lead to confusion since it breaks fundamental OO rules.

Dynamic Proxy:

Pros:

Contextual, one typ can have different aspects applied based on context.

Easy to use, no configuration or build steps.

Cons:

Limited pointcuts, only interface members and virtual members can be intercepted

must use factory to create objects