Формат POCO в приложении asp.net MVC - PullRequest
2 голосов
/ 24 августа 2009

Я создаю простое приложение корзины 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, но все равно позволило бы мне представить объект представлению (через модель представления) как объединенную сущность.

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

С уважением,

Hal

Ответы [ 2 ]

5 голосов
/ 24 августа 2009

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

  1. Существует четкое отношение "имеет", которое предполагает, что в корзине есть CartItems.

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

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

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

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

3 голосов
/ 24 августа 2009

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

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

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

Только мои два цента и удачи!

Доброжелательность,

Dan

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...