Улучшите Шаблон метода выбора уровня доступа к данным

Один шаблон, которым я наслаждался, похож на это насколько клиентский код идет:

        DataTable data = null;
        using (StoredProcedure proc = new StoredProcedure("MyProcName","[Connection]"))
        {
            proc.AddParameter("@LoginName", loginName);
            data = proc.ExecuteDataTable();
        }

Я обычно устанавливаю дополнительную связь, и я кодирую способом, чтобы вытянуть ее от раздела конфигурации ConnectionStrings или рассматривать ее как строку фактического соединения. Это позволяет мне снова использовать dal в одном от сценария и является частично привычкой со дней COM +, когда я сохранил строку подключения с помощью объектного свойства конструкции.

Мне нравится это, потому что это легко считать и скрывает весь код ADO от меня.

Единственная вещь, которую я делаю по-другому, является мной переключенный от моих собственных внутренних вспомогательных методов базы данных до фактического Блока приложений Доступа к данным http://msdn.microsoft.com/en-us/library/cc309504.aspx

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

Существует столько способов реализовать DBAL, по-моему, Вы находитесь на правильном пути. Somethings для рассмотрения в реализации:

• Вы используете подобный фабрике метод для создания SqlConnection, это - деталь, но можно сделать то же для SqlCommand.
• Длина параметра является дополнительной, таким образом, можно на самом деле упустить ее из Параметра. Добавьте вызов.
• Создайте методы для добавления параметров также, примера кода ниже.

Добавьте использование параметров DbUtil.AddParameter(cmd, "@Id", SqlDbType.UniqueIdentifier, Id);

internal class DbUtil {

internal static SqlParameter CreateSqlParameter(
    string parameterName,
    SqlDbType dbType,
    ParameterDirection direction,
    object value
) {
    SqlParameter parameter = new SqlParameter(parameterName, dbType);

    if (value == null) {
        value = DBNull.Value;
    }

    parameter.Value = value;

    parameter.Direction = direction;
    return parameter;
}

internal static SqlParameter AddParameter(
    SqlCommand sqlCommand,
    string parameterName,
    SqlDbType dbType
) {
    return AddParameter(sqlCommand, parameterName, dbType, null);
}

internal static SqlParameter AddParameter(
    SqlCommand sqlCommand,
    string parameterName,
    SqlDbType dbType,
    object value
) {
    return AddParameter(sqlCommand, parameterName, dbType, ParameterDirection.Input, value);
}

internal static SqlParameter AddParameter(
    SqlCommand sqlCommand,
    string parameterName,
    SqlDbType dbType,
    ParameterDirection direction,
    object value
) {
    SqlParameter parameter = CreateSqlParameter(parameterName, dbType, direction, value);
    sqlCommand.Parameters.Add(parameter);
    return parameter;
    }
}

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

Мои мысли о прокрутке Вашего собственного кода доступа к данным:

• Со временем я нашел легче не иметь отдельные объекты DAL/BL, а скорее объединить их в отдельный объект (некоторое время спустя после того, чтобы сделать этот вывод, я узнал, что это - довольно известный шаблон - а именно, ActiveRecord). Это могло бы выглядеть хорошим и отделенным, чтобы иметь отдельные блоки DAL, но издержки в затратах на обслуживание сложат. Каждый раз Вы добавляете новую опцию, необходимо будет создать больше, кодируют/изменяют больше классов. По моему опыту, команда, которая поддерживает приложение, часто является путем меньше, чем исходная команда разработчиков, которые создали его, и они будут ненавидеть дополнительную требуемую работу.
• Для многочисленных команд могло бы иметь смысл разделять DAL (и позволять коллективной работе на нем, в то время как другие. Но это делает хороший стимул для чрезмерного увеличения размера кода.
• Приход к определенному образцу: как Вы используете получающийся DataTable? Выполните итерации строк, создайте типизированные объекты и получите данные из строки? Если ответ да, думайте о дополнительном DataTable, который Вы создали только для движущихся данных между DAL и BL. Почему бы не взять его непосредственно от DataReader?
• Также об образце: если Вы возвращаете невведенный DataTable, то я предполагаю, что необходимо использовать имена столбцов (набора результатов возвраты вызова SP) путь в коде вызова. Это означает, должен ли я изменить что-то в базе данных, она могла бы влиять на оба слоя.

Мое предложение (я попробовал оба метода - предложение является последним рабочим подходом, который я придумал - оно вид развиваемых со временем).

• Сделайте базовый класс для своих введенных бизнес-объектов.
• Сохраните объектное состояние в базовом классе (новым, измененным и т.д.)
• Поместите основные методы доступа к данным в этот класс как статические методы. С небольшим усилием (подсказка: общие методы + Активатор. CreateInstance), можно создать один бизнес-объект на каждую строку, возвращенную в читателе.
• сделайте абстрактный метод в бизнес-объекте для парсинга данных строки (непосредственно от DataReader!) и заливка объект.
• сделайте статические методы в полученных бизнес-объектах, которые готовят сохраненные proc параметры (в зависимости от различных критериев фильтра) и называют универсальные методы доступа к данным от базового класса.

Цель состоит в том, чтобы закончиться с использованием, таким как:

List<MyObject> objects = MyObject.FindMyObject(string someParam);

Преимущество для меня было то, что я только должен изменить один файл для преодоления изменений в именах столбцов базы данных, типы и т.д. (небольшие изменения в целом). С некоторыми хорошо думал регионы, можно организовать код так, чтобы они были отдельными "слоями" в том же объекте :). Другое преимущество - то, что базовый класс является действительно допускающим повторное использование от одного проекта до другого. И чрезмерное увеличение размера кода минимально (хорошо, по сравнению с преимуществами. Вы могли также заполнить наборы данных и связать их со средствами управления UI :D

Ограничения - Вы заканчиваете с одним классом на объект области (обычно на основную таблицу базы данных). И Вы не можете загрузить объекты в существующих транзакциях (хотя Вы могли думать о передаче транзакции, если у Вас есть один).

Сообщите мне, интересно ли Вам более подробно - я мог бы развернуть ответ немного.

Пришлось добавить собственное:
Возврат DataReader из DataLayer в операторе Using

Новый шаблон позволяет мне иметь в памяти только одну запись за раз, но по-прежнему закрывает соединение в красивом операторе использования:

public IEnumerable<T> GetSomeData(string filter, Func<IDataRecord, T> factory)
{
    string sql = "SELECT * FROM [SomeTable] WHERE SomeColumn= @Filter";

    using (SqlConnection cn = new SqlConnection(GetConnectionString()))
    using (SqlCommand cmd = new SqlCommand(sql, cn))
    {
        cmd.Parameters.Add("@Filter", SqlDbType.NVarChar, 255).Value = filter;
        cn.Open();

        using (IDataReader rdr = cmd.ExecuteReader())
        {
            while (rdr.Read())
            {
                yield return factory(rdr);
            }
            rdr.Close();
        }
    }
}