Возвращает DataTable или DataSet из DAL - неправильный подход - PullRequest
Новая
       41

Возвращает DataTable или DataSet из DAL - неправильный подход

0 голосов
/ 14 марта 2012

Я создаю свой проект с нуля, я начал с создания DAL, который обрабатывает соединение с SQL и может выполнять хранимую процедуру.
Позже проект будет CMS или блог
Мой ЦАП или DAL читает строку подключения из web.config и принимает arrays of SQL Parameters вместе с Stored Procedure Name и возвращает вывод выполненной хранимой процедуры в DataTable.
Я звоню своему ЦАП следующим образом (using class functions и иногда использую код позади) 

Dim dt As DataTable = Dac.ReturnDataTable("category_select_bypage",  New SqlParameter("@pageid", pageid), New SqlParameter("@id", id))

Что работает нормально, и я предполагаю завершить все мое приложение, вызвав этот ЦАП и вставив и получив данные с помощью хранимых процедур, или позже это могут быть простые запросы.
Но я показал эту работу своему учителю, и он сказал мне, что you are using a wrong approach, и ваш код не соответствует правильному подходу DAL.
Итак, я сейчас слишком сильно путаюсь с DAL и DAC. Любой Как здесь основные вопросы.

1. В чем разница между DAL и DAC
2. С помощью моего подхода, какое приложение хорошо сделать с ним? Могу ли я сделать тележки, используя этот подход? 3. Что не так с моим подходом?

Ответы [ 5 ]

2 голосов
/ 14 марта 2012

Адриано предоставил очень хорошую ссылку.Конечно, необходимо прочитать.Но я вижу одну вещь.При создании логических слоев в приложении каждый слой не знает о внутренней работе тех, кто находится под ним.Например, уровень представления не имеет представления о том, как уровень данных получает данные, это просто волшебство.Причина этого в том, что если вы решите не использовать SqlClient и выбрали другую технологию.Теперь, используя «Сокрытие технологий» со слоями, вы можете легко это изменить.

Итак, учитывая, что у вас есть, я предполагаю, что DataTable находится на уровне представления (или приложения).И, если это правда, ваш вызов метода DAC не должен показывать ничего, связанного с тем, что или как он извлекает данные.В вашем случае это правило нарушается параметром SqlParameter.Возможно, вы могли бы передать строки или INT.Например: 

public DataTable Dac.GetPage(int pageId, int id)

Тем не менее, удачи.Я рад видеть тех, кто хочет учиться, и тех, кто хочет учить.

2 голосов
/ 14 марта 2012

Я думаю, вы можете начать с этих ссылок:
- http://msdn.microsoft.com/en-us/library/aa581778.aspx
- http://martinfowler.com/eaaCatalog/ (архитектурные шаблоны источников данных)
- http://www.simple -talk.com / dotnet / .net-framework / .net-application-Architecture-the-data-access-layer / (речь идет о DataSets, думаю, вы можете использовать их до приложение небольшое или довольно простое: оно хорошо известно и глубоко интегрировано во многие инструменты VS).

Взгляните также на вопрос SO: Как организовать Уровень доступа к данным (DAL) в ASP.NET

1 голос
/ 15 марта 2012

Проблема с DataSet / DataTable заключается в том, что это представление вашей базы данных. Его повсеместное использование создаст высокую связь с вашей базой данных.

Это означает, что вы должны обновлять весь зависимый код каждый раз, когда вносите изменения в свою базу данных.

Лучше создавать простые классы, которые представляют базу данных. тем самым вам нужно будет изменять внутреннюю часть этих объектов (или слой отображения) только при изменении БД.

Я рекомендую вам прочитать о шаблоне Repository. Это самый распространенный способ абстрагирования источника данных.

1 голос
/ 14 марта 2012

Функция на уровне доступа к данным Уровень SQLServer: 

public override DataTable abc()
{
   //Connection with database
}

Функция на уровне доступа к данным: 

public abstract DataTable abc();

Функция на уровне логики бизнеса: 

public DataTable abc()
{
  //Preparing the list
}

Функция на уровне представления: 

using (DataTable DT =  (new BusinessLogicLayerClass()).abc())
{
}

Вышеупомянутый подход соответствует DataTable.Но вместо этого он должен возвращать список классов в презентацию.Работа по подготовке списка должна выполняться на уровне бизнес-логики.

1 голос
/ 14 марта 2012

Я не думаю, что возвращение DataSets можно легко описать как «неправильное».

Ваш DAL служит просто абстракцией, поэтому (гипотетически) мы можем менять базы данных или переходить из базы данных в файл XML или что-то еще.Остальная часть приложения остается неизменной.

Пока ваша бизнес-логика удовлетворена контрактом, который передает наборы данных из DAL, я не думаю, что это архитектурная проблема.Это может быть неоптимальным, поскольку наборы данных могут быть довольно дорогими с точки зрения ресурсов, но они очень хорошо поддерживаются в .Net (они являются основой более простых архитектур, таких как сценарий транзакций или шаблоны таблиц).

Чтовместо этого у вас могут быть некоторые пользовательские объекты, и DAL преобразует свои результаты SQL-запросов в эти объекты, чтобы затем их можно было обрабатывать на уровне бизнес-логики.

Но тогда я могу вспомнить ситуации, когда вы могли бы простохочу DataSets…

Все субъективно, конечно;)

...