#c#
#c#
Вопрос:
На уровне доступа к данным, который запрашивает базу данных и возвращает перечислимый объект результатов, каковы преимущества возврата, скажем, списка объектов Dog со свойствами Name, Age и т.д. Вместо DataTable, В котором есть столбцы типа «Name», «Age» и т.д. ?
Комментарии:
1. Тот факт, что POCO выдает вам список объектов Dog со свойствами Name, Age и т.д., Вместо DataTable, В котором есть столбцы типа «Name», «Age» и т.д.
Ответ №1:
Несколько:
- Безопасность типов
- Сериализация не только в XML, но и в JSON, двоичный…
- Удобочитаемость
- Более легкий
- Возможность добавлять варианты поведения
- Возможность определения обозначения данных и логики проверки
- Возможность использования ORM
Комментарии:
1. когда вы упоминаете сериализацию, вы имеете в виду какую-то автоматическую возможность .net сериализовать POCOs, но он не знает, как сериализовать таблицы данных?
2. Это верно. Сериализация poco происходит автоматически, вам просто нужно использовать правильный сериализатор
Ответ №2:
Если вы используете обычную таблицу данных, вы в конечном итоге получаете волшебные строки везде (даже если вы используете константы). Код для извлечения значений оказывается неуклюжим и подверженным ошибкам, в основном потому, что в конечном итоге вам приходится предоставлять данные (имена, выражения и т.д.) Там, Где вы действительно пытаетесь выразить код.
Каждый раз, когда вы вызываете DataTable.Select or DataTable.Sort или обращаетесь к DataRow индексатору, представьте, насколько меньше путаницы — и меньше вероятности ошибки — было бы, если бы вы использовали строго типизированную модель. Конечно, это может быть строго типизированный набор данных, но даже тогда я нахожу, что с POCOs обычно меньше проблем.
Кроме того, для тестирования кода в POCOs обычно требуется меньше ресурсов, чем в DataTables.
Комментарии:
1. Похоже, что POCOs превосходят. Зачем кому-то вообще понадобилось использовать таблицы данных? Являются ли они просто пережитком прошлого?
2. @TheMuffinMan: Не совсем… если вам на самом деле не нужно ничего делать с данными, кроме отображения их, например, в виде таблицы, проще просто использовать
DataTable. Или если вы используете запросы с динамической формой. Если вы привыкли к Json.NET это похоже на использованиеJObjectвместо десериализации в определенный класс.3. @TheMuffinMan напишите класс, который может представлять файл csv, но иметь более 1 файла, он же Excel с таблицами…. итак, строки, проверка, столбцы, проверка, хорошо, теперь как вы храните столбцы неизвестных типов …, пожалуйста, покажите мне, как «POCOs» может достичь этого. То, о чем вы говорите, это когда у вас есть известная структура данных / типов. создан csv mapper, в котором csv является динамичным и гибким. так что нет, они не превосходят, они используются в разных ситуациях.
Ответ №3:
Если вы используете объекты вместо таблиц данных, вы получаете строго типизированные результаты и делаете код, использующий данные, намного чище. Вам не нужно будет иметь всевозможные строки, чтобы получить доступ к тому, что должно быть просто свойством объекта.
Кроме того, если вы используете инструмент ORM, такой как NHibernate, вы можете сопоставлять данные из базы данных непосредственно с вашими объектами без необходимости вручную обращаться к базе данных и иметь дело с SqlCommands и т.д..
Ответ №4:
Это отделяет вашу бизнес-логику от ваших уровней сохраняемости.
Таким образом, ваш объект ‘Dog’ и большая часть кода, который его использует, могут просто заботиться о Dogs и Doginess и не беспокоиться о том, какой вид доступа к данным моден на этой неделе.