.NET: Написание DataAccess dll - PullRequest
       7

.NET: Написание DataAccess dll

0 голосов
/ 28 апреля 2010

Я хотел бы написать все процессы отношений данных (общие функции, связанные с DataAccess через .NET) в dll, и я хочу использовать его повторно. Какие функции должны иметь в этой DLL? Некоторые хотят использовать хранимые процедуры, некоторые с утверждениями. Можете ли вы все предложить мне? Пожалуйста, ведите меня! Спасибо всем!

Ответы [ 4 ]

3 голосов
/ 06 мая 2010

Это довольно большая тема, но вот начало:

Обзор ADO.NET

Для простых операций CRUD я могу подвести итог простому способу сделать это, предполагая, что вы уже немного знаете о базах данных, и ваша база данных уже существует.

1) Используйте конструктор наборов данных, который поставляется с VS IDE. (Есть и другие способы)

2) Перетащите нужные таблицы на поверхность. Это создаст много сгенерированного кода, который будет поддерживать ваши операции CRUD. Вы можете легко настроить их независимо от того, используете ли вы текстовые операторы или хранимые процедуры. Дизайнер знает, как обращаться с параметрами и типами данных. Вы также можете выбрать данные, просто чтобы убедиться в правильности утверждений.

3) DataTables и адаптеры создаются для каждой таблицы, которую вы перетаскиваете, с правильными типами для элементов. Вы можете использовать их так:

using (MyDataSet.MyDataTable sigtbl = new MyDataSet.MyDataTable ())
using (MyTableAdapter adtp = new MyTableAdapter())
            {
               adtp.Fill(sigtbl, TargetTime);
               //sigtbl now contains the data from your DB. Use LINQ if you want to subquery or whatever.
               adtp.Insert(newSig,NewTime) //Parameters depend on your insert.
            }

4) Инкапсулировать логику БД в полезные бизнес-функции и ссылаться на проект из других ваших проектов. Постарайтесь сохранить содержимое БД в отдельном слое.

Во всяком случае, это довольно просто. Вы непременно столкнетесь с некоторыми проблемами, пытаясь сделать это для себя, поэтому убедитесь, что вы хорошо понимаете, как работает ADO.NET, и возвращайтесь с дополнительными вопросами.

Другие альтернативы, просто чтобы упомянуть: 1) Используйте материал System.Data, если вы не хотите накладных расходов + сложность генерации типизированных классов для вас. 2) Посмотрите на LINQtoSQL: LINQtoSQL

2 голосов
/ 07 мая 2010

В дополнение к предыдущим предложениям вы можете взглянуть на блок доступа к данным корпоративной библиотеки: Microsoft Enterprise Library 5.0 Блок приложения доступа к данным также к ADO.NET Entity Framework

1 голос
/ 12 мая 2010

Microsoft Enterprise Library , с помощью блока приложения доступа к данным следует делать то, что вам нужно. Это рамки для себя.

Другой интересной библиотекой доступа к данным является хорошо известная ORM NHibernate .

Если вы хотите ускорить разработку DAL, вам следует рассмотреть эти два варианта по отдельности или вместе.

EntLib DAAB позволит вам указывать именованную connectionString в файлах конфигурации вашего приложения, чтобы вам не нужно было развертывать новую сборку приложения при изменении connectionString, только файл конфигурации. Также обычной практикой является управление и настройка только одной строки подключения на файл конфигурации, поэтому если изменяется только одна строка подключения, вы только развернете этот новый файл конфигурации для этого подключения, и все готово! EntLib позволяет вам управлять вашим пулом соединений в соответствии с лучшими практиками. Все и все через довольно простые XML-файлы конфигурации.

Что касается NHibernate, это инструмент объектно-реляционного отображения, который может обрабатывать доступ к данным через API ISession. Все, на чем вам нужно сосредоточиться, - это разработка диаграммы бизнес-класса. Как только вы закончите, просто напишите файлы сопоставления XML в соответствии с вашей объектной моделью, и все готово для сохранения ваших объектов в базовом хранилище данных, независимо от того, какое хранилище данных вы используете. При использовании SchemaExportTool вы можете даже не беспокоиться о написании сценариев DDL, поскольку NHibernate может создать вашу реляционную схему для вас!

Как я уже сказал, один или оба, это слой DAL для себя, и многое, многое другое! Не беспокойтесь об их переносе в другую библиотеку классов, если только вы не хотите создать удобный для пользователя инструмент для DAL. И они на 100% пригодны для повторного использования! Разве это не приятно?

1 голос
/ 11 мая 2010

Я бы держался далеко, далеко от таблиц данных, адаптеров, наборов и так далее. Я всегда находил их довольно неуклюжими. Я предпочитаю писать классы репозитория, сервисные слои и так далее. Я бы порекомендовал вам немного почитать о доменно-управляемом дизайне (http://dddcommunity.org).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...