Каков наилучший подход к работе с графами объектов на разных уровнях / уровнях? - PullRequest
Новая
       0

Каков наилучший подход к работе с графами объектов на разных уровнях / уровнях?

1 голос
/ 08 января 2011

У нас есть типичная многоуровневая архитектура.Приложение + Служба WCF + Репозиторий / EF4 / База данных.

Мы используем настраиваемую версию шаблона EF POCO T4 для создания наших объектов, которые мы используем на всех уровнях / уровнях.Мы решили не использовать DTO из-за дополнительного времени / работы.

Примером объекта может быть лес, который может иметь навигационные свойства деревьев, которые могут иметь навигационные свойства листьев.

Каков наилучший подход для добавления листьев и работы с графом объектов?Данные импортируются со стороны клиента, поэтому мы не обязательно знаем, существует ли родительский лес / дерево в базе данных.

  1. Служба запросов и получение любых существующих связанных объектов.Прикрепите график для связанных объектов или создайте новые объекты и прикрепите график на стороне клиента.пример: public Forest GetForest (string forestid) затем --- public void AddLeaf (Leaf leaf)

  2. Создайте объекты леса, дерева и листа на стороне клиента и прикрепите графики.Отправьте конечный объект и затем на стороне сервера выполните логику, чтобы сравнить объекты с существующими объектами в базе данных.При необходимости удалите графики, добавьте несуществующие элементы и / или прикрепите к существующим объектам.пример: public void AddLeaf (Leaf leaf)

  3. Создайте объекты леса, дерева и листьев на стороне клиента, но не прикрепляйте графики.Отправьте объекты поперек, а затем на стороне службы выполните логику для сравнения объектов с существующими объектами в базе данных.Добавить элементы, которые не существуют и / или прикрепить к существующим объектам.пример: public void AddLeaf (Листовой лист, Дерево, Лесной лес)

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

Примечание. Клиентское приложение - это служба Windows, которая импортирует данные ... так что это не обязательно легкий клиент.(Мы не обязательно боимся добавлять в него логику.)

1 Ответ

1 голос
/ 08 января 2011

У меня был похожий вопрос несколько месяцев назад. После того, как я много поигрался с этой проблемой, мое окончательное решение - использовать ваше третье решение (мой клиент всегда веб-приложение). Это решение требует написания большого количества кода и включает в себя несколько дополнительных запросов к базе данных, потому что каждый раз, когда вы хотите обновить ваши объекты, вы должны сначала загрузить весь граф объектов. Причина этого заключается в том, что при работе с отсоединенными объектами вам приходится иметь дело с отслеживанием изменений вручную .

Когда вы используете третье решение, вы также можете задействовать DTO и передавать только действительно необходимые данные между клиентом и сервером.

В случае statefull клиента (приложение для Windows, написанное на .NET или, возможно, Silverlight) вы также можете использовать сущности самообследования и ваш первый подход. Самостоятельно отслеживаемые объекты являются реализацией шаблона Changeset. Они могут отслеживать все изменения после отсоединения от контекста, но вы должны сначала загрузить свои объекты из БД. Самостоятельно отслеживаемые объекты не являются хорошим выбором в случае клиента веб-приложения или службы, используемой не клиентом .NET.

...