Является ли круговая ссылка между бизнес-объектами (в иерархии) общей?

Question

Классы Linq-to-Sql дают как родителю ссылку на дочернюю коллекцию, так и потомку ссылку на родителя (одиночную или коллекцию).Это позволяет «сверлить» в обоих направлениях , и кажется довольно удобным.

Является ли этот дизайн подходящим для использования вручную созданных бизнес-объектов (POCO или других)?В случае;Каковы будут плюсы / минусы или конкретные ситуации, когда это будет рекомендовано?

---

EDIT1:

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

Answer 1

Не уверен, что это действительно тот ответ, который вы ищете, но вот мои 2 цента.

Циркулярные ссылки - это ужасный дизайн базы данных, которого следует избегать любой ценой.

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

Примером этого может быть что-то вроде:

class Company
{
  Person ContactPerson {get;set;}
}

class Person 
{
  Company Company {get;set;}
}

Здесь вы буквально сталкиваетесь с проблемой 22 (или проблемой куриного яйца) при работе с базами данных.

Однако работа с ним в коде не является большой проблемой.

Answer 2

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

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

Answer 3

Да, двунаправленные ссылки распространены и полезны. Они идеально подходят для объектно-ориентированных архитектур. Как вы указали, преимущества: они помогают вам моделировать ваши доменные объекты и эффективно обходить указанные объекты. С другой стороны, они могут усложнить понимание вашего кода, поскольку существует больше путей прохождения информации.

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

Answer 4

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

• Хранение в РСУБД - согласно Леппи. Для отношений один ко многим, Родительский ФК хранится на Ребенка записей. Для одного к одному отношения, хранить отношения другой как FK, но только в одну сторону.
• Сериализация через проводную банку также вызывают серьезные головные боли. Как правило, в один ко многим отношения, дети вложены под родителем (отношения сохраняются иерархией). Однако если дочерняя сущность имеет ссылку на родитель, родительский объект ссылка обычно не помечена как Сериализуемый, из-за рекурсии (циклов). (PreserveObjectReferences Хотя в WCF 3.5+ эта проблема уже решена с помощью (IsReference = true)).

В любом случае, ссылки на двунаправленные отношения должны быть «исправлены» после регидратации графа от хранения / десериализации. (посмотрите на код, сгенерированный Linq2Sql)