Как сохранить сгенерированное сервером сложное дерево объектов с сущностями, которых еще нет в базе данных?

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

"ComplexObjectTree" НЕ обязательно должен быть графом сущностей. Это может быть произвольный объект данных. Это все еще может быть тип CLR, но он не будет (или не будет содержать) объекты, описанные в метаданных, и они не будут известны EF или Db. Этот граф объектов существует просто как информация, которая управляет построением реального графа сущностей на клиенте. В нем есть все трудно поддающиеся расчету значения, которые вы не хотите рассчитывать на клиенте ... например, ответ на вопрос о смысле жизни и о том, кто выиграет Суперкубок в этом году.

Ваш запрос возвращает этот объект с данными, но без сущностей. Обратный вызов querySuccess, CreateComplexTree(data), создает граф объекта на клиенте из этих данных.

Граф сущностей будет состоять из сущностей, понятных клиенту Breeze благодаря метаданным. Если у вас нет возражений, эти сущности также распознаются на сервере и готовы к сохранению и запросу, как и любые другие сущности (вы можете обойти это предположение, если оно неверно... но давайте работать над одной проблемой за раз).

Итак, все готово. Вы ходите по графу данных, создавая объекты по ходу дела. Когда вы видите (-1) в данных, вы знаете, что нужно создать новый экземпляр типа. Скопируйте данные в объект инициализации объекта, который является вторым аргументом в manager.createEntity('Foo', {...}). Здесь нет бизнес-логики — нет расчетов — только мартышка копирования.

Я не могу сказать, должен ли быть вставлен КАЖДЫЙ объект в графе или только некоторые из них. Возможно, некоторые из них являются уже существующими сущностями, которые не изменяются, если пользователь их тоже не изменит. Ничего страшного. Вы можете использовать тот же подход для создания «неизменных» объектов на клиенте с помощью строки типа manager.createEntity('Bar', {...}, breeze.EntityState.Unchanged).

Теперь у вас есть правильный граф объектов Breeze, готовый к привязке, навигации и сохранению. Если пользователю нравится именно такой, каким его создал сервер, он нажимает кнопку [Сохранить], Breeze находит все изменения в графе сущностей, и они отправляются на сервер.

Как замечает Брайант, нельзя по-настоящему доверять клиенту. Вы захотите пройтись по графику, чтобы проверить его. Но это верно независимо от вашей методологии.

Надеюсь это поможет.

Обычно вы создаете объекты на клиенте, а не на сервере. Таким образом, сущности являются новыми и будут сохранены в методе сохранения.

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

Поэтому создайте новые объекты на клиенте, а затем вызовите сохранение изменений.

Брайант совершенно прав, таков его ответ. Этот ответ просто для получения разъяснений.

Не совсем уверен, что понимаю вопрос, но просто для ясности: EntityManager не поддерживает несколько сущностей одного типа с одним и тем же «ключом» (т.е. -1 в вашем случае). Он рассматривает все объекты одного типа с одним и тем же ключом как «один и тот же» объект.

Похоже, что вы хотите получить кучу «фальшивых» объектов в entityManager, а затем условно преобразовать несколько из них в «настоящие» новые объекты» и сохранить их, чтобы эти записи были добавлен в базу данных. Это то, чего вы пытаетесь достичь?