Проектное решение: (EF & WCF) Chatty или Chunky?

Question

У меня есть сущность Entity Framework (v4) с несколькими многослойными навигационными свойствами. Это потенциально очень глубокий объект. Результирующий объект может быть небольшим или довольно значительным по размеру. Это никогда не бывает супер-большим; никогда не мегабайт данных или что-либо еще.

Кроме того, я НЕ пытаюсь решить проблему с размером полезной нагрузки или любой ошибкой, которую я получаю. Я просто пытаюсь определить, какое решение лучше всего подходит для такой ситуации.

Давайте назовем мою сущность Entity Framework записью проекта.

Разумнее ли построить метод WCF следующим образом:

public Project GetProject(int projectId) { }

Или вот так:

public Project GetProject(int ProjectId) { }
public Project GetProjectPart1(int ProjectId) { }
public Project GetProjectPart2(int ProjectId) { }
public Project GetProjectPart3(int ProjectId) { }
public Project GetProjectPart4(int ProjectId) { }

Я полагаю, это вопрос Чанки против Чэтти.

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

Answer 1

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

С программной точки зрения, я бы, вероятно, выбрал коренастый вариант без лишних затрат на то, чтобы собрать проект вместе с 4 отдельными вызовами.

Решения, решения.

Answer 2

Вы можете пойти по полпути, имея несколько способов загрузки объекта Project в зависимости от ваших требований: -

LoadProjectLight(int projectId)
LoadProjectFull(int projectId)

Первый будет загружаться только на «верхнем уровне»графа объекта, то есть объекта Project, и последнего, который будет загружать полный объект, используя .Include (), чтобы ввести необходимые части графика.

Вы будете использовать метод Light, когда выТребуется только верхний уровень в зависимости, например, основной список проектов, а затем метод Full, когда вам нужен весь график, например, редактирование объекта в подробном представлении.

Answer 3

Когда я не могу выбрать один из двух способов сделать что-то, обычно это означает, что оба на самом деле полезны. Итак, в качестве компромисса, с точки зрения чистого API, я бы определил это так:

public Project GetProjectPart(int ProjectId, int firstPartIndex, int lastPartIndex) { }

Вы можете решить не реализовывать обработку fistPartIndex & lastPartIndex на начальных этапах вашего проекта, но, по крайней мере, API будет перспективным, что, я думаю, является очень важной частью решения, когда я начну определять публичные сервисы .

Answer 4

Чтобы противопоставить ответ Криса:

Система, которую я помогал собрать, была встроенной системой, взаимодействующей с сервером Windows.Конечно, было бы возможно сделать вещи короче.Однако встроенная система была контроллером доступа, который считывал значки и открывал (или не открывал) двери в зависимости от уровня доступа номера значка.

Если бы мы что-то делали неуклюже, загрузка конфигурации вывела бы двери в автономный режим более чем на минуту.

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

Повторно: решения, решения.