Entity Framework - взаимодействовать с Orace и SQL Server

1

Я работаю над.NET web api service (с поддержкой Odata) для поддержки мобильного клиента. Служба должна поддерживать базы данных Oracle и SQL Server, но одновременно будет использоваться только один тип базы данных, в соответствии с которым когда-либо клиент базы данных использует.

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

Также кажется, что для поддержки oracle в EF необходимы сторонние драйверы oracle - от devart или oracle ODP.NET.

Я обсуждаю, должен ли я использовать ADO.NET старого стиля или использовать EF для создания уровня доступа к данным.

Я буду признателен за любую помощь в этом.

Благодарю!

Теги:
sql-server
architecture
entity-framework

1 ответ

2
Лучший ответ

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

1.- ¿Как создать аглогический DAL базы данных (DB Engine)?

A: Один из подходов заключается в том, чтобы следовать шаблону репозитория и/или использовать интерфейсы для развязки кода, который управляет данными из кода, который извлекает/вставляет его. Фактическая реализация интерфейсов, используемых вашим кодом для получения данных, также может быть описана как агрегированная для DB Engine, если вы собираетесь использовать ADO.NET, вы можете проверить корпоративную библиотеку на очень полезный код, который является DB Агностик двигателя. Entity Framework также совместим с различными механизмами БД, но, как вы уже упоминали, может взаимодействовать только с одним БД за раз, поэтому всякий раз, когда вы создаете модель, вы привязываете ее к специфике механизма БД, в котором находится ваша БД. связано с другой проблемой в вашем вопросе:

2.- Если вы используете простой старый ADO.NET или EF?

Ответ: Это очень хороший вопрос, который, как я уверен, был задан много раз, и учитывая, что оба подхода дают вам одни и те же практические результаты, связанные с возможностью получения и манипулирования данными, возникает следующий вопрос: ¿что является вашим личным предпочтение кодирования и ограничения времени/ресурсов проекта?

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

Таким образом, если люди, участвующие в проекте, не очень удобны в написании хранимых процедур в SQL, и манипуляции с данными будут вращаться в основном вокруг вашей службы без необходимости очень сложных операций на стороне БД, тогда EF является подходящим подходом, и вы можете использовать шаблон репозитория, а также интерфейсы для реализации объектов "DBContext", которые позволят вам создать DAL DB Agnostic.

Однако, если вам необходимо выполнять транзакции, безопасность, расширенную регистрацию и удобнее записывать хранимые процедуры SQL, Entity Framework часто оказывается для вас бременем просто потому, что она еще не подходит для расширенных задач, например:

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

  • Другая ситуация использует преимущества таких функций, как Table Valued Parameters в SQL Server, для оптимизации отправки сразу нескольких записей в БД, в этом случае Entity Framework не включает ничего, что автоматически оптимизирует операции с несколькими записями, поэтому для использования TVP вам нужно будет вручную определить эту операцию, как если бы вы пошли по маршруту ADO.NET.

В конце концов, вам придется взвесить соображения вашего проекта против того, что вам предоставили альтернативы; ADO.NET дает вам максимальную производительность и настраиваемость для ваших операций с БД, он обладает высокой масштабируемостью и позволяет оптимизировать, но для кодирования требуется больше времени, в то время как EF очень прост и практичен для манипуляций с объектами, и хотя он постоянно развивается и улучшается, его производительность и возможности еще не совсем на пару с ADO.NET.

Что касается проблемы с драйверами, это не должно слишком сильно зависеть от этого, так как даже Oracle рекомендует использовать их драйвер вместо стандартного, предоставленного Microsoft.

  • 0
    Отличный исчерпывающий ответ. Спасибо!

Ещё вопросы

Сообщество Overcoder
Наверх
Меню