8

在我当前的框架设计中，我仔细阅读所有类型的特定程序集并根据找到的类型进行工作。它搜索的程序集由应用程序引导程序/初始化程序确定。程序集已编译，因此可以通过以下方式强烈引用它们：typeof(SomeTypeInTheAssembly).Assembly。这很好，因为引导程序代码对程序集中的类型有很强的引用，并且如果程序集限定名称发生更改，则不需要将完全限定名称作为内联字符串进行摸索，这些名称需要手动保持最新。但是我不喜欢在程序集中引用一些完全不相关的类型并依赖于存在的那种类型。（如果它移动到另一个程序集怎么办？如果我们弃用/删除类型怎么办？更改它的命名空间？）在代码中，它看起来也有点奇怪：

FrameworkAssemblyReader.Read(typeof(SomeAssemblyNamespace.SubNamespace.GraphingCalculator).Assembly);

现在在我的引导代码中，我有一个直接依赖关系（尽管是一个非常微不足道的依赖关系），GraphingCalculator它与引导阶段无关（作为一个 GraphingCalculator，它当然与获取程序集引用无关）。为了避免这种情况，在我打算以这种方式使用的每个程序集中，我在它们的根目录中添加了一个类：

namespace SomeAssemblyNamespace
{
    public static class AssemblyReference
    {
        public static System.Reflection.Assembly Get
        {
            get
            {
                return typeof(AssemblyReference).Assembly;
            }
        }
    }
}

这还不错，因为我的引导代码如下所示：

FrameworkAssemblyReader.Read(SomeAssembly.AssemblyReference.Get);

但是现在，我有大约十几个带​​有此类AssemblyReference复制/粘贴的程序集，我只希望它会随着应用程序构建在框架之上而继续增长。所以我的问题是，有没有一种很好的方法可以避免AssemblyReference类重复并仍然以编程方式将程序集引用传递给基础框架，同时避免指向目标程序集中的一些任意/不相关类型的模糊性？我的谷歌搜索似乎告诉我，没有 API 或语言功能可以让我强烈指向程序集（例如typeof类），但我希望这里有人提出比我更好的解决方案来避免类/代码复制。另外值得注意的是，代码有时是针对 Silverlight 编译的，所以我知道这可能会限制一些 API/技术。谢谢！

编辑：只是为了添加另一个活动扳手，基于“浣熊侠”的回答，我应该提到我并不总是加载相同的程序集。例如，我可能有一个适用于某些应用程序但不是全部的“CarBuilding”程序集。由引导程序告诉我他们希望使用哪些（以及开发人员正在使用的任何自定义）

EDITx2：回答 Jon Skeet 的问题：客户（或我们内部）将创建他们希望支持其应用程序的任何项目/DLL。反过来，这些项目将引用内部基础框架。他们的项目可能包含资源（3D 文件、图像、文本、本地化等）和插件式类（他们实现了我们在应用程序生命周期内根据需要发现和实例化/执行的脚本）。此外，我们的系统提供可选模块 (DLL)，其中包含客户（或我们）在制作特定应用程序时可以利用的可重用插件/内容。所以你可能会看到这样的项目结构：

Solution
    ->MyAppBootstrapper_Android
        ->MyAppGUI_Android
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Android

    ->MyAppBootstrapper_Silverlight
        ->MyAppGUI_Silverlight
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Silverlight
        ->BaseFrameworkGraphingModule

引导程序项目连接依赖关系，并提供应将哪些项目/dll（程序集）提供给基础框架以进行发现。请注意，在这种情况下，“MyApp”在 Android 和 Silverlight 构建中共享自己的迷你框架和共享资源，但两者都有自己独立的引用。Silverlight 充分利用了平台，BaseFrameworkGraphingModule并且他们拥有自己的特定于平台的资源。

所以在项目的引导程序中看起来像（虽然简化了）：

