微软自己要做的事情别人当然懒得做……

我也同意。我在使用Remoting的过程中，就感觉，这不就是一个AOP吗？

我觉得一般不用CBO的原因:
1,限制了用户类的实现,一定得从CBO继承而来..
2,和.NET Remoting相关.据说M$将会取消.NET Remoting.
3,不能对同一个Context中的函数进行拦截..

所以,还是比较喜欢Emit..

to:DLU,那只是介绍的文章。MS应该不会做这些东西的。

to:redmoon,我不太肯定这个。

to:saucer,就如那篇文章所说的，COM+提供的服务是"Site Effects",调用方法前做个东西，调用方法后作个东西。不过后面说到怎样在DotNet做的时候，"The Hope"是代码生成器，我不太认同。他那时不太相信用[Attribute]帮助拦截方法的调用。

to:HBifTs,说得对。我最近看过一些Java的东西。发现它们很喜欢用interface来定义他们的设计，然后提供DefaultImplementation。
不过一个类在继承于哪个类，是看调用者而定的。
例如调用者希望对象是一个Control，那么没有办法，必须继承Control。因为调用者调用的是Control的成员，而不是新的服务的方法。
但是，作为新开发的东西，新的类的成员不被类型所限制。
DotNet的WebService必须要继承System.Web.Services.WebService吗？为什么我们还是用得好好的？关于类的继承矛盾，这个可以用设计的方法来解决。（例如用Adapter，把一个不是那个类换成那个类）

就算MS放弃Remoting的，也不代表MS要删除Remoting。
3,不能对同一个Context中的函数进行拦截..??

@Lostinet:

redmoon说的还是很有道理的，因为有一种aspect就是提供对象位置透明性的，Remoting架构中的一个主要部分就是提供这个机制。

实际上，所谓对象的aspect而不是feature，主要就是看它能否透明的施加在某一类对象上。因为.NET Remoting可以为所有的MBR派生对象提供位置透明服务，这一层功能就应该算是利用AOP的思想施加到对象上的。

BTW: MTS应该算是最早的较为完整的AOP实现了，这要得益于COM本身的设计——所有发往对象的调用都是会被拦截的。COM中的线程同步、安全、TreatAs也都是这样实现的。.NET为性能考虑而没有对所有对象方法调用进行拦截，而只对MBR对象通过TP/RP提供这样的特性。

当然了，利用Emit相当于利用OOP来动态实现AOP，也有一定的优势吧。：）

:)
你说的是
public MethodB()
{
this.MethodA();
}
这样的情况吧。
我的AspectComponent做到了。
：
namespace NUnitTestLib
{
using System;
using System.Collections;
using System.ComponentModel;
using System.Diagnostics;
using System.Reflection;
using System.Text;
using System.Threading;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Proxies;
using System.Runtime.Remoting.Messaging;

using Lostinet.ContextBoundModel;
using NUnit.Framework;

[TestFixture]
public class Local_0040_AspectComponent
{
class SimpleComponent : AspectComponent,IAspectServerMessageHandler
{
string lastmethod;

IMethodReturnMessage IMessageHandlerBase.ProcessMessage(IMethodCallMessage mcm, AspectObjectProxy proxy, MessageHandlerQueue queue)
{
lastmethod=mcm.MethodName;

return queue.InvokeNext(mcm,proxy);
}

//get self's TransparentProxy!
new protected SimpleComponent GetTransparentComponent()
{
return (SimpleComponent)base.GetTransparentComponent();
}

public void MethodA()
{
Assert.AreEqual("MethodA",lastmethod);
}

public void MethodB()
{
Assert.AreEqual("MethodB",lastmethod);

try
{
MethodA();//run as this!
}
catch(Exception x)
{
//OK , the last method should not be MethodA!
Console.WriteLine(x.Message);
}

Assert.AreEqual("MethodB",lastmethod);
}

public void MethodC()
{
SimpleComponent thistp=GetTransparentComponent();

Assert.AreEqual("MethodC",lastmethod);

thistp.MethodA();//run as the TransparentProxy!

Assert.AreEqual("MethodA",lastmethod);
}
}

bool disposed=false;

[Test] public void Basic()
{
using(SimpleComponent sc=new SimpleComponent())
{
sc.MethodA();
sc.MethodB();
sc.MethodC();

sc.Disposed+=new EventHandler(sc_Disposed);
}

Assert.IsTrue(disposed,"the Disposed event must be raised!");
}

private void sc_Disposed(object sender, EventArgs e)
{
disposed=true;
}
}
}

