Что я должен использовать для доступа к данным, чувствительным к производительности?

Question

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

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

Мы 'Мы видели Entity Framework, но после некоторых исследований кажется, что преимущества ORM, который он дает, недостаточно для оправдания более низкой производительности, и, поскольку некоторые наши запросы становятся сложными, я уверен, что производительность с EF станет большепроблема.

То есть это случай с нашими текущими методами доступа к данным, или есть что-то более аккуратное, чем ручное создание и поддержка сущностей?

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

Любые идеи, комментарии и предложения оченьоценили!:)

Спасибо,

Энди.

** Обновление **

Забыл упомянуть, что нам действительно нужно уметь работать с помощью Azure (требования клиента), что в настоящее время не позволяет нам использовать хранимые процедуры.** Обновление 2 ** На самом деле у нас есть интерфейсный уровень для нашего DAL, что означает, что мы можем создать реализацию Azure, которая просто переопределяет методы доступа к данным из локальной реализации, которые не подходят для Azure, поэтому я предполагаю, что мы могли бы просто использовать хранимые процедурыдля чувствительных к производительности локальных баз данных с EF для облака.

Answer 1

Я бы использовал уровень ORM (Entity Framework, NHibernate и т. Д.) Для управления отдельными объектами.Например, я бы использовал слои ORM / entity, чтобы пользователи могли редактировать объекты.Это потому, что думать о ваших данных как об объектах концептуально проще, а ORM позволяют довольно просто кодировать эти вещи, даже не программируя SQL.слой ORM.Вероятно, я бы создал отдельную библиотеку классов специально для стандартных отчетов, которая сама создает операторы SQL или вызывает sprocs.ORM на самом деле не предназначены для массовых отчетов, и вы никогда не получите такую ​​же гибкость запросов через ORM, как с помощью кода SQL, написанного вручную.

Answer 2

Не исключаю, старый добрый ADO.NET. Возможно, он не такой модный, как EF4, но он просто работает.

С ADO.NET вы знаете, как будут выглядеть ваши SQL-запросы, потому что вы получаете 100% контроль над ними. ADO.NET заставляет разработчиков думать о SQL, а не прибегать к ORM, чтобы творить чудеса.

Если производительность высока в вашем списке, я бы неохотно взял зависимость от любого ORM, особенно EF, который является новым на сцене и очень сложным. ORM ускоряет разработку (немного), но затруднит прогнозирование производительности ваших SQL-запросов, и в большинстве случаев будет медленнее, чем вручную / хранимые Procs.

Вы также можете выполнить модульное тестирование SQL / Stored Procs независимо от приложения и, таким образом, выделить проблемы с производительностью, связанные либо с БД / запросом, либо с приложением.

Полагаю, вы уже используете ADO.NET в своем DAL, поэтому я бы посоветовал потратить время и силы на его рефакторинг, а не выбрасывать его.

Answer 3

Вы можете попробовать использовать mybatis (ранее известный как ibatis).Позволяет сопоставить операторы SQL с объектами домена.Таким образом вы сохраняете полный контроль над выполнением SQL и в то же время получаете четко определенную модель домена.

Answer 4

Хранимые процедуры для исполнения. ОРМ для простоты разработки

Считаете ли вы возможным устранение неполадок с непрозрачным генерируемым SQL, когда он работает плохо ...? Это создает несколько поездок туда и обратно, где можно было бы сделать? Или настаивает на использовании неправильных типов данных?