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

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

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

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

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

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

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

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

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

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

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

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