“插件”的分类方法DLL

发布于 2024-12-06 16:44:44 字数 667 浏览 0 评论 0原文

在我的团队中,我们正在创建一个 .NET (WinForms) 应用程序,它将附加程序集 (DLL) 作为可插入组件加载。

这些操作需要分为产品类别,以便以有组织的方式在 GUI 中呈现。

我们刚刚开始实现此功能,因此对于初学者来说,我们保留一个主 .xml 文件,将不同的程序集映射到类别。

这个过程很脆弱并且容易出现许多错误,并且此功能的最终版本应该自动创建此映射(以某种方式)。

我们正在寻找一些方法来映射现在(以及将来)不同的 DLL 并保持所有这些同步。

我们的一些建议是:

  1. 属性 - 用一些属性标记每个程序集,并运行一些 在构建过程中使用自定义工具来生成某种映射文件, 根据这些属性。

    这个过程会起作用,但这意味着静态编译 类别名称到程序集本身中,使得不可能 安装后在客户端计算机上动态更新。

  2. 配置文件 - 添加程序集的配置文件( 练习这很少使用我相信)并包含所需的 信息以某种形式存在。

这些主要是我考虑过的两个选项,一个是静态的,另一个是动态的(在部署应用程序后可更新)。

尽管我们预计不会发生任何变化,要求此映射是动态的,但我不知何故觉得将其静态编译为属性是错误的。

还有其他好的选择可以满足这样的要求吗? 另外,所提出的解决方案还有我没有考虑过的其他优点/缺点吗?

In my team, we are creating a .NET (WinForms) application that loads additional assemblies (DLLs) as pluggable components.

These actions needed to be classified into product categories, in order to be presented in the GUI in an organized way.

We've just started to implement this feature, so for starters, we keep a master .xml file that maps different assmeblies to categories.

This process is brittle and prone to many errors, and the final version of this feature should automatically create this mapping (somehow).

What we're looking for is some method to map the different DLLs now (and in the future) and keep all of this in sync.

Some suggestions we've had are:

  1. Attributes - mark each assembly with some attribute, and run some
    custom tool during build to produce some sort of mapping file,
    according to these attributes.

    This process will work, however this means static compilation of
    category name into the assembly itself, making it impossible to
    dynamically update on a client machine after installed.

  2. Configuration file - Add a configuration file for the assembly (a
    practice this is rarely used i believe) and contain the needed
    information there in some form.

These are mainly the 2 options i have considered, one is static and the other dynamic (updateable after the app has been deployed).

Although we don't foresee any changes, requiring this mapping to be dynamic, i somehow feel that statically compiling this as an attribute is wrong.

Are there any other good options for meeting such a requirement?
Also, are there any other pros/cons i haven't considered with the presented solutions ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

救赎№ 2024-12-13 16:44:44

您应该在这里问的第一个问题是:

  • 谁必须能够更改程序集<->类别映射?
  • 您的每个插件程序集都可以关联到任意类别吗?或者这没有意义/可能会导致错误?
  • 在安装更新期间发生类别更改是否足够?

如果每个程序集在某个时间点只能属于定义的类别(或定义的类别列表),则将元数据构建到程序集中是正确的事情,并且如果有人更改类别,则可能会导致运行时错误以错误的方式。稍后更新类别映射并非不可能,只要安装新版本的组件就有可能。

如果其他人应该能够更改实际映射,而无需安装新版本的软件,则将映射放入单独的配置文件或 XML 文件中是正确的选择。这可能导致需要一个用户友好的对话框来以不易出错的方式更改映射。

The first questions you should ask here is:

  • who is the one who must be able to change the assembly<->category mapping?
  • can every of your plugin assemblies be associated to an arbitrary category, or does that make no sense / may be a cause of errors?
  • is it sufficient when a category change takes place during the install of an update?

Metadata to be build into the assemblies is the right thing, if each assembly can only belong to a defined category (or a defined list of categories) at one point in time, and it may be result in a runtime error if someone changes the category in a wrong way. Updating the category mapping later is not impossible, it is possible whenever you install a new release of your components.

Putting the mapping into separate configuration file or XML file is the right option if someone else should be able to change the actual mapping, without having to install a new release of your software. This may result in the need of having a user-friendly dialog to change the mapping in a not-so-error-prone way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文