在域实体中使用DescriptionAttribute

我目前正在开发一个需要在运行时公开其一些元数据/文档的系统。我知道有使用XML注释的方法，并通过自行开发的Reflection扩展方法将数据带回到应用程序中。在域实体中使用DescriptionAttribute

我觉得使用System.ComponentModel命名空间的描述属性可能更容易（但位于System assembly中）。这样我和其他开发人员就可以使用正则反射来获取字段的描述。我宁愿使用这个比使用自定义属性。这种方法有什么缺点？

例子：

public Customer 
{ 
    public int Id { get; set; } 
    [Description("The common friendly name used for the customer.")] 
    public string Name { get; set; } 
    [Description("The name used for this customer in the existing Oracle ERP system.")] 
    public string ErpName { get; set; } 
}

来源

2013-02-26 BuddyJoe

这更像是一个陈述而非问题。你在问什么？ – Romoku 2013-02-26 18:56:25

请尝试http://codereview.stackexchange.com/而不是 – 2013-02-26 19:13:49

我做同样的事情，并没有遇到缺点（与ERP软件不能少！）。根据您的体系结构，您可能会考虑一个缺点，即许多文档工具直接或间接基于XML注释。他们可能无法获取描述属性。但是在我们的体系结构中，描述属性代码实际上并不是文档的主/源。我们有一个定义和描述每个属性的MetaData数据库。我们可以从同一个源生成XML注释和描述属性。实际上，在我们的情况下，我们根本不生成XML注释，而是直接生成通常直接由XML注释生成的XML文件。这是我们使用的文档工具所使用的文件。如果您希望使用依赖于xml注释输出的xml文件的文档工具（如果它无法直接接受Describiton属性），则可以编写一个简单的实用程序将描述属性提取到类似的XML文件中。

来源

2013-02-26 20:18:30 BlueMonkMN

好想法+1。有一件事仍然让我对“XML评论”和“属性”“闻起来不可思议”，在这两种情况下，您都需要将您的C＃源文件更新为正确的文档。你似乎用你的外部资源（数据库）来处理这个问题。你的方法遇到任何负面情况？ – BuddyJoe 2013-02-27 23:33:28

没有否定的。相反，使用“元数据库”为我们带来了许多意想不到的好处（您可以在元数据中包含和生成的代码越多，您必须对质量进行更改和查询的控制权越多）。当我们想要批量搜索或更改某些模式或对象类型时，通常只需要一个SQL查询。设计元数据模式及其周围的代码生成器时，您必须考虑周全。部分类在代码生成中非常有用。如果我真的想要考虑一个缺点，那么对于数据库表数据来说，源代码管理就不那么理想了。 – BlueMonkMN 2013-02-28 13:50:40

我以前使用过代码生成的部分类。用它来生成C＃和Java匹配的DTO。太棒了。谢谢。将与我的团队讨论，我们将在下周做出属性与数据库决策。良好的见解。 – BuddyJoe 2013-02-28 19:35:10

在域实体中使用DescriptionAttribute

回答

相关问题