Организация проекта с БД
Вопрос может показаться абстрактным, конечно..
Но уж очень он меня интересует..
Понятно, что во всех средах практически не существует единичного способа решения той или иной задачи, поэтому народ на форуме так часто и вступает в полемику!!..
Но все-таки.. : как правильно организовать доступ к БД, работу с адаптерами и вообще всеми визуальными и невизуальными компонентами, связанными с ADO.NET..
Вопрос возник по следующей причине: как уже неоднократно говорил - на C# работаю недавно.. В самом начале нашего знакомства возникла необходимость работы с БД(создания СУБД).. Естественно, сразу в и-нет искать различные уроки, книги, учебники по C# в целом и ADO.NET в частности..
Практически во всех источниках организация проекта различная.. В том или ином подходе есть свои достоинства и недостатки..
Не могли бы вы подсказать какой-нибудь оптимальный подход к решению этого вопроса..
Работаю со статическими реляционными БД, т.е. структура БД в процессе работы приложения не меняется..
Вот подходы, которые я уже пробывал:
1) Работа с компонентами DataAdapter - каждый dataAdapter работает с каждой таблицей.. DataSet(модуль) - полная копия БД..
2) Работа с динамически создаваемыми dataAdapter'ами в run-time, с соответствующим заданием необходимых параметров для соответствующей комманды dataAdapter'a.. DataSet также создается в run-time для работы с конкретной таблицей..
3) Стиль разработки с использованием Data Access Layer. [FONT=Verdana][SIZE=2][FONT='Times New Roman']DAL[/FONT][FONT='Times New Roman'] ([/FONT][FONT='Times New Roman']Data[/FONT][FONT='Times New Roman'] [/FONT][FONT='Times New Roman']Access[/FONT][FONT='Times New Roman'] [/FONT][FONT='Times New Roman']Layer[/FONT][FONT='Times New Roman']) компоненты предназначены для скрытия (инкапсуляции) взаимодействия с конкретной БД. DAL при данном подходе используется только с "рабочими" таблицами, для относительно постоянных таблиц(справочников) используются TableAdapter'ы.. При этом создается два DataSet'а - один для справочников, другой для "рабочих" таблиц.. В DataSet'е для справочников висят tableAdapte'ы для каждой таблицы, dataAdapter'ы же для рабочих таблиц создаются в слое доступа к данным..[/FONT][/SIZE][/FONT]
Но уж очень он меня интересует..
Понятно, что во всех средах практически не существует единичного способа решения той или иной задачи, поэтому народ на форуме так часто и вступает в полемику!!..
Но все-таки.. : как правильно организовать доступ к БД, работу с адаптерами и вообще всеми визуальными и невизуальными компонентами, связанными с ADO.NET..
Вопрос возник по следующей причине: как уже неоднократно говорил - на C# работаю недавно.. В самом начале нашего знакомства возникла необходимость работы с БД(создания СУБД).. Естественно, сразу в и-нет искать различные уроки, книги, учебники по C# в целом и ADO.NET в частности..
Практически во всех источниках организация проекта различная.. В том или ином подходе есть свои достоинства и недостатки..
Не могли бы вы подсказать какой-нибудь оптимальный подход к решению этого вопроса..
Работаю со статическими реляционными БД, т.е. структура БД в процессе работы приложения не меняется..
Вот подходы, которые я уже пробывал:
1) Работа с компонентами DataAdapter - каждый dataAdapter работает с каждой таблицей.. DataSet(модуль) - полная копия БД..
2) Работа с динамически создаваемыми dataAdapter'ами в run-time, с соответствующим заданием необходимых параметров для соответствующей комманды dataAdapter'a.. DataSet также создается в run-time для работы с конкретной таблицей..
3) Стиль разработки с использованием Data Access Layer. [FONT=Verdana][SIZE=2][FONT='Times New Roman']DAL[/FONT][FONT='Times New Roman'] ([/FONT][FONT='Times New Roman']Data[/FONT][FONT='Times New Roman'] [/FONT][FONT='Times New Roman']Access[/FONT][FONT='Times New Roman'] [/FONT][FONT='Times New Roman']Layer[/FONT][FONT='Times New Roman']) компоненты предназначены для скрытия (инкапсуляции) взаимодействия с конкретной БД. DAL при данном подходе используется только с "рабочими" таблицами, для относительно постоянных таблиц(справочников) используются TableAdapter'ы.. При этом создается два DataSet'а - один для справочников, другой для "рабочих" таблиц.. В DataSet'е для справочников висят tableAdapte'ы для каждой таблицы, dataAdapter'ы же для рабочих таблиц создаются в слое доступа к данным..[/FONT][/SIZE][/FONT]
моё ИМХО. Часто пишу именно так, но есть случаи когда надо пользоваться другими подходами.
1) для доступа к БД никогда не использую визульные "компоненты"
2) Использую Rsdn.Framework.Data (открытый проект сайта RSDN, который повышает уровень абстракции и позволяет избежать лишних телодвижений. при этом скорость доступа почти не меняется (результаты тестов есть на вышеупомянутом сайте) и сохраняется возможность использовать различные провайдеры для доступа без изменений в коде)
//для меня это не обсуждается... если есть преграды, см. выше, можно прибегнуть к другим решениям
3) Для всех объктов базы данных пишу "оболочку" в виде классов и коллекций, в которые "сериализую" данные.
3.1) На запись значения свойства ставлю обработчик, который модифицирует данные в БД
3.2) в конструктор передаю идентификатор (первичн. ключ)
3.3) у коллекций переопределяю методы Remove, Clear, Add для внесения изменений в базу
4) к контроллам биндю именно объекты
и т.д.
вижу в этом подходе кучу плюсов :)
1) для доступа к БД никогда не использую визульные "компоненты"
2) Использую Rsdn.Framework.Data (открытый проект сайта RSDN, который повышает уровень абстракции и позволяет избежать лишних телодвижений. при этом скорость доступа почти не меняется (результаты тестов есть на вышеупомянутом сайте) и сохраняется возможность использовать различные провайдеры для доступа без изменений в коде)
//для меня это не обсуждается... если есть преграды, см. выше, можно прибегнуть к другим решениям
3) Для всех объктов базы данных пишу "оболочку" в виде классов и коллекций, в которые "сериализую" данные.
3.1) На запись значения свойства ставлю обработчик, который модифицирует данные в БД
3.2) в конструктор передаю идентификатор (первичн. ключ)
3.3) у коллекций переопределяю методы Remove, Clear, Add для внесения изменений в базу
4) к контроллам биндю именно объекты
и т.д.
вижу в этом подходе кучу плюсов :)