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

【问题标题】：AOP and .NET: Is Contexts an obsolete concept?AOP 和 .NET：上下文是一个过时的概念吗？
【发布时间】：2010-04-12 14:04:06
【问题描述】：

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

所有上下文绑定类都派生自 ContextBoundObject，而后者又派生自 MarshalByRefObject。 MarshalByRefObject 是 .NET Remoting 体系结构的一部分。 .NET Remoting 体系结构被认为是过时的。
大多数与 .NET 相关的书籍很少或根本不关注上下文的概念。
MSDN 几乎不提供任何关于 Contexts 的信息：解释了类，但不提供卫星文章（例如“How To”、“Overview”、“Tutorials”等）。
大多数讨论上下文的文章和论坛主题都是几年前的。
除了同步上下文之外，.NET 框架似乎几乎没有使用上下文架构。

因此，我的问题是：.NET 中的上下文概念是否已过时并且在新开发中应避免使用？如果它已经过时，推荐什么替代品？

【问题讨论】：

【解决方案1】：

是的，避免使用 MarshalByRefObject 和 ContextBoundObject 进行 AOP。

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

.NET 通过 MarshalByRefObject 支持 AOP 的事实是一个令人高兴的意外。 MBO 从未用于此目的，将 MBO 用于 AOP 是对 .NET 远程处理和 MBO 的原始意图的劫持。

这并不意味着 .NET 不能支持 AOP，只是应该使用支持 AOP 的框架（如 Spring.NET、PostSharp 等）以一种不那么“hacky”的方式来完成。

Here 是一篇关于 .NET 的 AOP 框架的好文章，虽然有点过时了。

【讨论】：

戴夫，非常感谢您的严格回答。 Yove prolly 为我节省了很多学习、设计和实施的时间。看到好想法在框架内执行不力总是让我有点难过，并且不得不使用 3rd 方框架来弥补差距，但我会坚持你的建议。
我个人并不认为 .NET 存在某种缺陷，因为它不“原生地”支持 AOP，所以我不会将 AOP 框架的考虑仅限于 Unity。 .NET 远程处理位最初从未设计为支持 AOP。在大多数情况下，AOP 是一种编程技术/约定，它位于能够支持它的框架（如 .NET）之上。
我同意，我的观点是上下文是个好主意，如果它不绑定到 MarshalByRef/Remoting 架构，我会使用它。

【解决方案2】：

我有待纠正，但如果您仅限于使用“供应商”（re:Microsoft）代码，我相信 Unity 和/或 MS 企业库策略块中存在一定程度的 AoP。

【讨论】：

非常正确，Unity 和 Enterprise 库都包含 AoP 机制。我通过 Dave 的链接发现了这一点，我目前正在调查这两个库以确定哪个更适合我的需求。您对我对供应商代码的（心理）限制是正确的。 +1，感谢您的回答。