Сильно типизированный набор данных с набором адаптеров таблиц для каждого поставщика базы данных? - PullRequest
Новая
       12

Сильно типизированный набор данных с набором адаптеров таблиц для каждого поставщика базы данных?

2 голосов
/ 27 января 2009

Мне нужен строго типизированный DataSet вместе с конструктором TableAdapter, но конструктор DataSet в Visual Studio генерирует специфичный для провайдера код (например, SQL Server против MySql), и я не хочу фиксировать только одного провайдера. ORM поможет, но:

  • Entity Framework версии 3.5 и не очень хорошо работает с DataSets, а
  • NHibernate не поддерживает SQLite.

Вот что я придумала:

«DataSets.Masters» содержит полностью разработанный DataSet, привязанный к какому-либо конкретному поставщику (например, SqlClient), в том числе:

  • a CustomTableAdapter компонент, подкласс каждого разработчика TableAdapter ,
  • и ITableAdapterManager интерфейс, реализованный дизайнером TableAdapterManager для иерархических обновлений.

Все , кроме DataSets.MyDataSetTableAdapters Пространство имен копируется в проект «DataSets», где удаляется весь код TableAdapter (вместе с аннотацией xs:).

Пространство имен DataSets.MyDataSetTableAdapters вместе с MyDataSet.xsd и т. Д. Копируется и настраивается в каждый из «DataSets.SqlClient», «DataSets.SQLite» и т. Д., Каждый из которых ссылается на « Сборка "Наборы данных".

Теперь мне просто нужно выбрать правильную сборку для загрузки моей реализации ITableAdapterManager , основываясь на любой заданной строке соединения. Когда схема таблицы изменяется, я изменяю сборку Masters, копирую код в производственные сборки и запускаю несколько тестов.

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

Ответы [ 2 ]

1 голос
/ 28 января 2009

Может быть проще просто игнорировать автоматически сгенерированные команды TableAdapter и использовать объекты фабрики доступа к данным ADO.Net , когда пришло время для ваших операций CRUD. Таким образом, вы можете использовать DbProviderFactory.CreateCommandBuilder для правильного форматирования параметров в операциях CRUD. Обратите внимание, что это предполагает, что вы не делаете сложного сопоставления свойств, и ваша схема останется согласованной для всех поставщиков данных.

Дополнительная опция, если вы используете эту технику, - это создать класс, который вы можете ввести в качестве свойства BaseClass в ваших TableAdapters. Добавьте метод типа «init», который переопределяет соединение, и команды вставки, удаления, выбора и обновления с помощью заводских команд (на основе автоматически сгенерированной команды выбора & mdash; должен быть совместимым с большинством провайдеры).

1 голос
/ 27 января 2009

NHibernate поддерживает SQLite http://www.hibernate.org/361.html.

Я рекомендую использовать NHibernate в сочетании с Fluent NHibernate . Fluent NHibernate - это библиотека, которая позволяет вам использовать NHibernate без необходимости самостоятельно разбираться с XML-файлами, что, на мой взгляд, является самым большим недостатком NHibernate.

Также Fluent NHibernate поддерживает модель автоматического сохранения, согласно которой, если ваши доменные объекты близки к вашей схеме базы данных, вы можете автоматизировать весь бизнес-домен без написания кода отображения для каждого отдельного объекта. Чем больше ваши бизнес-объекты отличаются от вашей базы данных, тем сложнее становится использовать функции автоматического отображения Fluent NHibernate, и стоит использовать статическое отображение.

...