Формат POCO в приложении asp.net MVC

2

Я создаю простое приложение для корзины aspnetmvc и определил классы, похожие на следующие:

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

С очень простым репозиторием, который выглядит примерно так:

public interface ICartRepository
{
    Cart CreateCart();
    Cart GetCart(Guid Id);
    Cart UpdateCart(Cart cart);
    void DeleteCart(Cart cart);
}

После создания классов у меня возникает ощущение, что я лучше буду разбираться с свойством List из класса Cart, а затем рекомбинировать их в моей модели представления.

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

Это означало бы, что мне пришлось бы добавить дополнительные методы к моей модели для CRUD для CartItems, но все равно разрешу мне представить объект в виде (через viewmodel) как объединенный объект.

Не может быть никаких явных преимуществ для любого формата, но я бы хотел получить любую обратную связь по дизайну.

С уважением,

Хал

Теги:
model-view-controller
asp.net-mvc

2 ответа

3
Лучший ответ

Я бы придерживался только наличия корзины в вашей модели и ссылался на нее через Cart.CartItems. В тот момент, когда вы начинаете пытаться что-то сделать в двух местах, вы открываете себе дублирование кода.

Не нарушайте Кента Бек "Один раз и только правило".

Ваши модели предназначены только для того, чтобы предоставить все необходимое для просмотра. Ваша бизнес-логика и данные не должны быть там.

Просто мои два цента и удача!

Доброта,

Dan

5

Лично я бы сохранил CartItems в корзине. Вот почему:

  • Существует четкое отношение "есть", которое указывает на то, что в Cart есть CartItems.

  • Корзина является явным агрегатом в вашей модели домена. Маловероятно, что вы загрузите тележку без загрузки предметов корзины. Хотя это делает ваши CRUD-операции более сложными в вашем репозитории, ожидается, что любой потребитель репозитория будет делать UpdateCart(), а не выполнять свою собственную итерацию и делать UpdateCartItem().

  • Разрыв его в другом объекте добавляет сложности, которые не имеют отличительной цели

  • Так же легко получить элементы в вашем представлении в любом случае.

Если что-то изменится в отношении модели вашего домена или способа работы с товарами вашей корзины, эти допущения могут измениться и, следовательно, подход, который вы принимаете. Но это то, что я вижу в данный момент.

  • 0
    Первые два ответа были потрясающими и пришли к одному и тому же выводу. Я принял самый быстрый ответ. Спасибо за помощь...

Ещё вопросы

Сообщество Overcoder
Наверх
Меню