Понимание CRUD с помощью композиции

Question

Я очень хочу понять, как организовать свой код. Скажем, у меня есть класс под названием «Бренд», у которого есть объект «Продукт»:

public class Brand {
   public int ID { get; set; }
   public int name { get; set; }
   public Product product { get; set; }

    public void add(Brand brand)
    {
       // Database logic
    }

}

И этот класс называется product

public class Product {
   public int ID { get; set; }
   public int name { get; set; }
}

Я хочу знать, должен ли я иметь метод AddProduct внутри класса продукта или должен быть в верхнем классе «Brand». Это мое замешательство.

Answer 1

Способ, которым вы объявили продукт, использует свойство C# Auto.

Прежде всего, вы должны спросить себя, нужно ли вам, чтобы product отображался как public участник, или вы хотите инкапсулировать logi c настройки product.

Если ответ таков, что вы хотите, чтобы Product мог быть установлен снаружи, то нет необходимости объявлять какие-либо дополнительные метод:

public class Brand
{
    public int Id { get; set; }
    public string Name { get; set; }
    public IProduct Product { get; set; }
}

public static void Main(string[] args)
{
    var brand = new Brand
    {
        Id = 1,
        Name = "Name",
        Product = new Product()
    };
}

Однако, если вы хотите инкапсулировать способ, которым вы устанавливаете product, рассмотрите возможность использования подходов Composition или Aggregation:

public class Brand
{
    private int _id;
    public string _name;
    private readonly IProduct _product;

    public Brand(IProduct product, int id, string name )
    {
        _product = product;
        _id = id;
        _name = name;
    }
}

public static void Main(string[] args)
{
    var brand = new Brand(new Product(), 1, "prd");
}

Примечание: если вы по-прежнему хотите иметь возможность устанавливать product после объявления объекта, рассмотрите другое имя для метода, например SetProduct или что-то близкое по значению, потому что AddProduct означает, что вы имеете дело с коллекцией продуктов.

Answer 2

Чтобы лучше понять это, подумайте о разделении проблем и единой ответственности. Ответ в этом посте - хороший способ выразить это.

Прямо сейчас у вас есть объект с именем Brand, который содержит метод Add и некоторые свойства, относящиеся к тому, чтобы быть объектом Brand. Это означает, что Бренд отвечает не только за управление собой, но и за управление своим взаимодействием с базой данных. Вы также исправляете аналогичную связь между Product и базой данных. Что тогда происходит, когда у вас есть набор брендов, и вы понимаете, что у каждого бренда должен быть набор продуктов, и все они имеют базу данных logi c, разбросанную по всей? Затем предположим, что вы заметили, что для каждого Продукта требуется список ингредиентов, поэтому вы должны добавить его, поэтому для ингредиентов требуется logi c, et c. et c. Как видите, это очень быстро сбивает с толку.

Итак, на самом деле у вас должен быть третий класс, который отвечает за управление объектами базы данных, и этот класс будет иметь методы для вызова, которые принимают ваши объекты бренда и продукта в качестве параметров и взаимодействуют с базой данных внутренне . Теперь вы абстрагировали свою базу данных logi c от вашей торговой марки и продукта logi c, поэтому класс базы данных может делать то, что он создан для , но не более , а объекты Brand и Class могут существовать как определены оболочки для связанных данных и не более . Теперь все разделено, поэтому каждый класс представляет собой единую простую концепцию. Класс Brand существует для представления данных бренда. Database класс существует для взаимодействия с базой данных.

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