RAVen42 monstrU , 16760595
МСУ , например берем класс RootObject из Вашего примера.
У меня есть 2 процедуры на сервере:
1) возвращает: ID, name, address
2) возвращает: ID, hobbies

Как сделать JOIN данных из этих 2-х процедур по ID, чтобы записать данные в класс RootObject
Или это вообще по другому делается?

Если не сложно можно простой пример?Простой пример - это сначала заполнить спискок List<RootObject> данными из первой процедуры, а потом в цикле, или при первом обращении к свойству hobbies (Lazy), заполнить последнее данными из второй процедуры.

Также RootObject может реализовывать так называемый шаблон Proxy, и при обращении к свойству hobbies, всегда дёргать хранимую процедуру.

Но всё это не имеет никакого отношения к JSON и Web API.
Конвертацию модели в JSON в Web API выполняет соответсвующий formatter, которму абсолютно по фигу, каким образом была заполнена модель, которую необходимо преобразовать в JSON.

RAVen42, EF лишь формирует запрос на языке T-SQL за Вас и отправляет серверу на выполнение.
Напишите-ка то, что хотите в виде одного запроса (в виде одной хранимой процедуры).

По какому полю Вы собрались JOIN-ить результаты хранимых процедур?

Зачем вообще использовать хранимые процедуры? Нельзя-ли написать запрос, или представление (VIEW)?

RAVen42авторПо какому полю Вы собрались JOIN-ить результаты хранимых процедур?
по полю ID
Могу написать и в виде одной процедуры, например в поле hobbies , будет строка с перечислением "reading,cinema,sports "

skyANAЗачем вообще использовать хранимые процедуры? Нельзя-ли написать запрос, или представление (VIEW)?
1) Преследую цель по максимуму логику сделать на сервере, чтоб не переделывать фронт-енд.
2) НА T-SQL значительно проще и удобней написать и поддерживать МЕГА запрос, нежели писать его в коде.
3) View не вариант, слишком много ограничений для моего случая( временные таблицы, функции и т.д....)

Весь вопрос как легко и красиво сделать из данных возвращаемых процедурой JSON сложной структуры.Легко и красиво - это сформировать запрос с нужными JOIN-ами, выполнить его, а результат замапить в набор объектов, что formatter превратит в JSON.
Собственно, что и делает ORM.

Но в Вашем случае почему-то запрос составить нельзя. А в ORM нет чудесных механизмов для объединения двух хранимок в одну в одном запросе.

Пишите ещё одну хранимую процедуру, что будет вызывать первые две, объединять (JOIN) результаты по полю ID, и возвращать.
И используйте её: Data read using Stored Procedure .

P.S.: а от использования МЕГА запросов, временных таблиц и функции при выборке данных можно и избавиться.

CalabongaА если первая процедура вернет 10000 записей? эт чтож дергать 10000 раз 2-ую процедуру?
А еще некоторые используют пейджинг...:)В контексте Web API, для выборки 10000 записей из базы, зачем он нужен?
Ну хочет потребитель получить все 10000 записей от вашего API, флаг ему вруки. Захочет ограничить выборку, сформирует другой запрос в формате OData.

RAVen42когда при выборке используется куча функций, да при этом ещё и с десяток линкованых серверов со своими процедурами и таблицами и т.д.
Как Вы себе представляете писать этот запрос, состоящий из 1000+ строк в коде?Очень просто: вызвать всю эту "куча функций, да при этом ещё и с десяток линкованых серверов со своими процедурами и таблицами" при добавлении данных,
а при выборке тупо вернуть готовый результат запросом вида: SELECT Column1, Column2, ..., ColumnN FROM Table.

Интересно, сколько по времени у Вас выполняется такая хранимая процедура? Что будет при нагрузке скажем в 20 запросов в секунду?

RAVen42Допустим вернула у меня процедура такие данные:

ID|name| hobbies |address |
1 | Doe | reading,cinema,sports | ABC |

Что мне написать в коде чтоб результатом был JSON

Хм, что-то вроде этого:


При этом в классе Startup прописать:

RAVen42skyANA,
т.е. благодаря именно этому



у меня получится JSON сложной структуры?Нет. Разве из кода не понятно, что происходит?

RAVen42авторОчень просто: вызвать всю эту "куча функций, да при этом ещё и с десяток линкованых серверов со своими процедурами и таблицами" при добавлении данных,
а при выборке тупо вернуть готовый результат запросом вида: SELECT Column1, Column2, ..., ColumnN FROM Table.

skyANA, понимаете эта вся куча функций ... это один единый запрос, где таблицы связаны между собой юнионами, джоинами, потом транспонированы, и другие преобразования я вот ни как не могу понять зачем этот много-строчный запрос пихать в код программы?
Когда можно обойтись простым Exec в одну строчку.А я и не предлагаю "много-строчный запрос пихать в код программы", читайте внимательно.

RAVen42Интересно, сколько по времени у Вас выполняется такая хранимая процедура? Что будет при нагрузке скажем в 20 запросов в секунду?
При правильном написании, и достаточных мощностях сервера, такая процедура выполняется за доли секунд.
К тому-же процедуры имеют планы и статистики, которые значительно ускоряют её работу.
Но это уже совсем другая история :)То есть конкретных показателей у Вас нет, только предположения. Не очень хорошо.

Планы и статистики-то имеются, но также имеется и такая штука как parameter sniffing, когда планы и статистики летят в трубу.

RAVen42skyANA,
авторНет. Разве из кода не понятно, что происходит?
Если честно, то не совсем понятно.JsonFormatter сам преобразует IEnumerable<Person> в JSON.
Я лишь сказал ему: "Писать имена свойств с маленькой буквы и использовать отступы".

RAVen42авторА я и не предлагаю "много-строчный запрос пихать в код программы", читайте внимательно.
т.е. типа витрины данных сделать, да можно и так.Нет, просто шаблон "Денормализация" использовать.

RAVen42авторТо есть конкретных показателей у Вас нет, только предположения. Не очень хорошо.
пока что нет, так-как я только разбираюсь с самим процессом.

авторПланы и статистики-то имеются, но также имеется и такая штука как parameter sniffing, когда планы и статистики летят в трубу.
SQL я знаю очень хорошо Странно, с одной стороны SQL знаете хорошо, с другой стороны конкретных показателей у Вас нет.
Ну да ладно, если знаете хорошо, то разберётесь в производительности.