MVC模型的C＃最佳实践

Question

Just looking for some guidance on best practices here. I have an order manifest for a product order system, which looks like the following:-

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; }
}

I am now in a different area of the application to where this was originally created for and I find myself with very similar properties in the same format. But all of the fields above to do with prices are not going to be filled, as I am looking purely at product names and descriptions.

Should I create a different model with just the properties I need or use the same model and have lots of NULL values in the list of order items?

Thanks!

Answer 1

I am now in a different area of the application to where this was originally created for and I find myself with very similar properties in the same format. But all of the fields above to do with prices are not going to be filled, as I am looking purely at product names and descriptions.

The DRY principle is not "never write code twice", but rather that " every piece of knowledge must have a single, unambiguous, authoritative representation in the system ".

Just because two areas of an application have similar properties does not, by itself, mean that they should share a class. Anytime the business wants to add or modify a field to one area, it will affect the other, and you will always have to remember that . Sure they have the same properties now , but will they be the same forever ?

Should I create a different model with just the properties I need or use the same model and have lots of NULL values in the list of order items?

I don't recommend using the same model for your case, from my understanding of it. It's going to make your life easier down the road if you build a model that has a meaningful name, contains properties that it actually has, and can be changed as needed later without having to figure out where else in the application it's used. I'm certain you could also find a name that would better represent this area of the application.

To put it a different way, it would be a bad idea to use CurrentOrderItem in a place where it isn't actually an item for a current order.

Answer 2

It's not correct or incorrect. A ViewModel should have all the information required to render the view, which is the case.

If the other properties were two heavy, there could be a performance reason to create a custom object for this purpose. However, int this case the properties are simple, and that's not a concern.

Which is the concern them? That someone who maintains your code in the future knows clearly that some properties of those objects are not filled wit data, but left null.

Obviously, if you create a class without those properties, noone can make a mistake thinking that those variables are set.

The other options is to give the List a very clear name, and comment it so that someone later will understand that fact, for example:

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

So the decision has to do with a balance between writing more code (create a new class without that properties, do some mapping, manual, or automatic) or rely on good property naming and commenting. In this particular case I think that the intention of the view model is extremely clear, and a simple comment can make it even more clear for future maintenance, so you can spare writing additional code (that would have to be maintained).