Asp.Net GridView: хорошо или плохо / Какие типы данных использовать для привязки?

Question

Итак, этот вопрос может быть немного расплывчатым, но у меня есть постоянные дискуссии по этому поводу:

При разработке страницы Asp.Net, часто вы можете просто захотеть бросить быстрый и грязный GridViewна странице.Когда вы идете по этому маршруту, у вас есть различные опции источника данных (я обычно использую ObjectDataSource, привязанный к бизнес-объекту), и вы также можете привязывать вручную.

Я видел много вариантов того, какие типы данных могут автоматически предоставлятьФункциональность сортировки в сетке.Я видел, как люди буквально переводили свои пользовательские коллекции POCO в DataTables в своих бизнес-объектах, чтобы GridView могли легче поддерживать эти типы поведения.

Вы действительно можете получить множество различных поведений из GridView, обрабатывая всесамих доступных событий (OnSorting, OnUpdating и т. д.), и в конечном итоге они могут быть сильно настроены.Несмотря на то, что это так, вы можете столкнуться с подлыми другими небольшими проблемами, такими как отсутствие возможности использовать клавишу «Ввод» для автоматического выполнения операции обновления для данной строки.Это связано с тем, что кнопка по умолчанию на странице может находиться за пределами GridView, а ASP.Net позволяет указывать только кнопку по умолчанию для данной панели и не учитывает это поведение для кнопок внутри шаблонов GridView.Обратите внимание, это всего лишь пример.Также, конечно, возникает вопрос о том, должна ли страница возвращаться к источнику данных после каждой операции фильтрации, или же весь источник данных должен кэшироваться в ViewState на странице, чтобы разрешить фильтрацию / сортировку без поездки в БД....

Итак, вот главный вопрос: разумно ли использовать GridView на странице, где вам нужны базовые операции CRUD, даже если это может означать преобразование ваших пользовательских коллекций в какой-то тип DataTable?Следует ли полностью отказаться от GridView в пользу чего-то другого, например DataList, ListView или Repeater?Последние параметры, безусловно, могут быть более гибкими, но означает ли это, что для каждого сценария необходимо перестроить функции выбора строк по умолчанию, редактирования, сортировки и т. Д., Которые должны быть перестроены?

Любые разумные мысли на эту тему приветствуются!

Answer 1

Мне просто пришлось снова использовать gridviews впервые за много лет, я помню, почему я не использовал их так долго. Gridview отлично подходят для того, для чего они предназначены на базовом уровне, но, к сожалению, большую часть времени конечному пользователю понадобится больше функциональности, и именно здесь они начинают терпеть неудачу. Несмотря на то, что вы можете настраивать и расширять виды сетки, как вы заметили, это открывает совершенно другую банку червей. Поэтому я стараюсь использовать сетки в качестве инструмента для генерации отчетов. Что-то помимо этого, и я, кажется, трачу некоторое время на то, чтобы настроить и настроить его, чтобы получить что-то близкое к тому, что мне нужно, что это просто не стоит усилий.

Answer 2

Я только что понял, что этот вопрос все еще висит здесь, поэтому вот мой вывод на эту тему:

Я все еще думаю, что полезно встроить стандартный элемент управления GridView в страницу ASP.Net. Я все еще думаю, что неразумно обрабатывать каждое событие сортировки в выделенном фрагменте кода для страницы, поскольку это создает настоящий кошмар для обслуживания и отбрасывает ваш код взаимодействия с данными и бизнес-логики слишком близко к «представлению» в терминах MVC. .

Что я не знал, так это то, насколько тесно интегрированы GridView с различными элементами управления DataSource. Я знал, что при правильных обстоятельствах GridView при подключении к SqlDataSource будет выполнять различные операции CRUD непосредственно с базой данных, применяя свои собственные методы сортировки и разбиения на страницы, но это плохо переводилось на использование ObjectDataSource с бизнес-объектом - или так Я думал.

Оказывается, что в элементе управления ObjectDataSource есть три важных свойства, которые позволяют ему динамически предоставлять метод бизнес-объекта с параметрами сортировки и подкачки.

Это следующие свойства: SelectCountMethod, SortParameterName, StartRowIndexParameterName и MaximumRowsParameterName. Эти свойства в сочетании с требуемым флагом EnablePaging изменяют ожидаемую подпись вашего метода «Выбрать» и запускаются автоматически, используя ваш метод SelectCount, чтобы получить общее возможное количество возвращаемых записей, используя размер страницы вашего GridView и текущее состояние, чтобы определить, с чего начать. ваш набор результатов и количество элементов для выбора после этой начальной точки, и он начинает отправлять выражение сортировки в стиле SQL вместе со всеми вызовами вашего метода Select.

В целом, это был большой шаг вперед, но если вы используете пользовательские коллекции классов POCO или выполняете запросы к объектному контексту LinqToSql или EF, вам все равно придется перевести параметры StartRowIndex и MaximumRow в некоторую форму комбинацию Skip (). Take () (которая довольно проста и очевидна) и переводит выражение Sort в какой-либо тип запроса к контексту вашего объекта или коллекции в памяти.

Я не буду вдаваться во все подробности, но в основном решение состоит в том, чтобы использовать возможности и отражение dynamic-Linq для определения выражения запроса для вашей коллекции в памяти, используя только строку сортировки.

Строка сортировки будет содержать имя поля и направление сортировки (только если по убыванию) в типичном формате «FieldName DESC». Анализируя эту строку, вы можете использовать отражение для вашего конкретного типа, чтобы создать выражение, используя соответствующее имя свойства из строки сортировки.

Основным преимуществом здесь является то, что с помощью всего лишь нескольких настроек метода select и использования специального расширения Linq для обработки преобразования строки сортировки в лямбда-выражение вы можете заняться обычным делом, подключив GridViews к бизнесу. логика со встроенной сортировкой и функциональностью подкачки.

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