C# 有没有办法“杀死”模型属性?

C# 有没有办法“杀死”模型属性?,c#,wpf,datagrid,C#,Wpf,Datagrid,我的应用程序的前端是一个DataGrid,其内容被传递给Excel生成方法 问题是DataGrid处理13列:其中10列是固定的,即传递给Excel,而最后3列中的每一列都是可选的 public class GridModel { public string Item { get; set; } public string ItemName { get; set; } public double TotalHeight { get; set

我的应用程序的前端是一个DataGrid,其内容被传递给Excel生成方法

问题是DataGrid处理13列:其中10列是固定的,即传递给Excel,而最后3列中的每一列都是可选的

public class GridModel
{
    public string Item          { get; set; }
    public string ItemName      { get; set; }
    public double TotalHeight   { get; set; }
    public double AGLheight     { get; set; }
    public double Embedment     { get; set; }
    public string Shape         { get; set; }
    public double TipDiameter   { get; set; }
    public double BaseDiameter  { get; set; }
    public double Taper         { get; set; }
    public double ShearReaction { get; set; }
    // The following are optional, in 8 combinations, from all present to all absent
    public double Camber        { get; set; }
    public double Rake          { get; set; }
    public double Angle         { get; set; }
}
作为一个C新手,我正在考虑不同的方法

你们怎么处理这件事?想到的最简单的想法是向模型添加3个标志:

bool IsColumn1Present;
bool IsColumn2Present;
bool IsColumn3Present;
另一种方法是向层次结构添加一个级别,这样每个“特殊”列都包含自己的嵌入标志:

if (Camber.flag) add(Camber.value);
也就是说,我希望能够以某种方式删除这3个属性,因此任何尝试访问它们的行为都将导致错误或不可能

如果这样的东西存在,我想它会被称为变体属性

短暂性脑缺血发作


注意:我已经通过在GUI级别操纵Visibility.Visible字段解决了这个问题。然而,大师们告诉我们,这是一个坏主意。最佳实践规定,此功能应该是模型的一部分。

如果列的数量是恒定的,这意味着用户不能添加“自定义”列,我建议使用如下位字段枚举值:

[Flags]
public enum ColumnFlags
{
    None = 0,
    Camber = 0x1,
    Rake = 0x2,
    Angle = 0x4,

    // Other optional columns here, keep them powers of 2!
}
然后在模型类中,保留一个值,例如:

public ColumnFlags ColumnFlags { get; set; }
然后你可以用

if(model.ColumnFlags.HasFlag(ColumnFlags.Camber))
{
  // Do something here...
}

if(model.ColumnFlags.HasFlag(ColumnFlags.Rake))
{
   // Do something here...
}

编辑:或者,您可以使用可空类型指定缺少的值或空值。

如果列数为常量,意味着用户无法添加“自定义”列,我建议使用如下位字段枚举值:

[Flags]
public enum ColumnFlags
{
    None = 0,
    Camber = 0x1,
    Rake = 0x2,
    Angle = 0x4,

    // Other optional columns here, keep them powers of 2!
}
然后在模型类中,保留一个值,例如:

public ColumnFlags ColumnFlags { get; set; }
然后你可以用

if(model.ColumnFlags.HasFlag(ColumnFlags.Camber))
{
  // Do something here...
}

if(model.ColumnFlags.HasFlag(ColumnFlags.Rake))
{
   // Do something here...
}

编辑:或者,您可以使用可空类型指定缺少的值或空值。

您可以使用可空属性:

public double? Camber { get; set; }
然后检查它们在您的业务逻辑中的值:

if (thing.Camber.HasValue)
{
    DoSomething(thing.Camber.Value);
}
考虑到您对变量属性的评论,这听起来可能正是您想要的

更多信息:


更新:如果您需要根据您的评论在应用程序范围内关闭它们,您可以避免在不需要的时候首先设置该值。就我而言,这是最好的,因为这是业务逻辑,不属于您的哑模型类,或者使用自定义访问器对其进行扩展:

private double? _camber;

public double? Camber
{
    get
    {
        return ModelSettings.CamberEnabled
            ? _camber
            : null;
    }
    set;
}
然后在某个地方有一些静态/常量属性:

public static class ModelSettings
{
    public const bool CamberEnabled = true;
}

您可以使用可为空的属性:

public double? Camber { get; set; }
然后检查它们在您的业务逻辑中的值:

if (thing.Camber.HasValue)
{
    DoSomething(thing.Camber.Value);
}
考虑到您对变量属性的评论,这听起来可能正是您想要的

更多信息:


更新:如果您需要根据您的评论在应用程序范围内关闭它们,您可以避免在不需要的时候首先设置该值。就我而言,这是最好的,因为这是业务逻辑,不属于您的哑模型类,或者使用自定义访问器对其进行扩展:

private double? _camber;

public double? Camber
{
    get
    {
        return ModelSettings.CamberEnabled
            ? _camber
            : null;
    }
    set;
}
然后在某个地方有一些静态/常量属性:

public static class ModelSettings
{
    public const bool CamberEnabled = true;
}

因为它们是可选的,所以让业务逻辑查询某些内容以确定可见性是有意义的。您使用什么来确定这3个项目的可见性?当它们大于0时?您使用什么来确定这3个的可见性?简单:如果用户在这3列中的任何一列中键入任何内容,则该列将传递给Excel生成方法。任何未进行类型化的原始列都将不可见。GUI级别很好,因为它们是可选的,所以让业务逻辑查询某些内容以确定可见性是有意义的。您使用什么来确定这3个项目的可见性?当它们大于0时?您使用什么来确定这3个的可见性?简单:如果用户在这3列中的任何一列中键入任何内容,则该列将传递给Excel生成方法。任何未进行类型化的原始列都将不可见。GUI级别很好。可空性是否适用于我所需要的整个列,还是适用于每个特定的行/值?@TravisBanger-no,这将按对象设置。如果您需要应用程序范围的可访问性,您可以避免在不需要的时候首先设置值,或者根据我的编辑实现自定义访问器。就我而言,这更可取,因为这是业务逻辑,不属于您的哑模型类,我同意,我认为,让模型中的getter和setter执行默认设置以外的任何操作都可能导致代码膨胀和耦合到您不想要的地方。@akousmata正是我的观点——不过,在这种情况下,这可能是一个值得权衡的问题。如果没有更多的应用程序知识,很难说。可空性是否适用于我所需要的整个列,还是适用于每个特定的行/值?@TravisBanger-no,这将按对象设置。如果您需要应用程序范围的可访问性,您可以避免在不需要时首先设置该值,或者根据我的编辑实现自定义访问器
我关心的是,业务逻辑和不属于您的哑模型类,我同意,我认为让模型中的getter和setter执行除默认值以外的任何操作都会导致代码膨胀和耦合,这正是我的观点。@akousmata——虽然可能是这样,但在这种情况下,这是一个值得权衡的问题。如果没有更多的应用知识,很难说。