属性或属性

时间:2009-09-11 17:03:20

标签: c# .net

我想为每个编写的模块/插件添加一些功能,例如:

  

作者,公司,日期等

代表它的来源和编写者。然后程序员可以在一个DLL中有多个插件。我应该如何实现对这些的支持,以便我可以在主应用程序UI中访问它们?通常,1个插件是一个公共类。

我应该使用属性还是属性?我也应该使用接口吗?

我希望程序员能够填写这些内容,而不是让它成为可选项。

7 个答案:

答案 0 :(得分:5)

我会用自己的界面。 好的是,你可以将它添加到现有的类中,而不必对现有代码进行重大的重写,只需添加界面的属性/方法。

答案 1 :(得分:2)

我会选择属性,只是因为它听起来像你想要跟踪的项目不需要成为应用程序的一部分,而是代码本身的装饰。

此外,我认为如果程序员是一个属性,那么程序员添加其他垃圾并不真正属于的诱惑会更少。

答案 2 :(得分:2)

我认为使用界面是一种更好的方法。 因为每一个想要编写插件的人都应该根据契约(实现一个接口或者将一些属性放在他的类成员上)来做到这一点,所以从插件开发者的角度来看这并不重要,但它会更容易,更加结构化(我认为更快),让您的程序识别和利用基于接口的实现类。

答案 3 :(得分:2)

由于数据在技术上是关于类的元数据,而不是插件所需的实际状态,我会使用属性。属性旨在成为关于代码的元数据,这正是您想要的。

就执行它们而言,如果元数据丢失,您可能无法加载主机应用程序。这样,插件开发人员将无法在不提供数据的情况下测试插件。但是,您应该提供充足的文档,以便他们知道丢失的内容,或者在加载插件失败时提供详细的错误。

大多数程序集已经具有在AssemblyInfo类中设置的一些基本信息(公司,版本等)。你也可以改用它。

此外,为了防止丢失数据问题,您可以使用单个PluginAttribute将属性中的所有元数据作为参数,并要求主机的该属性加载该类。我最初想的是你想要记录的每个项目的一个属性,但是单个属性可以更好地工作。

答案 4 :(得分:1)

如果您使用属性,那么插件实施者会更难注意到他们是否忘记填写其中一个字段。使用抽象属性,他们将被迫实现它或面临编译错误:

public abstract class PluginBase
{
    protected PluginBase()
    {
    }

    public abstract string Author
    {
        get;
    }

    // ...
}

唯一的缺点是这种信息实际上是元数据,因此您可以从“语义正确”的角度来看待属性看起来更好。

答案 5 :(得分:1)

已经有了这方面的原因,为什么要重新发明轮子?

using System.Reflection;

[assembly: AssemblyTitle("my app")]
[assembly: AssemblyDescription("good app")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("mycorp")]
[assembly: AssemblyProduct("my prod")]
[assembly: AssemblyCopyright("Copyright © me 2009")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
[assembly: AssemblyVersion("1.0.0.0")]

默认情况下,它们已存在于AssemblyInfo.cs文件中。

这是在程序集中存储版本信息和其他元数据的标准方法。也许还有其他感兴趣的属性,您也可以为此创建自己的属性。

答案 6 :(得分:0)

就个人而言,我会选择属性,但会将值赋给构造函数中的后备只读属性。

两全其美。 :)