Дизайн класса: идентификатор объекта против ссылки на объект

Question

Если у меня есть Foo со свойством типа Bar. Оба сохраняются в базе данных, которую можно получить по идентификатору. (Идентификаторы на самом деле используются в бизнес-направлениях заявками на обслуживание клиентов. Поэтому они не просто заполнители индекса.) Я мог бы использовать подход, показанный с помощью b1 или b2.

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

int fooKey = 123;
Foo f = new Foo(fooKey);
Bar b1 = new Bar(Foo.BarID);  //This?
Bar b2 = Foo.Bar;  // Or This?

Примечание. Это НЕ касается .NET Entity Framework. Слово сущность используется здесь в общем смысле.

Answer 1

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

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

Answer 2

Посмотрите, как MSFT реализовал LINQ to SQL. Они позволяют вам установить либо / или. Их картограф достаточно умен, чтобы выставлять как свойства, так и ленивую нагрузку по мере необходимости. IMO, вы должны пойти по простому пути (использовать ID) или использовать O / R Mapper, например, Hibernate / NHibernate, Linq to SQL или Linq to Entities, если вы хотите фантазии.