Когда использовать объекты передачи данных и наборы данных

Question

Я пытаюсь найти методологию, когда использовать объекты передачи данных и когда использовать таблицы данных.

В качестве примера проблемы, с которой я сталкиваюсь в нашей системе ...

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

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

Служба данных 1 Заполняет

• Марка
• Цвет

Служба данных 2 заполняет

• Gears

• Размер шин

и каждый использует свой бизнес-объект. Очевидно, это смешно, вы не можете создавать новый класс для каждой возможной комбинации свойств.

Мои интуитивные ощущения говорят мне, что если это проблема, то, вероятно, нам следует использовать ORM.

Но пока я хочу сказать.

• Если вы заполняете или возвращаете всю строку из таблицы, используйте DTO / Business Entity, соответствующий базе данных.

• Если вы возвращаете случайный набор свойств, используйте таблицу данных.

Может ли кто-нибудь предложить какое-нибудь руководство?

Спасибо

Answer 1

Это будет зависеть от размера системы, о которой мы говорим. Если это действительно отдельные системы, то понятно, что они работают с разными способами просмотра одной и той же концепции. Это называется ограниченным контекстом: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html

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

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

Answer 2

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

Answer 3

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

Теперь, с другой стороны, также нет причин не стандартизировать общее определение "Велосипед". Если служба данных 1 хочет обновить только марку и цвет, она может иметь операцию UpdateBrandAndColor. Ему не нужно передавать всю сущность, только ее идентификатор, марку и цвет. То же самое с #gears и размером шин.

Но должен быть только один тип сущности Bicycle, возвращаемый из операции GetBicycle.