MVC 模型的 C# 最佳实践答案

【问题标题】：C# Best Practice With MVC ModelsMVC 模型的 C# 最佳实践
【发布时间】：2016-02-27 05:11:14
【问题描述】：

只是在此处寻找有关最佳做法的一些指导。我有一个产品订单系统的订单清单，如下所示：-

public class CurrentOrderManifestViewModel
{
    public int OrderID { get; set; }
    public List<CurrentOrderItem> CurrentOrderItems { get; set; }
    public decimal? MinimumOrderSurcharge { get; set; }
    public decimal? OrderSurcharge { get; set; }
}

public class CurrentOrderItem
{
    public int OrderProductID { get; set; }
    public string ProductDescription { get; set; }
    public string ProductCode { get; set; }
    public decimal? UnitPrice { get; set; }
    public int Quantity { get; set; }
    public decimal? VATRate { get; set; }
    public decimal? VATValue { get; set; }
    public decimal? GoodsValue { get; set; }
    public bool IsOnPromotion { get; set; }
}

我现在处于应用程序的不同区域，与最初创建它的位置不同，我发现自己具有相同格式的非常相似的属性。但是上面所有与价格有关的字段都不会填写，因为我只是在看产品名称和描述。

我应该创建一个只包含我需要的属性的不同模型，还是使用相同的模型并在订单项列表中有很多 NULL 值？

谢谢！

【问题讨论】：

可以创建一个类然后让另一个扩展它，然后在每个区域使用正确的类

标签： c# asp.net-mvc model-view-controller model naming-conventions

【解决方案1】：

我现在在应用程序的不同区域中最初是为我创建的，我发现自己具有非常相似的属性以相同的格式。但是上面所有与价格有关的领域都是不会被填满，因为我只是在看产品名称和说明。

DRY 原则不是“永远不要写两次代码”，而是“every piece of knowledge must have a single, unambiguous, authoritative representation in the system”。

仅仅因为应用程序的两个区域具有相似的属性本身并不意味着它们应该共享一个类。每当企业想要向一个区域添加或修改一个字段时，它都会影响另一个区域，您必须始终记住这一点。确定它们现在具有相同的属性，但它们会永远保持相同吗？

我应该创建一个仅包含我需要的属性的不同模型还是使用相同的模型并且在订单列表中有很多 NULL 值物品？

根据我的理解，我不建议为您的案例使用相同的模型。如果您构建的模型有一个有意义的名称、包含它实际拥有的属性，并且以后可以根据需要进行更改，而无需弄清楚它在应用程序中的其他位置，它将让您的生活更轻松。我敢肯定，您还可以找到一个更能代表该应用程序区域的名称。

换一种说法，在它实际上不是当前订单商品的地方使用CurrentOrderItem 是个坏主意。

【讨论】：

【解决方案2】：

它不正确或不正确。 ViewModel 应该具有渲染视图所需的所有信息，就是这种情况。

如果其他属性很重，则可能出于性能原因为此目的创建自定义对象。但是，在这种情况下，属性很简单，这不是问题。

他们关心的是什么？将来维护您的代码的人清楚地知道，这些对象的某些属性不是用数据填充的，而是留空的。

显然，如果您创建一个没有这些属性的类，那么没有人会误以为这些变量已设置。

另一种选择是给List 一个非常清晰的名称，并对其进行注释，以便以后有人会理解这一事实，例如：

///<summary>
/// This list includes the order items with all the price properties
/// set to null.
///</summary>
public List<CurrentOrderItem> CurrentOrderItemsWithoutPrices { get; set; }

因此，决定与编写更多代码（创建一个没有该属性的新类，进行一些映射，手动或自动）或依赖良好的属性命名和注释之间的平衡有关。在这种特殊情况下，我认为视图模型的意图非常明确，一个简单的注释可以使其更加清晰，以供将来维护，因此您可以节省编写额外代码（必须维护）。

【讨论】：