Как создать оболочку бизнес-модели для универсального подхода к базе данных?

Question

В настоящее время я сталкиваюсь с проблемой производительности при создании объектов POCO из моей базы данных.Я использую Entity Framework 4 в качестве OR-Mapper.Пока все приложение является прототипом.

Давайте предположим, что я хочу иметь несколько бизнес-объектов, таких как классы «Принтер» или «Сканер».Оба класса наследуются от BaseClass под названием Product.Бизнес-классы существуют.

Я пытаюсь использовать более общий подход к базе данных.Я не хочу создавать таблицы для «Принтер» и «Сканер».Я хочу иметь 3 таблицы: одна называется Product, а другая - Property и PropertyValue (в которой хранятся все присвоенные значения для определенного Product).

На моем бизнес-уровне я создаю определенный объект, подобный этому:

public Printer GetPrinter(int IDProduct)
{
  Printer item = new Printer();
  // get the product object with EF
  // get all PropertyValues
  // (with Reflection) foreach property in item.GetType().GetProperties
  // {
  //   property.SetValue("specific value")
  // }
  return item;
}

Вот так выглядит модель EF:

Пока работает отлично.Сейчас я делаю тесты производительности для извлечения нескольких наборов.

Я создал прототип и улучшил его в несколько раз, чтобы повысить производительность.Это все еще далеко от того, чтобы быть пригодным для использования.Мне нужно 919 мсек, чтобы создать 300 объектов, которые содержат только 3 свойства.

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

Я просто слишком глуп, чтобы создать эффективный способ получения объектов xx, или мой подход полностью неверен?Насколько я понимаю OR-Mapper, они в основном делают то же самое?

Answer 1

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

• Компиляция запроса медленная (вы можете предварительно скомпилировать ее)
• Материализация объекта медленная (вы не можете избежать этого)
• Отражение медленное (вы не можете его избежать)

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

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

Если вы хотите улучшить производительность, определите набор общих свойств и поместите их в Product.Затем либо используйте ваши текущие PropertyValue и Property для дополнительных не общих свойств, либо просто используйте таблицу ExtendedProperties, хранящую пары ключ-значение.Ваши объекты будут иметь тип Product с внутренним типом свойства, общими свойствами и набором расширенных свойств.Это общий подход.

Answer 2

Во-первых, мне непонятно, что вы имеете на пути POCO. Вы вручную их кодировали, и ваш контекст или T4 генерировали их? Есть несколько замечательных статей здесь , которые измеряют производительность без POCO, сгенерированных T4 POCO / Context и POCO с ручным кодированием / Context. Как и ожидалось, ОГРОМНАЯ экономия производительности достигается за счет POCO (более чем 15-кратное повышение производительности по сравнению с его эталоном) по сравнению с маршрутами POCO по сравнению с генерируемыми Entity Framework. Вы не говорите, что СУБД ... если MSSQL вы включили профилировщик и посмотреть, что генерируется?