Использование элемента DataSet в .NET 6

Здравствуйте. До этого работал с приложениями на .NET Framework, сейчас пробую перейти на .NET 6. Столкнулся с проблемой, что в .NET 6 не могу найти элемент DataSet. Всегда использовал его, чтобы задать поля таблиц базы данных и отображать их в таблице GridControl, так можно было удобно их редактировать и размещать как нужно в конструкторе таблицы. Сейчас не пойму как это делать. Как найти элемент DataSet или на что его заменить?

0

Сообщение от XIST а какая версия VS

2022

Добавлено через 10 минут

Сообщение от wizard41 Чем присутствие его в конструкторе облегчает жизнь? Ты не можешь объявить датасет в коде руками?

Я акцентирую внимание именно на управлении таблицей GridControl, куда загружаются данные из DataSet. Конструктор GridControl позволяет вертеть полями из DataSet как угодно, группировать, переименовывать, менять местами, скрывать лишние. то есть настраивать отображение таблицы в приложении. Облегчает тем, что в конструкторе в DataSet можно было добавить поле и оно автоматически появлялось в том же GridControl или в отчете FastReport. Всё визуально было видно, а через код придется вручную добавлять или удалять поля там, где это требуется. Тут, возможно, и придется переходить на Dapper или EF, чтобы хоть какаято визуализация была в виде класса таблицы базы данных.

0

Сообщение от 1inkin1 Облегчает тем, что в конструкторе в DataSet можно было добавить поле и оно автоматически появлялось в том же GridControl

ну так работайте программно

1

1inkin1, или я не очень понимаю о чем речь, или у тебя заблуждения. Все то же самое спокойно делается в тех же классах-моделях - источников данных для грида.
Ту "невидимую" логику пропишет конструктор все равно, причем так, как считает нужным. И это далеко не всегда практично.
Своя модель крутится-вертится гораздо эффективнее.
В конце концов, никто не отговаривает менять что-то; дело привычки. Лишь предлагают тебе более лучшие практики, на которые давно перешли 9 из 10 программистов. И никаких проблем не испытывают.

1

Сообщение от XIST ну так работайте программно

придётся

Сообщение от wizard41 В конце концов, никто не отговаривает менять что-то; дело привычки

получается, что ставят перед фактом

Конечно, я пристрастен в этом вопросе, так как привык к определенным методам. Спасибо всем за ответы, буду пробовать делать по новому.

0

Сообщение от 1inkin1 Я, конечно, не продвинутый программист и мне не особо понятны преимущества использования Dapper или EF. Как я написал, используя DataSet в конструкторе, я мог в него забить все нужные таблицы и поля к ним, привязать там же в конструкторе формы BindingSource к нужной таблице в DataSet, а к BindingSource привязать таблицу GridControl и настроить ее отображение. При подключении базы данных, DataSet сразу наполнялся табличными данными и ими можно было управлять и через BindingSource и через GridControl. Нужно добавить или удалить поля - редактируешь DataSet и изменения сразу появляются в GridControl. Dapper и EF же при подключении дают список данных, с которыми тот же BindingSource не работает полноценно, поэтому приходится сначала конвертировать список в таблицу. Да и при внесении изменений класс с полями таблицы нужно перезагружать DataSource подключение в GridControl, чтобы состав полей обновился. В общем, не особо хочется всё переделывать, но раз элемент DataSet удалили, видимо, придется.

Прикол в том, что "быстро накидать" можно и без DataSet. C датасетом в дизайнере ты завязываешься на специализированные возможности студии. Вот этот момент отломали и всё, ты потерялся) Это во-первых. Во-вторых, датасет нетиизированный. Пойди пойми какие там подразумеваются поля и каких они типов. При этом ты всё равно в дизайнере полезешь человекочитаемые имена колонкам грида прописывать. Т.е. объём писанины и работы в целом не меньший, чем напрямую, без дизайнера и датасета.

Ну и вот этот вот аргумент, про "редактирование полей прямо в гриде"... Он работает только в каких-то совершенно тривиальных случаях. В более реалистичных между грибом и базой уже будет какая-то бизнес-логика, а само выгребание данных уже может быть с джойнами и преобразованием данных, из чего DataAdapter тебе уже не сгенерирует Insert\Update команды и надо будет руками это реализовывать, что уже сложнее будет, чем прямая работа, без датасета.

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

А использовать Dapper или EF - тут каждый сам решает. Можно и руками с ADO.NET возиться, если есть весомые основания (обычно, из нет). Это не отменяет мою позицию относительно использования датасетов, да ещё и в связке с дизайнером...

2

Сообщение от Usaga датасет нетиизированный. Пойди пойми какие там подразумеваются поля и каких они типов. При этом ты всё равно в дизайнере полезешь человекочитаемые имена колонкам грида прописывать.

Это не так - в Dataset для каждого поля устанавливался тип и заголовок, которые потом наследовались тем же GridControl, поэтому в дизайнере таблицы оставалось только разместить уже готовую колонку в нужном месте.

Сообщение от Usaga Если что-то серьезнее, то этот механизм больше проблем создаёт, чем решает.

Это я в целом осознал. Просто для меня, как не особо глубоко знакомого с работой этих методов, наверное, важнее было именно удобство использования и для моих задач Dataset и адаптер вполне подходили. Но раз теперь не получится пользоваться по старинке, то буду менять подход. С EF уже начал знакомиться, наверное, с ним и продолжу работать.

0

Сообщение от 1inkin1 Это не так - в Dataset для каждого поля устанавливался тип и заголовок, которые потом наследовались тем же GridControl, поэтому в дизайнере таблицы оставалось только разместить уже готовую колонку в нужном месте.

Этот тип существует только в рантайме, а не в коде. Можно сгенерировать\дописать руками геттеры\сеттеры для свойств. Но это ещё хуже, так как что тогда мешает сделать обычный класс?

Сообщение от 1inkin1 С EF уже начал знакомиться, наверное, с ним и продолжу работать.

Я не настаиваю на EF. Вообще никак не настаиваю. Я настаиваю на работе с пользовательскими классами, описывающих выборки из базы или параметры запросов. А как ты объекты этих классов будешь получать тут роли не играет. Это может быть прямая работа с ADO.NET, через MicroORM типа Dapper или PetaPOCO, или "взрослые" ORM типа Linq2Db и EF. Не важно. Главное типизация.

По поводу EF'а сразу хочу предупредить, чтобы ты очень осторожно относился к его механизму Change Tracker и выгребнию данных в виде коллекций исходных сущностей и байндинга их к гриду. Речь о таком. Это тоже фиговая практика. Даже хуже, чем работа с датасетами. Старайся избегать её. И налегать на "проекции" (сущности\коллекции сущностей получаемые методом IQueryably.Select). Магии меньше, но работать будет гораздо лучше.

2