to: JGTM'2004 [MVP]
Aspect的概念是如此的话，那么Remoting就是了。
而且 RemotingProxy 还对GetType,GetHashCode进行拦截呢
：）

呵呵,我的想法就是尽量对用户透明.他不用理解我的框架里面的东西.也不用去写和我的框架相关的代码..

to:hBifTs
要做到这个不容易啊。
那需要很多和语言和平台相关的东西能支持才行。
可惜我们能干预的DotNet的这些实在太少了。。
动态对一个interface进行包装还好。
但是对于具体的对象就难多了。
例如你那边的方案是重写虚拟方法。
这也是一种为了实现的约定啊。

嗯,这个没办法..除非使用别的方法.比如Profiling.但是扩展性还是不够强..
可能如果真的要做成想的这样,只能通过研究Remoting中的TP/RP了~

呵呵,话说回来.要提倡面向接口编程..这样Virtual函数的问题就搞定了~

其实我那套方案是支持多种的。

1。MarshalByRefObject
对于这个对象，用AspectServices.CreateServerAspectObject。
不过这个需要现成的对象。
例如
MyMBR mbr=new MyMBR();
mbr=(MyMbr)AspectServices.CreateServerAspectObject(mbr,null);
（所以，所有的System.ComponentModel.Component都能被CBM拦截）
这个有个缺点就是，无法拦截构造方法了。

2.ContextBoundObject/AspectObject
这个可以用上面说的那一套。
如果ContextBoundObject不用上面的，那么它要标记为[AspectObject] 和 实现 IAspectObject

3.AspectComponent
这个的目的是提供IComponent的实现。
并且提供GetAspectProxy(),GetTransparentComponent()的支持。

明白你的意思了:P

：）
我现在也提供了拦截Interface的方法了
object obj=AspectServices.CreateAspectInterface(typeof(ISimpleInterface),notmbr,new IMessageHandler[]{new SimpleHandler()});
即使目标对象不是MBR的，也可以通过我的Proxy把它进行针对某interface的拦截。
而且这个obj是MarshalByObject的。
这样一个非远程的对象可以以interface的形式发布到其他的应用程序域中了 ：）

首先声明，我对.Net不是很熟。:-(不过，使用过AspectJ和AspectC++。
不懂为什么你们总是要讨论“拦截”method,那么Property如何拦截呢？C++中的全局变量如何拦截呢？
我看来你们讨论的只是基于组件的一种aspect，而不是真正基于语言层次的（比如C++）。不知我理解是否对头？

@noname
在Java下面,你所谓的基于语言层次的只有AspectJ了.现在在.NET下面还未出现相关的软件~

to noname :
拦截 method 的意思,就是拦截代码.

DotNet里,Property就是set_Property/get_Property
如果是基于TP/RP的,连字段都是用Object.FieldSetter/FieldGetter来实现的.

我这里不是讨论定死为基于组件的Aspect,而可以看作是基于设计的Aspect.

据我所知, AspectJ/AspectC++与其说是基于"语言"层次的,还不如说是基于"编译"层次的.
我想它们的用意只是希望把重复的代码分开来写.但是target class与aspect class必须是同时编译的..

而我目前研究的,是怎样用AOP实现,A公司做的target class,可以用配置/编程的形式被B公司做的aspect class进行interception .
而且这个,已经实现了. 剩下的就是细节/规范的问题了。

真是麻烦~~~~

PermissionPrincipalAttribute已经是个AOP的东西了,如果建议微软开放这个功能,大家就皆大欢喜了.

想想, 从C#语言内置支持...

是的.代码安全检查是DotNet内部提供的可扩展的机制.
但它不完全是AOP.因为在IPermission里,除了StackTrace,其他什么信息基本都不能获得.
除了抛出异常或修改静态的数据,就无法改变方法的行为了.

d