Как избежать ограничений ORM или их следует избегать?

Question

Короче говоря, ORM, такие как Entity Framework, обеспечивают быстрое решение, но со многими ограничениями. Когда их (ORM) следует избегать?

Я хочу создать движок системы DMS, мне интересно, как я могу создать уровень бизнес-логики.

Я буду обсуждать следующие варианты:

• Использование Entity Framework и предоставление его позже в качестве Business для клиентов механизма.

  Проблема в том, что отсутствует контроль над свойствами и проверка правильности, поскольку генерируется код.

• Создание собственных классов бизнес-уровня вручную без использования Entity Framework или какого-либо ORM:

  Проблема в том, что это сложная задача и что-то вродезаново изобрести weel.

• Создать свои собственные классы бизнес-уровня в Entitiy Framework (используйте его)

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

Правильно ли я обсуждаю проблему?

Answer 1

Короче говоря, следует избегать ORM, когда:

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

• вы используете строго настраиваемые типы данных или преобразования.ORM, как правило, плохо справляются с BLOB-объектами, и существуют ограничения на то, как им можно сказать, как «отображать» объекты.

• вам нужна абсолютная наивысшая производительность при взаимодействии с SQL Server,ORM могут страдать от проблем N + 1 и других неэффективных запросов, и в целом они добавляют слой (обычно рефлексивного) перевода между вашим запросом объекта и оператором SQL, что замедляет работу.

Вместо этого ORM следует использовать в большинстве случаев ведения записей на основе приложений, когда пользователь просматривает агрегированные результаты и / или обновляет отдельные записи, состоящие из простых типов данных, по одному за раз.ORM имеют огромное преимущество по сравнению с необработанным SQL в своей способности предоставлять проверенные компилятором запросы с использованием провайдеров Linq;практически все популярные ORM (Linq2SQL, EF, NHibernate, Azure) имеют интерфейс запросов Linq, который может поймать много «жирных пальцев» и других распространенных ошибок в запросах, которые вы не улавливаете при использовании «магических строк» ​​для формированияSQLCommands.ORM также обычно обеспечивают независимость базы данных.Классические отображения NHibernate HBM представляют собой файлы XML, которые при необходимости можно заменить, чтобы указать хранилище на MSS, Oracle, SQLite, Postgres и другие RDBMS.Даже «плавные» отображения, которые являются классами в файлах кода, могут быть заменены, если они правильно спроектированы.EF имеет аналогичную функциональность.

Answer 2

Отказ от ответственности: Я работаю в Mindscape, который создает LightSpeed ​​ORM для .NET

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

При разработке O / R Mapper важно учитывать то, что мы называем «аварийными люками». ORM неизбежно приведет к определенному набору поведения по умолчанию, что является одним из способов повышения производительности труда разработчика.

Один из уроков, которые мы извлекли из LightSpeed, был о том, где разработчикам нужны эти аварийные люки. Например, KeithS здесь заявляет, что ORM не годятся для массовых операций - и в большинстве случаев это так. У нас был этот сценарий с некоторыми клиентами, и мы добавили перегрузку к нашей операции Remove (), которая позволила вам передать запрос, который удаляет все соответствующие записи. Это избавило от необходимости загружать объекты в память и удалять их. Прислушиваться к тому, что разработчикам не терпится и помогает быстро решить эти проблемы, очень важно помогать в создании надежных решений.

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

В целом вы должны выбрать ORM, который дает вам немедленный прирост производительности (почти в стиле демонстрационной программы «смотрите, я запрашивал данные за 30 секунд!»), Но также обратил внимание на более масштабные решения, где есть аварийные люки и некоторые из менее демо, но нужны чрезвычайно полезные функции.

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

Если вам интересно, вы можете узнать о нашей LightSpeed ​​ORM для .NET .

Answer 3

Итак, вы спрашиваете, как сделать «Х» без «Х»?ORM - это абстракция, и, как и любая другая абстракция, она имеет недостатки, но не те, которые вы упомянули.

• Код (EFv4) можно сгенерировать с помощью шаблона T4, а шаблон T4 - это код, который можно изменить
• Генерируемый код - это частичный класс, который можно комбинировать с вашей частичной частью, содержащей вашу логику
• Написание классов вручную - очень распространенный случай - использование конструктора, доступного в платформе Entity, встречается реже

Answer 4

По моему опыту, вы должны избегать использования ORM, когда ваше приложение выполняет следующие манипуляции с данными:

1) Массовое удаление: большинство инструментов ORM не удаляют данные по-настоящему, они помечают их идентификатором сборки мусора (GC-запись) для обеспечения согласованности базы данных. Хуже всего то, что ORM собирает все данные, которые вы хотите удалить, прежде чем пометить их как удаленные. Это означает, что если вы хотите удалить 1000000 строк, ORM сначала извлечет данные, загрузит их в ваше приложение, пометит их как GC, а затем обновит базу данных ;. я считаю, что это огромная талия ресурсов.

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

3) Генерация отчетов: инструменты ORM хороши для создания простых отчетов списков или простых объединений таблиц, как в сценарии order-order_details. но в большинстве случаев ORM только замедляет извлечение данных и добавляет дополнительные объединения, необходимые для отчета. которые приводят к тому, что они дают больше работы движку БД, чем вы обычно делаете с подходом SQL