Clever Geek Handbook

POCO format in asp.net MVC application

I am creating a simple aspnetmvc shopping 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 get the feeling that I would rather deal with 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");
        }
    }
}

This would mean that I would have to add additional methods to my CRUD model for CartItems, but would still allow me to present the object (via the viewmodel) as a concatenated object.

There may not be any clear advantage to any format, but I would love to receive any design feedback.

Respectfully,

Hal

+2


source to share


2 answers


I would stick with just having a cart in your model and linking to it via Cart.CartItems. The moment you start trying to do something in two places, you open yourself to duplicate code.

Don't break the Kenta Beck "Once and only rule."

Your models are only intended to provide everything you need to view. Your business logic and data shouldn't be there.



Just my two cents and good luck!

Kindness,

Dan

+3


source


Personally, I would keep CartItems in the cart. That's why:

  • There is a clear "is" relationship that indicates that Cart has CartItems.

  • The shopping cart is an explicit aggregate in your domain model. It is unlikely that you will load a cart without loading cart items. While this makes your CRUD operations more complex in your repository, any consumer of the repository is expected to do UpdateCart () rather than iterate and do UpdateCartItem ().

  • Breaking it apart in another object adds complexity that has no distinctive purpose.

  • It's just as easy to get the items in your view anyway.



If something changes with respect to your domain model or the way you work with your cart items, those assumptions may change and hence the approach you take. But this is what I see at the moment.

+5


source






More articles:


All Articles