Я использовал бы ORM, если я использую Хранимые процедуры?

По моему опыту, я бы позволил ORM обрабатывать операции 'CRUD', а специализированную работу оставил бы хранимым процедурам. Как правило, использование хранимой процедуры для операций «CRUD» является излишним, и если позволить ORM обрабатывать ее, можно значительно повысить вашу производительность.

Да, вы можете, все основные ORM поддерживают хранимые процедуры.

Что касается вашего предположения, вы особенно правы, когда вы используете хранимые процедуры с ORM, вы связываете свой проект с конкретным база данных. Но на практике на 99% вам не нужно будет менять поставщика базы данных, поэтому в этом случае вы используете ORM не для абстрагирования от конкретного поставщика БД, а для того, чтобы помочь себе с задачей объектно-реляционного сопоставления, что является основной задачей ORM. и для которой изначально был создан ORM.

Здесь возникает интересный момент.

Если у вас есть ORM и относительно простые запросы, зачем вам нужны хранимые процедуры? SP тесно связаны с базой данных. ORM освобождает вас от необходимости поддерживать много кода, специфичного для БД. То, что специфично для БД, можно изолировать и управлять.

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

Используйте база данных для того, что у нее получается лучше всего - для хранения данных.

Используйте свое приложение для того, что у него лучше всего - обработки данных.

Yes you can but you will want to spend some time investigating what capabilities the ORM provides around stored procedures.

Most will allow you to run a stored procedure that returns a strongly typed object / entity. More advanced ORM's will allow you to plug stored procedures in for performing CRUD actions as well (so your generic querying, deleting etc goes via a stored procedure rather than a dynamic query).

Generally ORM's are great for generating ad-hoc queries and getting strongly typed entities but having strong stored procedure support has the benefit of allowing you to (sometimes) more easily access native capability of your RDMS that may not be exposed as first class citizens in the ORM - especially if the ORM supports many database engines.

Following up from your edit:

Often you will want to use the ad-hoc querying engine provided by the ORM however as I alluded to earlier - sometimes you want to query using a capability not exposed from the ORM.

The benefits of strongly typed entities is invaluable as it means you have domain object usually, rather than data readers, data tables etc. You can cleanly encapsulate behaviors and logic within those entities that you have retrieved.

The list of additional benefits is very long indeed - for example, with the LightSpeed ORM (and most others) your entities will support standard binding interfaces, error reporting interfaces, validation etc. On the querying side you will lose out on lazy loading etc unless you write it yourself.

"Агностичность" базы данных (?) - не единственная причина для использования ORM. Однако вы можете воспользоваться независимостью от БД в 99% ваших взаимодействий с БД, а в 1% (или 2%, 10% или что-то еще) вам могут потребоваться хранимые процедуры для скорости / ясности / сложности. Если вы изменили БД, вам придется их переписать.

Я часто использую netTiers на работе, и мы позволяем ему генерировать наши хранимые процедуры для нас. Они обрабатывают только основные операции CRUD, но они очень быстрые и экономят мне ТОННУ времени. netTiers также позволит нам создавать собственные хранимые процедуры и генерировать наш код доступа к данным с этими процедурами.

Можно, но многие из более продвинутых функций ORM становятся более громоздкими в использовании. Что-то вроде iBatis очень легко интегрировать с хранимыми процедурами, в то время как более сложные функции более сложных механизмов, таких как (N?) Hibernate, такие как генерация динамического SQL и отложенная загрузка больших полей, могут стать более сложной задачей чем они стоят.