Рекомендации по замене блока доступа к данным Enterprise Library на Entity Framework - PullRequest
7 голосов
/ 04 февраля 2011

Несколько лет назад мы разработали большое приложение ASP.Net (C # / .net 3.5), которое должно было быть независимым от «компонента Database Engine» (то есть это приложение могло использовать SQL Server, Oracle, MySQL ... как двигатель БД). Для этого мы использовали блок доступа к данным Enterprise Library 4.1.

Но сейчас, когда мы находимся на этапе «повышения производительности / масштабируемости», мы думаем об обновлении технологии или реорганизации основ наших приложений.

Итак, вопрос в том, есть ли какое-то преимущество для перехода на Entity Framework? Соблюдает ли EF наши независимые критерии Database Engine? Или мы должны сохранить нашу реализацию EntLib DAAB, но обновить ее до последней версии (5.0)?

Спасибо

Ответы [ 3 ]

12 голосов
/ 05 февраля 2011

Самая большая проблема, возникающая между ними, заключается не в независимости базы данных, а в том, что модель использования принципиально иная. Блок доступа к данным (DAAB) - это, прежде всего, удобная оболочка для ADO.NET. Это облегчает / делает менее раздражающим вызов хранимых процедур, но вы все еще имеете дело с наборами данных или программами чтения данных. Это на самом деле не меняет того, как вы взаимодействуете с базой данных, оно просто делает ее менее раздражающей.

Entity Framework, с другой стороны, касается моделирования данных и объектно-реляционного отображения. Он работает на более высоком уровне, чем DAAB; вы пишете свой код с точки зрения ваших объектов, а не с точки зрения DataSets или DataReaders. Он автоматизирует «материализацию» объектов из базы данных, поэтому вам не нужно писать этот код, поддерживает отношения между ними и т. Д. Это гораздо более полнофункциональный, но совершенно другой способ работы с базой данных.

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

Существует множество провайдеров, доступных для EF (см. Ответ Деварта для списка), но они все внешние / дополнительные расходы. Единственный в коробке для Sql Server. Хотя я добавлю, что DAAB на самом деле не полностью охватывает «независимость от базы данных» - если у вас есть фактический SQL в вызовах DAAB, это не поможет вам с различиями в диалектах SQL. EF будет.

0 голосов
/ 30 января 2013

Есть ли какое-либо преимущество при переходе на Entity Framework?

Как правило, быстрее выполняется работа по доступу к данным.Синтаксис Linq великолепен и может запрашивать sql.

Соблюдает ли EF наши независимые критерии Database Engine?

Не без какой-либо третьей стороны поддержка.Хотя я не сталкивался с ЛЮБЫМИ разработчиками, которые фактически взяли работающее приложение и переключили технологии баз данных на или из sql.

Или мы должны сохранить нашу реализацию EntLib DAAB, но обновить до последней версии (5.0)?

DAAB потрясающий !!Я написал для него код generator . Также после реализации EF для большой базы данных с реляционной схемой VERY POOR я обнаружил, что «мастер» EF занял много времени для обновления, 3 минуты для таблиц 110 sql(примерно).Это было слишком медленно, и я вернулся в DAAB ... Я скажу, что путь вперед - EF.Я просто пытаюсь использовать его с хранимыми процедурами и без отслеживания для лучшей производительности .Еще одна вещь, о которой следует помнить с помощью EF, - это слияние конфликтов, когда два человека обновляют документы по отдельности.Это может запутать.

0 голосов
/ 04 февраля 2011

Существует ряд поставщиков EF для Oracle ( Devart dotConnect для Oracle , DataDirect ) и MySQL ( Devart dotConnect для MySQL , MySQL Соединитель / NET ), и Microsoft предоставляет поставщика Entity Framework для SQL Server, поэтому не должно быть никаких проблем с независимостью базы данных.

...