Постарайтесь, чтобы ваши объекты представляли вещи в реальной жизни.Теперь это может звучать немного странно, но объект с именем OrderProduct
ничего не представляет в реальной жизни, а также является плохим дизайном.Что вам нужно, так это отношения между Product
и Order
.А как насчет List<Product>
в классе Order
?Вы можете заполнить этот список продуктами и легко удалить продукты.Затем, взаимодействуя с вашей базой данных, вы делаете запись в своей таблице OrderProduct
для каждого элемента в списке.
Посмотрите на это, чтобы получить представление:
public class Product
{
int productID;
string name;
}
public class Order
{
int orderID;
Customer customer;
List<Product> products;
DateTime orderDate;
}
Вы, кажется,смешивать парадигмы.Помните, что вы занимаетесь объектно-ориентированным программированием с помощью реляционной базы данных.Вы не должны смешивать эти два.Например, в вашей базе данных нет объекта, представляющего таблицу.Объект представляет объект в реальном мире, и его свойства могут храниться в комбинации таблиц.Заказ - это то, что было сделано клиентом, имеет список продуктов, количество, общую стоимость и т. Д. Вы не можете сохранить этот 1 объект в 1 записи в вашей базе данных, как вы знаете из применения нормализации в вашей реляционной БД.Таким образом, 1 объект приводит к нескольким записям в вашей БД.
Часто программисты ООП создают в своих программах «Уровень данных» или «Уровень», который «преобразует» из ООП в реляционный перед сохранением в БД.