Почему мы все еще используем DataSets в .NET?

DataSets были одной из больших вещей в .NET 1.0, и даже сейчас, когда я использую .NET 3.5, мне все еще приходится использовать их... особенно, когда мне приходится вызывать сохраненный процесс, который возвращает набор данных, который я тогда в конечном итоге придется вручную преобразовать в объект, чтобы упростить работу.

Мне никогда не нравились DataSets, и они находили их раздражающими для использования... и в результате я имел тенденцию хранить свои знания о них до минимума (возможно, очень плохо!). Я также предпочитаю быстро преобразовывать их в объект или список объектов, поэтому я могу легко манипулировать ими в своем коде.

Имеют ли данные DataSets их использование по дате? С появлением маркеров O/R, таких как NHibernate, мне интересно, будут ли DataSets вымирать или все еще есть место для них? На данный момент я разорван между тем, следует ли мне отложить время, чтобы пересмотреть DataSets и узнать, как правильно их использовать или зайти на карты O/R на 100% и полностью удалить DataSets.

Предоставляют ли DataSets что-либо, что технологии, такие как NHibernate и LINQ и т.д., не могут? Если нет, то почему мы все еще используем их?

Ответ 1

Я никогда не использовал DataSet правильно (подключен к SQL Server), но он был полезен для конкретной потребности один раз. Я обнаружил, что DataSet и DataView являются довольно удобными и функциональными базовыми классами для реализации уровня данных /BLL, пока я не смогу сделать что-то действительно продуманное. Там есть много функциональных возможностей, о которых вы должны знать, если ничего другого.

Ответ 2

К лучшему или худшему, ответ - это простота. Когда 2.0 Framework вышла, и TableAdapters были включены в этот процесс, стало смешно легко получить ваше базовое приложение типа CRUD или даже на первой странице, показывающей данные. Просто подключитесь к своему разъему, перетащите таблицу (-ы), и структура была на месте, включая ссылки на внешние/первичные/уникальные ключи. Нужно выполнять обновления по этим данным? Используйте мастер, укажите существующие процедуры или дайте мастеру создать для вас специальные или хранимые процедуры.

И все готово, подключитесь к GridView, и вы можете быстро делать много вещей: прибегать к услугам, требовать, редактировать несколько записей при отключении и обновлять в одиночном или навалом. Такое удобство трудно упустить, когда вы работаете над проектами, которые хотят быстро выполнить. Плюс наличие вещей в этом родном формате "DataTable" становится удобным для XML-хенниганов, если это то, что вам нужно, поскольку модель DataSet использует XML под капотом для многих вещей.

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

Увидев, что новый сайт/проект Dynamic Data Service построен из LINQ to SQL или LINQ to EF, я думаю, что прилив может наконец измениться на более новую модель.

Ответ 3

Я думаю, что самая большая проблема с наборами данных заключается в том, что они в основном побуждают вас создавать dbms в памяти. Мне нравится, как Linq/сущности покрывают ваши потребности в данных, и они полагаются на стандартные классы коллекций .Net и дженерики для работы.

Тем не менее, я бы не отказался от возможности динамически читать нетипизированные данные и применять отношения и т.д. в памяти, которые все еще очень мощные функции в зависимости от вашей ситуации.

Ответ 4

Я думаю, что я нахожусь в одной лодке: я очень редко использую наборы данных, и я, конечно же, не претендую на то, чтобы быть экспертом по модели адаптера (я думаю, что "Fill" - единственный метод, который я действительно использовал в производстве), но иногда они используют некоторые виды использования. Например, если вам нужно выполнить какой-то специальный SQL-код, вы не можете предсказать схему (и поэтому ORM не поможет), и вы не хотите связываться с IDataReader и т.д. Для простого, небольшого набора данных.

Помимо этого (то есть большую часть времени), я предпочитаю стандартные классы - ORM или manual.

Ответ 5

Наиболее популярным использованием DataSets является создание копии базы данных в памяти. Я нашел, что я никогда не использовал его для этого, даже с .NET 1.0. Отключенная модель всегда была неприемлемой в многопользовательской среде.

Если вы вообще игнорируете реляционные базы данных, все еще используются для DataSets:

Если вы пишете приложение форм, которое должно загружать и сохранять данные в файл, вы можете определить типизированный DataSet, а затем загрузить и сохранить его с помощью класса XmlDataDocument.
Crystal Reports может генерировать отчеты, читая данные в памяти. Вы можете создать типизированный DataSet только для одного конкретного отчета и использовать язык .NET для написания сложной бизнес-логики, чтобы заполнить этот DataSet. Это избавляет вас от реализации бизнес-логики с помощью функций Crystal Reports (что может быть очень сложной задачей).
Вы можете прикрепить DataGridView к DataSet с одной строкой кода, чтобы получить дрянной пользовательский интерфейс, который, тем не менее, может сделать нужную работу. Хорошо для таких вещей, как встроенные инструменты тестирования. (Не достаточно для отправки клиенту).

Ответ 6

3 причины, похожие на наборы данных:

Для winforms они поддерживают привязку данных/фильтрацию, большинство ормсов не
Многие сторонние инструменты (инструменты отчетности esp) встроены в поддержку наборов данных/наборов, а не для простых объектов.
Во время отладки вы можете щелкнуть правой кнопкой мыши по заполненной таблице и просмотреть содержимое. Это настоящая экономит время.

В целом у них много функциональности. Однако мне не нравятся адаптеры. Обычно я пишу свои собственные адаптеры баз данных.

Ответ 7

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

Ответ 8

Я использую Typed DataSets для очень низкого рычага. Я знаю, что это не так хорошо, но попробуйте объяснить это крупным снимкам.
Поэтому вместо того, чтобы менять мир и внедрять какой-то инструмент не-microsoft oss (или, наконец, перейдя с .net2.0 на 3.5 и используя l2s или ef), я просто использую набор данных для хранения результатов запроса и легко привязываю их к сеткам, текстовые поля и выпадающие списки, если необходимо. Я нахожу способность позже использовать что-то вроде

MyDataSet.MyDataTableRow row = // whatever
if (row.Price > 100) // do something

очень полезно.

Ответ 9

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