namespace MyAppBootstrapper_Android
{
    public class Bootstrapper
    {
        public void Setup()
        {
            FrameworkAssemblyReader.Read(MyAppGUI_Android.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(MyAppFramework.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(MyAppResources.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(MyAppAdditionalResources_Android.AssemblyReference.Get);
        }
    }
}

namespace MyAppBootstrapper_Silverlight
{
    public class Bootstrapper
    {
        public void Setup()
        {
            FrameworkAssemblyReader.Read(MyAppGUI_Silverlight.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(MyAppFramework.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(MyAppResources.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(MyAppAdditionalResources_Android.AssemblyReference.Get);
            FrameworkAssemblyReader.Read(BaseFrameworkGraphingModule.AssemblyReference.Get);
        }
    }
}

因此，对于构建在基本框架之上的每个应用程序，都会创建一个引导程序，指示要包含哪些程序集（以及其他一些不相关的接线工作）。为了具体回答这个问题，该项目具有对所需每个程序集的编译时引用（这具有双重职责，因为它确保所有 DLL 打包在一起以进行 Android/Silverlight 部署），因为它们不会动态下载到用户的智能手机或 Silverlight 应用程序但打包在初始下载中。您关于引导程序如何知道要使用哪些程序集的问题，开发人员知道并进行了必要的FrameworkAssemblyReader.Read调用。我希望这有帮助！感谢您花时间查看它。我有一种感觉，我无中生有（或者完全错过了更好的解决方案/设计）。

最后，我（愚蠢地）忽略了提到我们还针对 Android 的 Mono 进行编译，并且在不久的将来还会针对 WPF 进行编译。WinRT 可能是未来的补充，但当我们谈到它时，我会很高兴跨过那座桥。不过，一般来说，由于每个平台都以自己的方式编译并具有自己的平台功能，因此我不介意不同平台是否有不同的方式来提取程序集引用；虽然如果平台之间有统一的语法会很好。

EDITx3：是的，另一个。我提到过，但没有举例说明并非所有项目都需要或应该由基础框架阅读。例如，实用程序或业务逻辑项目的代码与基础框架无关，但与客户端应用程序相关。所以从上面的例子：

Solution
    ->MyAppBootstrapper_Android
        ->MyAppGUI_Android
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Android
        ->MyCompanySharedUtilities

    ->MyAppBootstrapper_Silverlight
        ->MyAppGUI_Silverlight
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Silverlight
        ->BaseFrameworkGraphingModule
        ->MyCompanySharedUtilities

MyCompanySharedUtilitiesMyAppGUI_Silverlight 和 MyAppFramework 可以利用它，但开发人员可能不会运行它，FrameworkAssemblyReader.Read因为它只包含一些数学或业务规则的专有实现。

4

1 回答 1

4

我不确定您希望您的客户如何使用此代码，因此此建议可能无关紧要，但取消 Setup 功能（至少，将其对客户隐藏）并使用会不会更有意义某种配置文件？

<ReferencedAssemblies>
    <ReferencedAssembly key="UnchangingKey" qualifiedName="SomeAssemblyName, version=1.0.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef" />
</ReferencedAssemblies>

从配置文件加载程序集。使用密钥，如果完全限定名称更改，您不必更新应用程序，只需更新配置文件（并保留密钥原样）。

这基本上是 Visual Studio 对其项目文件使用的方法。这是我的一个 VB 项目的示例：

<ItemGroup>
  <Reference Include="System.Core">
    <RequiredTargetFramework>3.5</RequiredTargetFramework>
  </Reference>
  <Reference Include="System.Drawing" />
  <Reference Include="System.Windows.Forms" />
  <Reference Include="System.Xml.Linq">
    <RequiredTargetFramework>3.5</RequiredTargetFramework>
  </Reference>
  <Reference Include="System.Data.DataSetExtensions">
    <RequiredTargetFramework>3.5</RequiredTargetFramework>
  </Reference>
  <Reference Include="UIAutomationProvider">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="WindowsBase">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="PresentationCore">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="PresentationFramework">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="System" />
  <Reference Include="System.Data" />
  <Reference Include="System.Xml" />
</ItemGroup>

编辑：

这是一个想法……如果您使用 Reflection.Emit 从 XML 配置文件生成程序集会怎样？您可以向生成的程序集添加一个存根类，您的核心项目可以使用它来创建对生成的程序集的硬引用，并且您可以使用反射来探测每个引用程序集（在 XML 文件中）以创建对任何对象的硬引用在引用的程序集中。当引用的程序集之一发生更改时，您需要重新生成程序集，但它不需要更改代码。您甚至可以将程序集生成代码构建到您的核心项目中，以便用户能够根据需要更新他们的项目。

于 2012-07-03T13:34:59.117 回答