Каков наилучший способ построить слой данных в нескольких базах данных?
Сначала немного об окружающей среде:
Мы используем программу под названием Clearview для управления сервисными отношениями с нашими клиентами, включая колл-центр и работу на местах. В целях лучшей поддержки клиентов и наших полевых техников мы также разработали веб-сайт, обеспечивающий доступ к записям услуг в Clearview и отчетам. Со временем наша потребность в настройке поведения и добавлении новых функций привела к тому, что все больше и больше вещей были привязаны к этому сайту и его базе данных.
На данный момент мы имеем дело с такими вещами, как Компания, определяемая частично в базе данных Clearview и частично в базе данных веб-сайта. Для правильной оценки мы также начинаем связывать сценарии для нашей телефонной системы с тем же веб-сайтом, который также потребует общения с собственной базой данных телефонной системы.
Все это настроено и работает... НО у нас нет хорошего уровня данных для работы со всем этим. Мы перешли с Linq на SQL, и теперь у нас есть два DBML, которые мы можем использовать, а также некоторые пользовательские классы, которые я написал до того, как услышал о Linq, вместе с некоторыми наборами данных ADO старого стиля. Так что да, в основном все в беспорядке.
То, что мне нужно, - это уровень данных, который обеспечивает единый внешний интерфейс для наших приложений, а внутренний поддерживает все в правильной базе данных.
Я слышал кое-что о Entity Framework, позволяющем создавать классы из нескольких источников, но оказывается, что может быть только одна база данных. Итак, вопрос в том, как я мог продолжить это?
В настоящее время я думаю о том, чтобы получить классы Linq To SQL, установленные для каждой базы данных, а затем вручную написать совместимые с Linq интерфейсы, которые связывают их вместе. Похоже на большую работу, и учитывая ограничения Linq (например, невозможность обновления), я не уверен, что это хорошая идея.
Могу ли я сделать что-то с Entity Framework, что получилось бы лучше? Стоит ли искать другой инструмент? Я сумасшедший?
3 ответа
Платформа Entity Framework дает определенную степень независимости базы данных, поскольку вы можете построить модель объекта из одной базы данных, а затем подключить ее к другой базе данных, используя другую строку подключения объекта. Однако, как вы говорите, это всего лишь одна база данных, и, кроме того, она ограничена базами данных, которые поддерживают Entity Framework. Многие делают, но не все из них. Вы можете использовать несколько моделей сущностей в одном приложении, чтобы объединить несколько баз данных с помощью Entity Framework. Об этом есть информация в блоге команды ADO.NET. Однако поддержка Entity Framework для этого в лучшем случае находится на ранней стадии.
Мой подход к этой проблеме заключается в том, чтобы абстрагироваться от использования Entity Framework за шаблоном Repository. Для меня самое непосредственное преимущество - сделать модульное тестирование очень простым; вместо того, чтобы пытаться смоделировать мою модель Entity, я просто заменяю фиктивный репозиторий, который возвращает IQueryables. Но этот же шаблон действительно хорош для объединения нескольких источников данных или источников данных, для которых нет поставщика Entity Framework, таких как веб-служба, не поддерживающая службы данных.
Поэтому я не собираюсь говорить: "Не используйте Entity Framework". Мне это нравится, и я использую это сам. Учитывая последние новости от Microsoft, я считаю, что это лучший выбор, чем LINQ to SQL. Но это не решит проблему, которую вы описываете. Используйте шаблон Repository.
Если вы хотите использовать такие инструменты, как Linq2SQl или EF, и не хотите управлять несколькими DBMLS (или какими бы то ни было вызванными в EF или другими инструментами), вы можете создать представления в базе данных вашего сайта, которые ссылаются на ClearView или Phone БД системы.
Это позволяет вам отделить ваш веб-сайт от их структуры базы данных. Я считаю, что Linq2Sql и EF могут использовать представление в качестве источника для сущности. Если они не могут смотреть на nHibernate.
Это также позволит вам иметь составные объекты, которые извлекаются из различных источников данных. Существуют некоторые ограничения при обновлении представлений в SQL Server; тем не менее, вы можете определить свой собственный вместо триггера (ов) в представлении, которое может затем сделать фактические операторы вставки обновления удаления.
L2S прекрасно работает с представлениями в моем проекте. Вам нужно только сделать небольшой трюк: 1. Добавьте таблицу вторичной БД в текущую БД в качестве представления. 2. В Designer добавьте атрибут первичного ключа в поле id в представлении. 3. Только сейчас добавьте связь с любой другой таблицей, которую вы хотите в исходной БД.
Теперь вы можете увидеть представление, доступное для навигации.