Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _Case, Вы писали:

_C>>Entity Framework полезен когда нужно работать с локальной embedded базой (SqLite, SQL Compact) в desktop приложении, потому как писать inline SQL код (в C# классах) не очень удобно и чревато ошибками типа — забытой кавычки, а хранимых процедур в таких встроенных движках баз нет, а для WEB согласен, на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)
S>Facepalm. Вы просто не умеете готовить батчи.
S>Хранимки к перформансу не имеют почти никакого отношения.

Хорошо, а если рассмотреть следующую ситуацию — допустим пользователь по нажатию кнопки на сайте запускает некую сложную (не просто MERGE / UPDATE) процедуру пересчета данных за определенный период времени, например за месяц, алгоритм может использовать большое количество (десятки — сотни тысяч записей) из нескольких таблиц, если это реализовать хранимой процедурой (даже если в ней будут использоваться и курсоры и ещё что-то) — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..

ещё пример сложные отчеты — по моему опыту через ORM сложный отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое кол-во времени..

Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с поток SQL от ORM nтак просто не разберешься..

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _Case, Вы писали:

_C>>Entity Framework полезен когда нужно работать с локальной embedded базой (SqLite, SQL Compact) в desktop приложении, потому как писать inline SQL код (в C# классах) не очень удобно и чревато ошибками типа — забытой кавычки, а хранимых процедур в таких встроенных движках баз нет, а для WEB согласен, на хранимках сайт работает гораздо быстрее (при работе с MSSQL Server IMHO на порядки)
S>Facepalm. Вы просто не умеете готовить батчи.
S>Хранимки к перформансу не имеют почти никакого отношения.

Хорошо, а если рассмотреть следующую ситуацию — допустим пользователь по нажатию кнопки на сайте запускает некую сложную (не просто MERGE / UPDATE) процедуру пересчета данных за определенный период времени, например за месяц, алгоритм может использовать большое количество (десятки — сотни тысяч записей) из нескольких таблиц, если это реализовать хранимой процедурой (даже если в ней будут использоваться и курсоры и ещё что-то) — то будет просто запрос на базу вида: EXEC [ProcessDataForMonth] а если эту же задачу реализовывать средствами Entity Framework то придется сначала вытащить все эти сотни тысяч записей на BackEnd сервер, отпроцессать их, и затем сохранить снова в базу — это же займет больше времени чем сделать это всё на месте — внутри DB сервера, не гоняя данные по сети..

Ещё пример сложные отчеты — по моему опыту через ORM сложный отчет (хотя бы 7-8 джойнов) будет строиться неприлично большое кол-во времени..

Эта тема конечно о производительности EF, но процедуры я люблю именно за то что понятно что вызывается — запустил SQL профайлер и ясно какая страница что делает, а с потоком SQL-а от ORM так просто не разберешься..