Как создать приложение, поддерживающее несколько баз данных
У меня есть ситуация, когда мне нужно создать приложение, которое поддерживает несколько баз данных. Многократные базы данных означают, что клиент может сначала использовать любую из баз данных, таких как Oracle, SQL Server, MySQL, PostgreSQL.
Я пытался использовать ORM, как NHibernate или MyBatis. Но они имеют свои ограничения и нуждаются в экспертизе для использования.
Поэтому я решил использовать провайдеров данных, предоставляемых Microsoft, таких как ADO.NET, OLEDB, ODP.NET и т. Д.
Есть ли способ, чтобы моя логика базы данных оставалась одинаковой для всей базы данных? я пытался IDbConeection, IDbCommand и т.д., но у них есть проблема в случае Oracle (Ref Cursor).
Есть ли способ добиться этого? Некоторые ссылки или руководства будут оценены.
Редактировать:
Существует проблема с DBTypes, потому что они перечисляются по-разному для разных поставщиков данных.
4 ответа
Ну, реальные приложения так сложны. Прежде чем вы это узнаете, вы хотите заменить пользовательский интерфейс на приложение, представить свою логику в качестве службы WCF, изменить службу электронной почты у другого поставщика услуг, протестировать фрагменты кода во время насмешки над DAL и изменить базу данных на другую.,
Обычный способ справиться с этим - передать все вызовы через интерфейс, который отделяет реализацию от вызывающей стороны. После этого вы можете реализовать различные DAL.
Лично я обычно иду с таким подходом:
- Сначала создайте одну DLL, которая содержит все интерфейсы. По сути, идея состоит в том, чтобы выставить все вызовы, которые нужны вашему интерфейсу, приложению или чему-либо еще через интерфейс. С этого момента ваш пользовательский интерфейс больше не общается с базами данных или поставщиками электронной почты.
- Если вам нужно получить доступ к интерфейсу, вы используете фабричный шаблон. Никогда не используйте "новый"; это приведет к неприятностям в долгосрочной перспективе.
- Это не тривиально, и требует правильной обработки. Обычно я начинаю с минимальной версии, взламываю все остальное в пользовательском интерфейсе в качестве первой версии, затем перемещаю все, что касается БД или службы, в нужный проект при создании интерфейсов и, наконец, перестраиваю все, пока я не удовлетворен на 100%.,
- Интерфейсы должны быть построены, чтобы длиться. Конечно, изменения будут происходить со временем, но вы действительно хотите минимизировать их. Подумайте о том, что нас ждет в будущем, прочитайте о том, что придумали другие люди, и убедитесь, что ваши интерфейсы отражают это.
По сути, теперь у вас есть работающее программное обеспечение, которое работает с одной базой данных, почтовым провайдером и т. Д. Пока все хорошо.
Далее реинжиниринг фабрики. В основном вы хотите использовать параметры конфигурации, чтобы выбрать подходящего провайдера (правильную DLL, которая реализует ваш интерфейс) для ваших данных. В большинстве случаев достаточно простого переключателя.
На этом этапе я обычно делаю привычку делать тонны юнит-тестов для интерфейсов.
Последний шаг - это создание DLL для разных поставщиков баз данных. Один из них будет загружен во время выполнения в вашем приложении.
Я предпочитаю простой Linq для SQL (я также использую библиотеку из LinqConnect), потому что это довольно быстро. Я просто начинаю с копирования-вставки другого поставщика базы данных, а затем реинжиниринг, пока он не заработает. Лично я больше не верю в волшебное решение "поддержка всех баз данных sql": по моему опыту, некоторые базы данных будут обрабатывать определенные запросы намного, намного быстрее, чем другие базы данных - это означает, что вы, вероятно, в конечном итоге получите некоторый пользовательский код для каждая база данных в любом случае.
Это также момент, когда ваши юнит-тесты действительно окупятся. По сути, вы можете просто начать с копирования-вставки и протестировать его. Если вам повезет, все сразу запустится с приличной производительностью... если нет, вы знаете, с чего начать.
Построить до последнего
Создавай вещи на долго. Все изменится:
- Подумайте об обновлениях и протестируйте их. Предпочитаю автоматические тесты.
- Вы не хотите возиться с вашим заводом каждый день. Используйте рефлексию, выражения, генерацию кода или что-то еще, чтобы избавить себя от необходимости менять код.
- Потратьте время на написание тестов. Убедитесь, что вы покрываете большую часть. Я не могу подчеркнуть это достаточно; под давлением люди обычно "экономят" время, не написав тесты. Вы заметите, что на этот раз, когда вы "сохраните", вы получите двойную поддержку в качестве поддержки, когда вы уйдете. Каждый месяц.
Как насчет Entity Framework
Из-за этого я видел, как у многих моих клиентов возникают проблемы с производительностью. Во многих случаях, когда я это проверял, у меня был такой же опыт. Я заметил, что клиенты взламывали EF для большого количества запросов, чтобы получить немного приличной производительности.
Честно говоря, я сдался несколько лет назад, и я знаю, что они значительно улучшили производительность. Тем не менее, я бы протестировал его (особенно со сложными запросами), прежде чем рассматривать его.
Если бы я использовал EF, я бы реализовал все вещи EF в "общей DLL базы данных", а затем извлекал из них классы. Как я уже сказал, не все базы данных одинаковы с запросами - и вы можете захотеть реализовать некоторые хаки, необходимые для получения достойной производительности. Ваши тесты скажут.
Бонусы
Другие причины для программирования через интерфейсы имеют много преимуществ в сочетании с прокси. Чтобы назвать несколько, вы можете легко создавать приемники журналов, кэширование, статистику, WCF и т. Д., Просто реализуя тот же интерфейс. И если вы когда-нибудь возненавидите свой текущий оператор OR, вы можете просто выбросить его, не касаясь ни одной строки своего приложения.
Я считаю, что компоненты доступа к данным Microsoft подойдут вам. https://en.wikipedia.org/wiki/Microsoft_Data_Access_Components
Да, это возможно.
Сейчас я работаю с тем же сценарием, в котором все мои логические данные (как правило, вы можете называть метаданные) находятся в одной БД, а дата - в другой БД.
Что тебе необходимо сделать. у вас должен быть параметр, связанный с соединением, в двух разных файлах, или вы можете назвать эти файлы как файлы проп. теперь вам нужно иметь конкретный класс соединения, который принимает параметр из этого файла проп. поэтому, где вам нужно создать соединение, просто предоставьте файлы поддержки, и оно создаст соединение БД, как вам нужно.
Как насчет написания микросервисов и подключения их с помощью API отдыха? Вы (и, возможно, ваша команда) могли бы предоставить основное приложение, которое обрабатывает логику и пользовательский интерфейс. Это все еще основано на вашей текущей технологии. Но вместо непосредственного добавления какого-либо соединения с базой данных, вы можете предоставить несколько типов микросервисов (на основе asp.net или ядра), обеспечивающих API для отдыха. Вы получаете свои данные из каждой базы данных от такого микросервиса. Таким образом, вы бы разработали 1 микросервис, например, для MySQl, а другой - для MsSQL, а когда новый клиент придет к оракулу, вы напишете новый небольшой микросервис, который обрабатывает ваш ожидаемый API.
Дополнительная информация (на основе ядра.net) находится здесь: https://docs.asp.net/en/latest/tutorials/first-web-api.html
Я думаю, что это групповое обсуждение, какую технологию вы решите использовать. Но сегодня я бы порекомендовал написать микро сервис. Это значительно упрощает вложение нового приложения, например, для мобильного устройства:)