DataTable Wrapper или Как отделить пользовательский интерфейс от бизнес-логики

Я прошел через это недавно, отделяя почти то же самое от нашего слоя пользовательского интерфейса.

Вы можете увидеть мой прогресс здесь и здесь.

На мой взгляд, A DataTable не представляет бизнес-логику. В частности, это данные, извлеченные непосредственно из базы данных. Бизнес-логика превращает эти данные в действительно полезный бизнес-объект.

Итак, первый шаг - отделить DataTable от бизнес-объекта.

Вы можете сделать это, создав объекты и List<object>, которые составляют таблицы данных и коллекции таблиц данных, а затем вы можете создать ListView, который отображает эти объекты. Я описываю последние шаги в ссылках, которые я разместил выше. И первые шаги так же просты, как следующие:

1. Создайте класс, который будет представлять ваш объект.
2. выполнить итерацию через свой DataTable (или DataSet, или как бы вы ни извлекали данные) и вставить эти поля в свойства этого объекта (или того List<T>);
3. верните этот список в Gridview или ListView для отображения.

Таким образом, ваш ListView или Gridview не будут тесно связаны с методом, которым вы извлекаете свои данные. Что произойдет, если вы позже решите получить данные из запроса JSON или XML-файла? Тогда вам придется встроить это туда.

Шаг 1 - Получение данных из базы данных

Есть несколько методов для получения данных из базы данных, я не могу перечислить их здесь. Я предполагаю, что вы уже знаете, как получать данные из базы данных, а если нет, то есть довольно много ссылок, по которым можно перейти. Представим, что вы подключились к базе данных и используете SQLDataReader для получения данных. Мы заберем там.

Диаграмма классов

Foo
----
id
Name
Description

А вот метод:

 private void FillDefault(SqlDataReader reader, Foos foo)
        {
            try
            {
                foo.id = Convert.ToInt32(reader[Foo.Properties.ID]);
                foo.Name = reader[Foo.Properties.NAME].ToString();
                    
                
             if (!string.IsNullOrEmpty(
                reader[Foo.Properties.DESCRIPTION].ToString()))
                 foo.Description = 
                 reader[Foo.Properties.DESCRIPTION].ToString();
             else foo.Description = string.Empty;
            }
            catch (Exception ex)
            {
               throw new Exception(
               string.Format("Invalid Query. 
               Column '{0}' does not exist in SqlDataReader.", 
               ex.Message));
            }
        }

Как только это произойдет, вы можете вернуть список, выполнив этот процесс в цикле while, который нацелен на функцию SQLDataReader.Read().

Как только вы это сделаете, давайте представим, что возвращаемый вами Foo является списком. Если вы сделаете это и перейдете по первой ссылке, которую я дал выше, вы можете заменить Dictionary<TKey, TValue> на List<T> и получить тот же результат (с небольшими отличиями). Класс Properties просто содержит имена столбцов в базе данных, поэтому у вас есть одно место для их изменения (на случай, если вам интересно).

DataTable - обновление на основе комментария

Вы всегда можете вставить промежуточный объект. В этом случае я бы вставил бизнес-уровень между DataTable и пользовательским интерфейсом и обсудил, что буду делать выше. Но DataTable - это не бизнес-объект; это визуальное представление базы данных. Вы не можете перенести это на уровень пользовательского интерфейса и называть его разъединенным. Они говорят, что вам нужно использовать DataTable, они говорят, что вы должны перенести этот DataTable в пользовательский интерфейс? Я не могу представить, чтобы они это сделали. Если вы это сделаете, то вас никогда не расстанут. Вам всегда понадобится промежуточный объект между DataTable и уровнем пользовательского интерфейса.

Я бы начал с разделения таблицы данных прямо в корзину. Создайте уровень домена, а затем какой-нибудь уровень доступа к данным, который имеет дело с БД (рекомендуется ORM).

Затем создайте уровень обслуживания, который предоставляет данные пользовательскому интерфейсу. Вся бизнес-логика должна быть внутри службы или самих сущностей.

Рассмотрите возможность реализации шаблона MVP (презентатор представления модели). Это дает вам разделение бизнес-логики через интерфейс докладчика, что также позволяет улучшить возможности модульного тестирования. Тогда ваш код страницы aspx является просто соединителем событий и получателем / установщиком свойств. Вы можете найти его в MS шаблонах и практиках блоков корпоративных приложений (CAB - составной блок приложения - если я не ошибаюсь).
Подробнее об этом можно прочитать здесь: http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
Но также из DataTable / Наборы данных в объекты (POCO) является предпочтительным.