Существуют ли передовые практики для сериализации графов объектов с использованием WCF?

Question

Я использую WCF с Entity Framework v4 и использую объекты POCO. Наши организации имеют большое количество связанных организаций. Один объект может иметь много дочерних объектов различного типа, а затем, в свою очередь, множество дочерних объектов разных типов. Например, автомобиль имеет 1 или много водителей. У каждого водителя 0 или много детей. У каждого ребенка тогда есть 0 или много друзей. (Бедный ребенок с 0 друзьями). Пример немного сумасшедший, но вы понимаете, в чем дело.

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

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

• Есть ли лучшая практика, когда дело доходит до SOA?
• Должны ли это быть только непосредственно связанные объекты?
• Есть ли какое-то соглашение об именах?
• Должны ли мы использовать разные методы, например, GetCar () и GetCarWithDrivers ()?

Answer 1

Я не думаю, что есть какое-то эмпирическое правило, и мне не нравится идея возврата данных, которые не нужны клиенту. Ваш дизайн сервиса должен зависеть от бизнес-функциональности, предоставляемой клиентам. Поэтому, если вы ожидаете, что клиенту часто понадобится только Автомобиль, вам следует определить операцию, которая будет возвращать только Автомобиль. Если клиенту иногда также может понадобиться Car with Drivers, вам нужно определить вторую операцию, которая вернет Car with Drivers.

Если ваш сервис работает в основном как CRUD высокого уровня, тогда может быть разумно вернуть хотя бы первый уровень связанных объектов, но опять же, это только обобщение, основанное на предоставленной функциональности. Другим полезным методом могут быть агрегаты. В совокупности связанная сущность не имеет смысла без родительской сущности. Например, Автомобиль с Водителем не является совокупным, потому что Водитель - это отдельная сущность. Но Invoice и InvoiceLine являются совокупными, потому что вы не можете определить InvoiceLine без Invoice. В этом случае может быть полезно вернуть Invoice со всеми InvoiceLines. Опять же, это не так во всех ситуациях. Я работал над приложением подтверждения, где пользователям было разрешено просматривать и утверждать только заголовок Invoice и InvoiceLines из своего центра затрат, поэтому, если Invoice содержал более 50 InvoiceLines, но пользователю было разрешено видеть только одну строку, не было причин для их передачи.

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

Answer 2

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