Entity Framework и ООП. Как правильно реализовать принцип согласованности? В ходе разборок с DDD, возник вопрос который ломает мне мозг.
На примере такой предметной области:
Есть небольшой магазин, в нем необходимо автоматизировать процесс продажи и прием продукции на складе.
У нас существуют три варианта документа с которыми работает магазин: Чек, Возврат от покупателя, Накладная.
Кейсы (берем обычные тривиальные случаи):
1. Продажа: приходит человек, пробивается чек, списывается товар из номенклатуры.
2. Возврат от покупателя: приходит человек, оформляется возврат, товар возвращается на склад.
3. Накладная: приходит товар, оформляется накладная, товар добавляется на склад.
Теперь попробуем разбить на сущности:
1. Если брать со стороны Domain-Driven Design:
Product - товар
Order - чек
OrderLine - позиция в чеке, которая не может существовать без чека и продукта и списывает количество товара на складе
Return - Возврат от покупателя, добавляет количество товара
ReturnLine - позиция в возврате
Consignment - накладная
ConsigmentLine - позиция в накладной, добавляет количество товара
2. Data-Driven Design:
Product - товар
Document - документ, с типом(Чек, Возврат, Накладная)
DocumentLine - позиция документа
Как правильно реализовать связь между Business и Database уровнями? Маппинг?
В случае использования маппинга как решить проблему сохранения, добавления позиций, если используется Entity Framework?
Есть ли возможность подходом Code First реализовать классы из Domain-Driven для работы с базой данных, при чем чтобы таблица была одна?
Entity Framework и ООП. Как правильно реализовать принцип согласованности? В ходе разборок с DDD, возник вопрос который ломает мне мозг.
На примере такой предметной области:
Есть небольшой магазин, в нем необходимо автоматизировать процесс продажи и прием продукции на складе.
У нас существуют три варианта документа с которыми работает магазин: Чек, Возврат от покупателя, Накладная.
Кейсы (берем обычные тривиальные случаи):
1. Продажа: приходит человек, пробивается чек, списывается товар из номенклатуры.
2. Возврат от покупателя: приходит человек, оформляется возврат, товар возвращается на склад.
3. Накладная: приходит товар, оформляется накладная, товар добавляется на склад.
Теперь попробуем разбить на сущности:
1. Если брать со стороны Domain-Driven Design:
Product - товар
Order - чек
OrderLine - позиция в чеке, которая не может существовать без чека и продукта и списывает количество товара на складе
Return - Возврат от покупателя, добавляет количество товара
ReturnLine - позиция в возврате
Consignment - накладная
ConsigmentLine - позиция в накладной, добавляет количество товара
2. Data-Driven Design:
Product - товар
Document - документ, с типом(Чек, Возврат, Накладная)
DocumentLine - позиция документа
Как правильно реализовать связь между Business и Database уровнями? Маппинг?
В случае использования маппинга как решить проблему сохранения, добавления позиций, если используется Entity Framework?
Есть ли возможность подходом Code First реализовать классы из Domain-Driven для работы с базой данных, при чем чтобы таблица была одна?
На примере такой предметной области:
Есть небольшой магазин, в нем необходимо автоматизировать процесс продажи и прием продукции на складе.
У нас существуют три варианта документа с которыми работает магазин: Чек, Возврат от покупателя, Накладная.
Кейсы (берем обычные тривиальные случаи):
1. Продажа: приходит человек, пробивается чек, списывается товар из номенклатуры.
2. Возврат от покупателя: приходит человек, оформляется возврат, товар возвращается на склад.
3. Накладная: приходит товар, оформляется накладная, товар добавляется на склад.
Теперь попробуем разбить на сущности:
1. Если брать со стороны Domain-Driven Design:
Product - товар
Order - чек
OrderLine - позиция в чеке, которая не может существовать без чека и продукта и списывает количество товара на складе
Return - Возврат от покупателя, добавляет количество товара
ReturnLine - позиция в возврате
Consignment - накладная
ConsigmentLine - позиция в накладной, добавляет количество товара
2. Data-Driven Design:
Product - товар
Document - документ, с типом(Чек, Возврат, Накладная)
DocumentLine - позиция документа
Как правильно реализовать связь между Business и Database уровнями? Маппинг?
В случае использования маппинга как решить проблему сохранения, добавления позиций, если используется Entity Framework?
Есть ли возможность подходом Code First реализовать классы из Domain-Driven для работы с базой данных, при чем чтобы таблица была одна?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Для правильной реализации принципа согласованности между объектами бизнес-уровня и базой данных при использовании Entity Framework можно использовать подход Code First.
Для данной предметной области можно описать следующие классы для работы с базой данных:
Product - класс, описывающий товарDocument - абстрактный класс, описывающий документ (чек, возврат, накладная)Order - класс, описывающий чек, наследуется от DocumentReturn - класс, описывающий возврат, наследуется от DocumentConsignment - класс, описывающий накладную, наследуется от DocumentDocumentLine - класс, описывающий позицию в документеСвязи между классами можно определить с помощью атрибутов в Entity Framework, например, связь один-ко-многим между Document и DocumentLine:
public class Document{
public int Id { get; set; }
public ICollection<DocumentLine> DocumentLines { get; set; }
}
public class DocumentLine
{
public int Id { get; set; }
public int DocumentId { get; set; }
public Document Document { get; set; }
}
Таким образом, при добавлении позиции в документ (например, в чек) нужно сначала создать новую позицию DocumentLine, присвоить ей DocumentId и добавить в коллекцию DocumentLines у документа.
Для сохранения данных в базу данных можно использовать метод SaveChanges() контекста базы данных Entity Framework после добавления всех необходимых объектов.
Чтобы иметь одну таблицу для всех документов (чек, возврат, накладная), можно использовать подход Table Per Hierarchy (TPH) или Table Per Type (TPT) в Entity Framework, в зависимости от конкретных требований предметной области.
Таким образом, подход Code First позволяет реализовать классы из Domain-Driven Design для работы с базой данных, обеспечивая согласованность между бизнес-уровнем и базой данных.