Действительно ли ORM подходит для сложных проектов? [закрытый]

ORM . по определению, это объектно-реляционное отображение.

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

Объекты могут предоставлять некоторые методы, которые могут включать обработку данных и поиск других объектов.

Здесь начинаются проблемы.

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

Сравните это:

MyAccount->Transactions()->GetLast()

Это может быть реализовано двумя способами:

SELECT  *
FROM    Accounts
WHERE   user_id = @me

в $ MyAccount

, затем

SELECT  *
FROM    Transactions
WHERE   account_id = @myaccount

в массиве на стороне клиента @Transactions

, затем $ Transactions [-1] , чтобы получить последнее.

Это неэффективный способ, и вы заметите это, когда получите больше данных.

В качестве альтернативы, умный ORM может преобразовать его в такой:

SELECT  TOP 1 Transactions.*
FROM    Accounts
JOIN    Transactions
ON      Transactions.Account = Accounts.id
WHERE   Accounts.UserID = @me
ORDER BY
        Transactions.Date DESC

, но он должен быть действительно умным ORM .

Таким образом, ответ на вопрос «использовать ли ORM или нет» является ответом на вопрос «позволит ли мой ORM выполнять операции, основанные на наборах, для база данных в случае необходимости "?

Иногда на этот вопрос сложно ответить. Возможно, вы слышали о объектно-реляционном несоответствии импеданса раньше; это проблема, которую инструменты ORM пытаются решить, но она чревата проблемами. Это одна из тех ситуаций, когда вы можете решить 90% проблемы за очень короткое время, но каждый дополнительный 1% с этого момента, кажется, экспоненциально возрастает в сложности из-за всех зависимостей.

Фреймворк ORM является абстракцией и становится дырявой абстракцией в нескольких точках:

• Сложные запросы / сценарии, включающие такие концепции, как UDT, CTE, подсказки запросов, временные таблицы, оконные функции и т. Д.

• Оптимизация производительности запросы. Как упомянул Куассной в своем ответе, ORM становятся лучше в этом, но часто генерируют неоптимальные запросы, а иногда эффект очень заметен.

• Управление транзакциями - шаблон «Единица работы» может помочь вам только тогда, когда вам нужно иметь дело с большими пакетными обновлениями.

• Действия между базами данных или серверами. Есть обходные пути, но это всего лишь обходные пути. Ни один ORM, который я видел, действительно хорошо справляется с этим.

• Многотабличное наследование - это единственная форма наследования, которая на самом деле нормализована, и на самом деле не так уж сложно управлять с использованием чистого SQL и ручного сопоставления, но сопоставители O / R плохо справляются с Это. Для многих из нас наследование одной таблицы не является приемлемой альтернативой.

Это некоторые из многих областей, в которых O / R-картографы, кажется, подводят нас. Сказав это, это не означает, что O / R Mappers не подходят для больших проектов.

На мой взгляд, ORM в целом и O / R Mappers в частности почти жизненно важны для больших проектов. Они экономят огромное количество усилий и могут помочь вам выпустить приложение за долю того времени, которое вам потребовалось бы в противном случае. Они просто не решают всей проблемы . Вы должны быть готовы профилировать свое приложение, чтобы увидеть, что на самом деле делает ORM, и вы должны быть готовы вернуться к чистому SQL, когда этого требует ситуация (то есть в некоторых из вышеперечисленных ситуаций).

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

Я думаю, что лучший ответ на этот вопрос: Да, они подходят для больших проектов, если вы не полагаетесь исключительно на них. Знайте пределы своего выбора инструмента ORM, используйте его для экономии времени в 90% случаев, когда это возможно, и убедитесь, что вы и ваша команда понимаете, что на самом деле происходит под капотом в тех случаях, когда утечки абстракции.

Это субъективно. Мой ответ конкретно об автоматизированных инструментах ORM.

У меня есть философские возражения против ORM Tools по следующим причинам:
1- Таблица не является и не обязательно должна быть взаимно однозначным отображением бизнес-объекта.
2- Базовый код CRUD / бизнес-объекта писать скучно, но он важен для вашего приложения. Я бы предпочел держать все под контролем и знать об этом. (небольшой синдром NIH)
3- Новому разработчику будет легче изучить традиционную объектную модель по сравнению с каким-либо странным синтаксисом, созданным инструментом ORM.

Вы не упоминаете, какую платформу вы используете, но если бы я хотел прочитать запись из базы данных в .NET без использования ORM, я бы необходимо:

1. Прочитать строку соединения
2. Открыть соединение с базой данных
3. Открыть объект Command для соединения
4. Прочитать мою запись (путем выполнения оператора SQL для объекта Command)
5. Преобразовать эту запись к объекту на моем выбранном языке
6. Закрыть мой запрос
7. Закрыть мое соединение

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

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

Проблемы производительности обычно переоцениваются. Она обычно находится в другом месте, чем вы ожидаете. У нас был крутой слой абстракции, написанный на Python, и он отлично работал. Что было плохо, так это библиотека url, которую нам пришлось переписать на C. Действительно, вы всегда можете оптимизировать запросы, которые наиболее важны в конце, написав SQL вручную в тот момент, когда вы видите, что производительность требует этого. Но в большинстве случаев - вам не придется этого делать.

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

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

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

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

http://www.youtube.com/watch?v=uFLRc6y_O3s

Самая последняя тема, которую обсуждает Джош Беркус, - «Сбежавший ORM». Проверьте это в 37:20.