AOP和.NET：上下文是一个过时的概念吗？

最近我开始学习.NET中的上下文（上下文绑定、上下文敏捷、消息接收器等）。几声警钟开始响起：

所有上下文绑定类都派生自ContextBoundObject，而ContextBoundObject又派生自MarshalByRefObject。MarshalByRefObject是.NET远程处理体系结构的一部分。.NET远程处理体系结构被认为已经过时

大多数与.NET相关的书籍很少或根本不关注上下文的概念

MSDN几乎没有提供任何关于上下文的信息：解释了类，但没有提供卫星站点文章（如“How To”s、“Overview”s、“Tutorials”等）

大多数讨论上下文的文章和论坛线程都只有几年的历史了

除了同步上下文之外，.NET framework似乎几乎没有使用上下文体系结构

---

因此，我的问题是：.NET中的上下文概念是否已经过时，在新的开发中是否应该避免？如果它已过时，建议使用哪些替代方案？

是，避免AOP的MarshalByRefObject和ContextBoundObject。

大约四年前，我使用上下文绑定的MarshalByRefObject方法推出了一个自定义AOP解决方案。当时我知道我正陷入困境，但无论如何我还是这么做了，因为许多.NET的AOP框架还很年轻

NET通过MarshalByRefObject支持AOP的事实是一个令人高兴的意外。MBO从来就不是为了这个目的，将MBO用于AOP是对.NETRemoting和MBO原意的劫持

所有这些都不意味着.NET不能支持AOP，只是应该使用支持AOP的框架，如Spring.NET、PostSharp等，以一种不太“黑客”的方式来实现

---

这是一篇关于.NET的AOP框架的好文章，尽管有点过时。

我需要更正，但如果您仅限于使用“供应商”（re:Microsoft）代码，我相信Unity和/或MS Enterprise Library策略块中存在一定程度的AOP

戴夫，非常感谢你的严格回答。你为我节省了很多学习、设计和实施的时间。看到好的想法在框架内执行得很差，不得不使用第三方框架来弥补差距，我总是有点难过，但我会坚持你的建议。我个人并不认为.NET有缺陷，因为它“本机”不支持AOP，因此，我不会将AOP框架的考虑局限于统一性。NET远程处理位最初从未设计为支持AOP。在大多数情况下，AOP是一种编程技术/约定，它是在能够支持它的框架（如.NET）之上分层的。我同意，我的观点是，上下文是一个好主意，如果它没有绑定到MarshalByRef/Remoting体系结构，我会使用它。非常正确，Unity和Enterprise库都包含AOP机制。我通过Dave的链接发现了这一点，目前我正在调查这两个库，以确定哪一个更适合我的需要。关于我对供应商代码的（心理）限制，你是对的+谢谢你的回答。