Вопрос по database, .net, c# – .Net: как создать независимый от поставщика набор данных, табличные адаптеры, привязки (база данных определяется во время выполнения)

0

У меня есть приложение C # Windows Forms, чей прототип был создан на SQL Server (строго типизированный набор данных). В окончательной версии приложение должно работать на SQL Server, MySQL или Oracle.

Теперь мне интересно, какие части (если таковые имеются) могут быть повторно использованы из прототипа. 1. Набор данных (напечатан)? 2. TableAdapters? (вероятно, нет, они содержат специфичный для SQL Server синтаксис) 3. Привязки к DataGridViews

Самое главное, если нам нужно заново все это реализовать, есть ли способ сделать это во время разработки? Или же, 1. нужно ли программно создавать нетипизированный набор данных? 2. нужно ли программно создавать свои адаптеры данных (или адаптеры таблиц)? Если да, то какой из двух? 3. Нужно ли нам программно создавать привязки к сетке данных интерфейса?

Возможно, не имеет значения: если мы создадим модель сущности (AFAIK, которая обеспечивает независимость БД) от существующей схемы БД, можем ли мы использовать это каким-либо образом для создания привязок к нашим сетевым представлениям?

Спасибо!

Итак, чтобы сохранить наши Bindings и dataGridViews, а также некоторую дополнительную логику, которую мы реализовали, должны ли мы выбросить все сгенерированные TableAdapter и написать их вручную? Если мы их выбрасываем, должны ли мы вместо этого использовать DataAdapters?

Является ли это "за книгой"? подход? Кто-нибудь сделал что-то подобное?

В более общем случае, если вам нужно создать приложение Forms для работы с несколькими базами данных, сделайте ли вы это: A. с нетипизированным набором данных, dataadapters / tableadapters и привязками, созданными вручную B. как-то сгенерируйте независимый от поставщика набор данных и dataadapters / tableadapters ( как?) и связать их во время разработки через VS gui C. каким-то другим способом ???

UPDATE:

Итак, чтобы сохранить наши Bindings и dataGridViews, а также некоторую дополнительную логику, которую мы реализовали, должны ли мы выбросить все сгенерированные TableAdapter и написать их вручную? Если мы их выбрасываем, должны ли мы вместо этого использовать DataAdapters?

Является ли это "за книгой"? подход? Кто-нибудь сделал что-то подобное?

В более общем случае, если вам нужно создать приложение Forms для работы с несколькими базами данных, сделайте ли вы это: A. с нетипизированным набором данных, dataadapters / tableadapters и привязками, созданными вручную B. как-то сгенерируйте независимый от поставщика набор данных и dataadapters / tableadapters ( как?) и связать их во время разработки через VS gui C. каким-то другим способом ???

Ваш Ответ

2   ответа
3
The typed dataset/table is database independent. (however, if you add adapters in the designer they get DB-specific.. Don't use adapters from the designer
The adapters ARE NOT database independent.
Databinding is database independent. But beware of drag-drop databinding automatically adding an adapter


Remove the adpaters from the dataset designer Rewrite your own repositories/adapters using a simple class with methods that get/fill tables. So you use them instead of the generated adapters. These classes can be DB-specific. So for instance a PersonRepositorySqlServer,PersonRepositoryMySql. Or perhaps you give the db-type with the constructor to reuse the SQL as much as possible..
If you used adapter on your forms, remove them to. Hand-code the filling of the dataset

Что я всегда делаю, чтобы ответить на остальные вопросы

I use typed datasets but I just make the tables and not the adapters I Usualy code the databindings since sometimes the designer messes up but this is not necessary to be db independent I write my own repositories that use adapters to fill/get/update the datatables. However I code them by hand. Given a typed datatable it's rather easy to auomatically generate update/insert/delete/fill statements by the way..



Переписать адаптеры выглядит сложно, но на самом деле это вполне выполнимо.

у вас есть рабочий пример по этому поводу?
2

Datasets are DB independent. Typed Datasets probably as well. DataAdapters are in so far DB dependent as they contain SQL to talk to the DB There are abstractions and possibilities to work vendor independent with the basic ADO.NET concepts (IDbConnection, IDbCommand, etc.) You may also bind plain old c# objects to BindingSource & friends. If you go down this route prepare to throw pretty much everything away you have prototyped. You will require a framework that can translate between "entities" and the DB. It will depend on that framework what the limitations on your entities are and how your DB independence looks like.

Похожие вопросы