Стоимость выполнения ORM

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

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

Производительность всегда была второстепенной задачей при разработке / архитектуре большинства DAL Layer. Я думаю, что пора нам начать подвергать сомнению производительность этих инструментов ORM из-за так называемой простоты разработки, которую они обещают:

Две самые большие проблемы с производительностью в ORM:

1. Невозможность писать Оптимальный SQL. Вы должны использовать язык объектных запросов, который интерпретируется платформой в SQL. В основном это хороший SQL, но довольно часто это не самый эффективный SQL.

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

Другие проблемы с производительностью возникают из-за неэффективного проектирования базы данных или модели сущностей из-за тесной связи объектов сущностей с таблицами.

Это также зависит от того, что вы используете в качестве ORM. По моему опыту, Hibernate - настоящая свинья с точки зрения скорости, использования ресурсов и времени запуска. LINQ to SQL, с другой стороны, представляет собой чрезвычайно легкую оболочку SQL, влияние которой вы, вероятно, почти не заметите (если вообще заметите).

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

Производительность - всегда за и против. Если вы углубитесь в архитектуру ORM (см. Мою статью: избегайте вредных привычек ORM), тогда вы интуитивно найдете способы сделать это быстрее. Вот еще одна моя статья о том, как сделать EF6x в 5 раз быстрее (по крайней мере, для ситуаций чтения): EF6.x в 5 раз быстрее

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