Буду ли я использовать ORM, если я использую хранимые процедуры?

Question

Если я использую хранимые процедуры, могу ли я использовать ORM?

EDIT:

Если я могу использовать ORM, разве это не разрушает часть причины агностичности базы данных для использования ORM? Другими словами, зачем еще мне использовать ORM, если я привязываю себя к определенной базе данных с хранимыми процедурами (или это предположение неверно)?

Answer 1

Использование ORM для доступа к хранимым процедурам - одно из лучших применений ORM. Это даст вам строго типизированные объекты, в то время как у вас все еще есть полный контроль над SQL.

Answer 2

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

Answer 3

Вы можете одновременно использовать функции ORM и функции хранимых процедур. Особенно используйте ORM, пока он вам не подходит, но если у вас есть проблемы с производительностью или вам нужна какая-то низкоуровневая настройка - включите хранимые процедуры в свою бизнес-логику.

Answer 4

Это поднимает интересный момент.

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

Да, вы можете, но вам захочется потратить некоторое время на изучение возможностей ORM для хранимых процедур.

Большинство позволит вам запустить хранимую процедуру, которая возвращает строго типизированный объект / сущность. Более продвинутые ORM позволят вам подключать хранимые процедуры для выполнения действий CRUD (так что ваши общие запросы, удаление и т. Д. Выполняются с помощью хранимой процедуры, а не динамического запроса).

Обычно ORM отлично подходят для генерации специальных запросов и получения строго типизированных сущностей, но благодаря сильной поддержке хранимых процедур вы можете (иногда) упростить доступ к собственным возможностям вашей RDMS, которые могут не отображаться в качестве первого класса. граждане в ORM - особенно если ORM поддерживает много механизмов баз данных.

В продолжение ваших правок:

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

Преимущества строго типизированных сущностей неоценимы, так как это означает, что у вас обычно есть объект домена, а не считыватели данных, таблицы данных и т. Д. Вы можете чисто инкапсулировать поведение и логику внутри извлеченных вами сущностей.

Список дополнительных преимуществ действительно очень длинный - например, с LightSpeed ​​ORM (и большинством других) ваши объекты будут поддерживать стандартные интерфейсы привязки, интерфейсы отчетов об ошибках, валидацию и т. Д. На стороне запросов вы проиграете из-за ленивости. загрузка и т. д., если вы не пишете это самостоятельно.

Answer 9

Я считаю, что любой инструмент, который освобождает вас от повторной работы и позволяет сосредоточиться на решении проблем, действителен. ORM, кажется, являются тем инструментом, когда дело доходит до базовых операций CRUD - даже если SP используют для лучшего выполнения требования (например, использование молотка по гвоздю, это просто подходящий инструмент для задачи).

Дело в том, что нет черного или белого, только шкала серого. Очень неэффективные и плохо закодированные приложения используют причину «независимости от БД», чтобы объяснить чрезмерное использование ресурсов БД. Во многих случаях быть слишком привязанным к базе данных тоже нехорошо. Цель: получить максимальный «агностицизм в отношении БД», не тратя впустую ИТ-ресурсы клиентов без необходимости.

Нет «старого против нового», просто люди говорят, что экстремальные «чистые» подходы лучше. Я не очень верю в это. Я считаю, что, как и в любом другом инструменте, «лучший» (обратите внимание на кавычки) подход использует ORM до тех пор, пока он не станет подходящим инструментом для доступа к вашим данным. И используйте SP внутри ORM, когда вы достигаете точки, когда вы тратите ресурсы и снижаете масштабируемость и «ценность жизни» (я забыл английский эквивалент выражения для португальского «vida útil») ресурсов TI. Или, другими словами, используйте SP, когда это под рукой, что молоток для гвоздя.

Answer 10

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