Давайте рассмотрим простой пример. Скажем, у вас есть приложение, которому требуется отслеживать заказчиков и сделанные ими заказы. Вы хотите создать форму, на которой находятся две сетки: одна показывает список заказчиков, другая список заказов, ассоциированных с заказчиком, выбранным в первой сетке. Это стандартный сценарий привязки данных вида ведущий-детализация, но вы хотите, чтобы он поддерживался не наборами данных, а специальными рабочими объектами. Прежде всего вам нужно определить типы специальных рабочих объектов, которые будут содержать данные приложения, как показано в листинге 9.1.

В данном случае объекты Customer содержат свойства CustomerName и Customerld, а также свойство Orders, которое содержит коллекцию заказов, ассоциированных с заказчиком. Обратите внимание, что свойство Orders класса customer доступно только для чтения. Обычно, если ваш класс инкапсулирует коллекцию, вы захотите управлять ее жизненным циклом внутри класса. Когда коллекция экспонируется через ссылку, в данном случае List<0rder>, пользователи класса Customer легко могут обращаться к коллекции Orders, добавлять к ней ссылки на объекты Object и в принципе использовать любые элементы открытого API класса List<0rder>. Однако поскольку это свойство класса Customer допускает только чтение, они не могут заменить эту коллекцию новой (что могло бы привести к ненамеренной потере информации о заказах) или установить ссылку на коллекцию в null (что могло бы нарушить определенные предположения, которые делает код класса Customer относительно переменной mOrders - что она всегда содержит действительный экземпляр коллекции).

Объекты Order состоят из номера заказа Orderld, даты OrderDate и наименования продукта ProductName. Они содержат также обратную ссылку на объект Customer, которому принадлежат. Поскольку вы имеете дело с объектными ссылками, а не экземплярами данных, которые они содержат, ничто не мешает вам поддерживать ссылки в обоих направлениях - от родителя к потомкам и от потомка к родителю, как делается в этом примере. Такой тесной сопряженности между объектами Customer и Order иногда стараются избегать, но она имеет смысл, если вам часто требуется переходить от родителя к потомкам и от потомков обратно к их родителю. Это аналогично двусторонним переходам, обеспечиваемым DataRelation в связанных таблицах набора данных.

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