Как побудить себя перейти на ORM?

Question

Я работаю с устаревшим проектом моего партнера по команде (.NET / Oracle). Проект еще не завершен, он находится в стадии строительства и далек от производства. Он следовал «традиционному способу» доступа к данным: создание хранимых процедур, а затем использование драйвера базы данных для их вызова. Я хочу следовать «современному способу» доступа к данным: использовать ORM для абстрагирования и доступа к данным. Переключатель не будет стоить дорого, с точки зрения времени и денег. Проблема в том, что он намного опытнее меня и ненавидит ORM (он не объяснил почему, но сказал, что это сбивает с толку). Сейчас я сам по себе, но я не достаточно воодушевлен, чтобы перейти на ORM.

Тогда я должен перейти на ORM или нет? если да, пожалуйста, подбодри меня.

РЕДАКТИРОВАТЬ: Я не знаю, почему кто-то должен закрыть этот вопрос. Я не достаточно воодушевлен, потому что я не уверен, какой путь лучше. Вы можете убедить меня, что ORM заставляют меня развиваться быстрее, меньше ошибок, или хранимые процедуры быстрее ... что угодно. Хочу спросить у вас, какие, имхо, опытные программисты (кроме меня, а также мой напарник). У моего товарища по команде появилась причина использовать хранимые процедуры, и у многих программистов есть свои. Мне нужно знать, почему они так думают (хранимые процедуры очень хороши или они просто хотят использовать что-то подобное с ними и т. Д.)

Большое спасибо.

Answer 1

Вот три причины не переключаться:

1. Oracle PL / SQL - полный язык программирования.Это не просто замороженные операторы SQL и условное программирование.Таким образом, вполне вероятно, что уровень PL / SQL содержит логику, которая не может быть легко реализована в ORM.

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

3. Вы описываете свое приложение как «устаревшее», которое предполагает, что оно находится в производстве.Если это так, изменение архитектуры доступа к данным будет большой потворством.Вы и ваш коллега потратите много времени на написание кода, не говоря уже о регрессионном тестировании всего приложения, с без заметных преимуществ для ваших пользователей .

Answer 2

ORM не являются «современными», они предназначены для минимизации взаимодействия с базой данных до такой степени, что вам часто не нужно писать SQL. Это также то, что вы получаете, используя хранимые процедуры и функции SQL, при условии, что у вас есть команда разработчиков базы данных, которая посвятит себя разработке и обслуживанию.

В ORM все чаще встречается поддержка нативного SQL, потому что они по понятным причинам имеют ограниченную способность обрабатывать сложный SQL. У людей есть проблемы с разработкой SQL, я не ожидаю, что программная абстракция будет лучше ...

«Традиционный способ» более целенаправленный, что делает его более эффективным для выполнения быстрее, чем с ORM. Преимущество ORM заключается в поддержке нескольких поставщиков баз данных без знания тонкостей каждого поставщика или самого SQL.

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

Answer 3

своими словами:

• Ваш напарник намного опытнее
• Вы должны прийти сюда для аргументов для обсуждения
• Ваш товарищ по команде уже имеет рабочее решение
• У вас надвигающийся срок

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

Answer 4

Переход на ORM в этот момент - это действие испорченного ребенка, и если бы вы сделали это в моей команде без моего согласия заранее, я бы уволил вас. Существует много веских причин для использования хранимых процедур, в том числе запрещение доступа к данным на уровне таблиц, что, например, важно для финансовых систем. Желание использовать какой-то другой инструмент, потому что вы хотите изучить его, является детским и непрофессиональным.

ORMS не лучше для многих сложных проблем, они часто создают плохо работающий код, когда все становится сложным. Хранимые процедуры могут быть легко настроены на производительность, что очень важно. Хранимые процедуры обеспечивают лучшую защиту ваших данных, поскольку вы можете ограничить прямой доступ к таблицам и разрешить пользователям выполнять только те задачи, которые определил porc, что снижает вероятность мошенничества. Кроме того, намного, намного проще реорганизовать базу данных, если все запросы находятся в хранимых процессах. Изменения в запросах также проще применять, гораздо проще загрузить один сохраненный процесс proc в prod, чем перекомпилировать и перезагрузить все приложение.

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

Answer 5

Я разделил разницу в прошлом, используя (по-видимому, теперь пылящийся на чердаке) сверхлегкий картограф iBatis , некоторые дополнительные атрибуты в XML-определениях запросов iBatis, указывающие один / несколько результатовустановить поведение и таблицу стилей XSLT, которая считывает определения запросов и выплевывает исходный код для красивого аккуратного класса DAL.

При таком подходе вы можете подключать либо хранимые процедуры, либо прямой SQL.Вы упускаете некоторые из лучших функций современного ORM, такие как поддержка LINQ и кэш в памяти, но у вас также гораздо меньше проблем с преодолением отклонений правила 80/20, которые обычно присутствуют в схеме, которая былаПервоначально не был построен с учетом требований ORM.

Answer 6

Это зависит от того, какой язык вам наиболее удобен и для какой платформы вы разрабатываете. Основываясь на этих критериях, я бы порекомендовал изучить среду MVC, которая заставляет вас использовать хорошие методы ORM. В этом пространстве Ruby on Rails (на основе Ruby) и CakePHP (на основе PHP) отлично подходят для веб-разработки. Хотя структура ZEND менее строгая в отношении ORM, она также очень хороша, если вам нравится PHP. Если вы работаете с MS SQL Server или разрабатываете для настольных ПК, .NET MVC - это путь, который совместим с любым языком .NET.

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

Существует также дополнительное преимущество быстрой разработки приложений (RAD). Очень легко и быстро запустить работающее приложение с большинством сред ORM. Они могут сэкономить много времени в жизненном цикле разработки.

Answer 7

SPROCS никогда не были хорошей идеей, на мой взгляд.

• PL / SQL редко и часто никогда не тестируется автоматически. Он может работать, когда вы реализуете его, но без юнит-тестов, как вы можете быть уверены, что он продолжит работать в будущем без регрессионных тестов. Практика, которую я считаю, что каждый должен принять это TDD. Благодаря дисциплине TDD не позволяет писать код, который не проверяется автоматически при каждой сборке на предмет регрессии. Не поймите меня неправильно, я не советую вам использовать TDD для PL / SQL (я знаю, что это технически возможно). Я предлагаю вам сохранить свой код в своей кодовой базе.
• PL / SQL не облегчает простую отладку. Возможно пройти через SPROCS, но не обычными средствами отладки приложений (особенно не .NET для Oracle; может быть .NET для MS SqlServer).
• Использование логики, специфичной для ядра СУБД, связывает ваше приложение не только с этим поставщиком БД, но и с этой версией БД, а также довольно часто с этой версией драйвера БД. Я был в проекте, который использовал .NET и MS SqlServer, и он был первоначально реализован со многими SPROCS. В конечном итоге заказчик сказал, что не желает оплачивать расходы на лицензирование SqlServer и хочет перейти на движок БД с открытым исходным кодом (конкретнее MySQL). Мы не смогли удовлетворить этот запрос легко, и это просто неприемлемо, когда существует так много фреймворков, которые легко облегчают переключение движка БД без промедления.

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