krudensoftСистемы, которые за меня будут генерить запросы - не предлагайте, я знаю TSQL лучше, чем они 8).
Написание CRUD на клиенте тоже малоинтересно, в силу его медлительности.


Хм. Вы точно ORM ищете? Собственно, они и занимаются генерацией CRUD запросов на клиенте.

krudensoft,

ааа, так вы боитесь построчного обращения к БД? Приличные ORM умеют отправлять запросы пакетами, так что предаврительно изучить возможности конкретной ORM.

Далее буду говорить как большой сторонник NHibernate, за него и агитирую. :)

krudensoftИсходные данные: WinForms клиент, MS SQL Server (2005, 2008) .NET 2.0
БД большая (складская программа)

С 2.0 выбор будет сильно огранчен. Ибо его поддержку даже мелкософт прекратила. Может хотя бы на 3.5 перейти? Но может взять старую версию - NH 2.1.1.

krudensoftЗадача следующая:
1. Считать и показать список накладных (100 - 100000 строк);
2. Открыть и отредактировать накладную (шапка + 100-5000 строк товаров) ;
3. Быстро сохранить в одной транзакции эту накладную (шапку и товарку)(система многопользовательская).


1. 100 - это нормально. Но 100000 зачем? И дело даже не в ORM, просто по сети передавать долго будет. Но вот недавно пробовал на NHibernate скорость загрузки проекции из 400к строк. Заняло несколько секунд.
2-3. Насколько быстро можно выполнить этот пункт зависит не только и не столько от ORM. Но если это обычная операция сохранения, то особой разницы по сравнению с обычным TSQL не заметите.

В остальном оптимизация возможна для каждого конкретного случая.

krudensoft,

Наличие ORM предполагает, что ваша бизнес логика и будет на клинете, либо сервере приложений.
Что касается валидации - надо пробовать на ваших данных и базе. Теоретически, загрузить всю необходимую информацию можно за один поход к БД, проверить валидацию на клиенте, и в случае успеха отправить накладную на в БД. На накладую из 100 строк думаю вполне реально получить результат меньше секудны.

Переопределять методы сохранения, загрузки и т.д. можно. Но в этом случае вы потеряте многие возможности ORM связанные с эффективными запросами к БД.

krudensoftТ.е. правильно ли я понял, что вся прелесть ORM в том, что не надо писать запросы?
В первую очередь ORM помогает избавится от рутинного CRUD'а. Особенно для простых сущностей. Всякие справочники и т.д. идут на ура, там где надо более сложная логика - приходится потрудится чуть побольше. Но разве с T-SQL дело обстоит так же. :)

krudensoftУ некоторых клиентов базы данных превышают 450Гб. Используется сегментирование и прочие хитрости, чтобы такие обьемы ворочались достаточно шустро. Делать валидацию на клиенте нереально, т.к. за время закачки результатов валидации и слива данных на скул, валидация может устареть.
Вряд ли вы одиноки в своих проблема насчёт 450Гб. И есть много способов оптимизации в т.ч. при работе с ORM. Устаревать валидация не будет, т.к. загрузка данных, валидация, и сохранение накладной идут в рамках транзакции.

SolYUtorСпасибо за ответы. Получается, под мои задачи ORM не подходят... Ну или надо менять задачи. 8).
Скорее вам придётся кардинально менять способы решения задачи. :)
Ибо ORM"ы заточены под DDD, использует все преимущества неведения о сохранямости, улучшает возможности тестирования и надёжность приложения. Но естественно, не бесплатно, некоторое снижение производительности будет. Насколько сильно - зависит от понимания узких мест, возможностей ORM, и вашего уровня владения им. ;)

МСУkrudensoftИсходные данные: WinForms клиент, MS SQL Server (2005, 2008) .NET 2.0
БД большая (складская программа)
Entity Framework однозначно.

Видимо первый EF, да?

SeVa,

большое спасибо за подтверждение моих слов!

Алексей КBLToolKit ещё можно взять. Впрочем, вызывает сомнение необходимость тягать из/в БД NNNNNN записей.
BLToolKit это конечно не ORM, но явно лучше голого ADO.NET.

EDUARD SAPOTSKI,

Если вы думаете, что обработка накладной - это кинуть в базу шапку и товар, то нужен смайлик чтобы поржать над вами. А то что вы описали на полдня, можно сделать за почаса с ORM'ом.

SeVaЕсли нет графов, то это только какой-то примитивный классификатор, в остальных 99% - сложный граф

Проблемой графов вы не один озадачились. ORM'ы имеют эффективные средства для их загрузки ( или не загруки, it depends).

EDUARD SAPOTSKIГде я такое писал, что я так думаю? Даже если так, а оно так и есть, Вы можете много придумать реальных операций с накладными которые требуют применений нетривиальных алгоритмов? Примеры в студию! Я чето сходу так и не придумаю.

Сложность не в алгоритмах. А в количестве простых действий, которые надо выполнить в рамках одной транзакции.