代码之家  ›  专栏  ›  技术社区  ›  tbischel

用于工厂类的.NET外接程序,可将数据强制转换回具体类

  •  2
  • tbischel  · 技术社区  · 14 年前

    我有一个主机应用程序,它控制各种工厂类,这些类产生一个公共数据契约的实现。此外,所有工厂都源于一个特定的工厂合同。工厂可能需要特定的数据契约实现来生成自己的对象…因此主机可以通过工厂契约中的一个函数来传递数据,该函数有一个数据契约类型的参数。然后这些工厂试图把它铸造成他们感兴趣的类型…如果不匹配则忽略它。到目前为止,这一切都正常。

    我想扩展它以允许用户使用.NET外接程序框架创建外接程序工厂,但我担心隔离边界…例如,如果一个工厂生成IData实例,那么另一个工厂是否可以将外接程序生成的对象强制转换为共享的具体实现类型?似乎在外接程序管道中需要适配器可能会把这件事搞砸?

    例如,在下图中,具体类数据a将在plugina和pluginb之间共享,具体类数据b将在pluginb和pluginc之间共享。


    编辑: 到目前为止,我只知道System.Addin创建外接程序的功能…以及旧的涉及直接反射的方法。我刚刚发现了MEF,它不关心系统核心的隔离边界。有经验的人知道这会如何影响我的场景吗?

    我想扩展它以允许用户使用.NET外接程序框架创建外接程序工厂,但我担心隔离边界…例如,如果一个工厂生成IData实例,那么另一个工厂是否可以将外接程序生成的对象强制转换为共享的具体实现类型?似乎在外接程序管道中需要适配器可能会把这件事搞砸?

    例如,在下图中,具体的类数据a将在plugina和pluginb之间共享,具体的类数据b将在pluginb和pluginc之间共享。

    alt text


    编辑: 到目前为止,我只知道System.Addin创建外接程序的功能…以及旧的涉及直接反射的方法。我刚刚发现了MEF,它不关心系统核心的隔离边界。有经验的人知道这会如何影响我的场景吗?

    1 回复  |  直到 14 年前
        1
  •  0
  •   tbischel    14 年前

    所以经过一些试验,我发现 MEF 可以解决这些问题。系统所产生的隔离屏障,使系统无法恢复实际的具体实现…MEF允许我将发现的外接程序从了解特定实现的外接程序中强制转换回其具体类型。