Рекомендации по выбору Entity Framework 6 или raw ADO.Net

Question

У нас есть существующее устаревшее приложение, используемое от 200 до 300 компаний, которое будет перестроено с нуля в ближайшем будущем. Из-за характера нового приложения мы находимся на заборе относительно технологии доступа к данным.

В целом мы будем иметь архитектуру приложений с несколькими арендаторами (ASP.Net MVC) и архитектуру данных с одним арендатором (то есть каждая компания будет иметь собственную базу данных SQL). Я не хочу обсуждать архитектуру данных с несколькими арендаторами, используя отдельные схемы базы данных для каждой компании. Существуют договорные обязательства, которые требуют, чтобы каждая компания имела свою собственную базу данных.

У нас есть три проблемы, которые являются причиной нашей нерешительности:

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

Во-вторых, мы хотим иметь контрольный журнал для многих таблиц, возможно, даже для большинства таблиц. Я думаю, что мы будем использовать какой-то тип искажений событий, связанных с заражением. У нас будет стандартная таблица SQL, в которой хранится текущее состояние объекта и вторая таблица контрольных журналов, в которой хранятся дельта. Я не уверен точно, как что-то подобное будет реализовано с Entity Framework. Может быть, получить только измененные свойства объекта сущности и передать их в таблицу дельта, прежде чем передать полный объект объекта в таблицу состояний. Идеи, безусловно, приветствуются здесь.

Наконец, нам необходимо поддерживать некоторую степень настройки некоторых объектов домена. Эта настройка будет полностью контролироваться конечным пользователем. Чтобы поддержать это, я считаю, что мы будем использовать две таблицы для хранения объекта домена. Первой будет статическая таблица, в которой хранятся требуемые свойства домена. Вторая - динамическая таблица, в которой мы можем изменить схему «на лету», чтобы сохранить пользовательские свойства; так как это контролируется пользователем, эти динамические таблицы будут разными в каждой базе данных. Я не уверен, как с этим справиться с Entity Framework. Возможно, используйте Entity Framework для получения стандартного объекта домена, а затем опуститесь до необработанного ADO.Net, чтобы получить динамические свойства из динамической таблицы и выбросить их в какой-то мешок свойств на сущности. Опять же, любые идеи о том, как наилучшим образом реализовать это, очень ценятся.

Answer 1

META: Этот вопрос, вероятно, лучше подходит для программистов.stackexchange.com, и, вероятно, его следует разбить на отдельные вопросы, чтобы соответствовать Q & Формат лучше. Тем не менее, вот моя попытка ответить:

Я фактически работаю над проектом, который выполняет все три перечисленные вами вещи. По вашему 3 вопросам:

1. Модель данных сущности не является вещью для каждой базы данных. Если все ваши базы данных используют одну модель, то есть только одна модель.

2. Сущность Framework на самом деле не помогает и не повреждает здесь. EF не отличает поля в объекте объекта от полей базы данных и предоставляет их список. (Может быть, вы можете заставить это сделать это как-то?) Итак, что-то нужно сделать, а затем внести изменения в контрольный журнал. Вам придется решить: будет ли это отвечать бизнес-логике, или это будет сделано на уровне базы данных? В прошлом я работал над проектами, которые делали это полностью с помощью триггеров. В этих подходах есть компромиссы.

3. НЕ настраивайте базу данных для каждого клиента: это кошмар управления конфигурацией. Вместо этого используйте XML, JSON или просто типичную гибкую структуру таблицы. К последнему из них могут относиться столбцы с именем «custom1, custom2, custom3» в сочетании с другим способом изменения правил метки и проверки. Если вам нужно бесконечное количество таких полей, вы можете иметь целую таблицу для настраиваемых полей. Независимо от того, какой подход вы используете, EF вам не поможет или не повредит вам.

Прощальная мысль: EF не является ни сценарием, ни сценарием. Это всего лишь оберточный слой поверх ADO. Используйте EF, где это уместно и удобно, и отступите к ADO.NET в какой-то другой процедуре, если это лучше подходит. Я был в проекте, который использовал EF для работы CRUD и отчетности, но использовал ADO.NET для массового импорта/экспорта данных и для просмотра в режиме реального времени. Это не похоже на то, что вы «привязаны» к нему или должны пройти через все это. Вы даже можете использовать его для развертывания и обновления баз данных, даже если вы никогда не используете его в своем коде напрямую.