I am creating a simple aspnetmvc cart application and have defined classes similar to the following:
public class Cart
{
public Guid Id { get; set; }
public string Comment { get; set; }
public DateTime CreatedOn { get; set; }
public DateTime UpdatedOn { get; set; }
public DateTime? DeletedOn { get; set; }
public List<CartItem> CartItems { get; set; }
}
public class CartItem
{
public Guid Id { get; set; }
public Guid CartId { get; set; }
public string Sku { get; set; }
public double ItemAmount { get; set; }
public double Amount { get; set; }
public int Quantity { get; set; }
}
With a very simple repository that looks something like this:
public interface ICartRepository
{
Cart CreateCart();
Cart GetCart(Guid Id);
Cart UpdateCart(Cart cart);
void DeleteCart(Cart cart);
}
After creating the classes, I begin to have the sense that I would be better suited to break out the List property from the Cart class and then recombine them in my view model.
public class vmCart
{
public Cart cart { get; set; }
public List<CartItem> CartItems { get; set; }
public string CreatedOn
{
get
{
return cart.CreatedOn.ToString();
}
}
public string CartTotal
{
get
{
var total = (double)0;
foreach (var lineItem in CartItems)
{
total += lineItem.Amount;
}
return total.ToString("c");
}
}
}
It would mean I would have to add additional methods to my model for CRUD of CartItems, but would still allow me to present the object to the view (through the viewmodel) as a combined entity.
There may be no clear advantages to either format, but I would love any feedback on the design.
Best regards,
Hal
I’d stick with just having a Cart in your model and reference it’s items through Cart.CartItems. The moment you start trying to do something in two places you are opening yourself to duplication of code.
Don’t violate Kent Beck’s “Once and once only rule.”
Your models only purpose is to give everything to the view it needs. Your business and data logic should not be in there.
Just my two cents and good luck!
Kindness,
Dan