Кто на самом деле использует DataGrid / GridView / FormView / и т. Д. В производственных приложениях?

Любопытно, чувствуют ли другие то же самое, что и я. Для меня такие элементы управления, как datagrid / gridview / formview / и т. Д. отлично подходят только для презентаций или демонстраций. Потратить время и настроить эти элементы управления, переопределить их поведение по умолчанию (подключение к их глупым событиям и т. Д.) - большая головная боль. Единственный элемент управления, который я использую, - это ретранслятор, поскольку он предлагает мне наибольшую гибкость по сравнению с другими.

Короче говоря, они в значительной степени бесполезны.

Я бы предпочел сплести свой собственный html / css, использовать свои собственные запросы на подкачку.

Опять же, если вам нужно быстро открыть страницу, эти элементы управления великолепны (особенно, если вы пытаетесь убедить людей в простоте .NET разработки).

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

Ответов (25)

Никогда не пользовался. Полностью согласен, это раздутое ПО. Обычно я использую ретранслятор с настраиваемыми элементами управления, которые я сделал.

Тот, кто думает, что никто не использует * элементы управления сеткой, явно никогда не работал с внутренними корпоративными веб-приложениями.

Мы используем Infragistics UltraWebGrid + LinqDataSource в наших приложениях для интрасети.

Это дает нам ajax, сортировку, фильтрацию, пейджинг на всей стороне сервера.

«Экспорт в Excel» также является отличной особенностью.

У нас 5000+ пользователей, много данных, отличная производительность.

Я пытаюсь взглянуть на все это в контексте. У меня есть страница с красивым gridview (отображает 10 строк за раз, 6 столбцов, сортировку и разбиение на страницы), и если я просто посмотрю на таблицу html, созданную вместе с viewstate, я вижу только 29k кода .

Действительно ли 29k по сравнению с 18k при использовании ретранслятора или списка стоит всех усилий в наше время широкополосной связи?

Я лично придерживаюсь gridviews, однако дизайнер, с которым я работаю, иногда недоволен попытками стилизовать его с помощью CSS.

Просто читаю твои посты. Я согласен, что PHP проще, чем asp. но я только начал использовать визуальную студию для форм и сеток. Не может быть намного проще для программистов на vb или C#. У ASP по-прежнему возникают проблемы с загрузкой больших файлов. PHP это совсем несложно. Я запускаю PHP под IIS 7.5

Я действительно широко использовал GridView для административной консоли. Я даже создал настраиваемый DataFieldControl, который устанавливает текст заголовка поля и выражение сортировки на основе поля данных, создает строку Insert внизу и автоматически собирает значения в строке и перенаправляет их методу вставки источника данных, а также генерирует список если указан дополнительный источник данных списка. Это было действительно полезно, хотя на создание этого потребовалось огромное количество времени.

У меня также есть другой элемент управления, который будет генерировать новую форму данных на основе метаданных полей, когда нет записей (в EmptyDataTemplate).

<asp:GridView ...>
 <Columns>
       <my:AutoField HeaderText="Type" 
                      DataField="TypeId"
                      ListDataSourceID="TypesDataSource"
                      ListDataTextField="TypeName" />          
  </Columns>

    <EmptyDataTemplate>
        <my:AutoEmptyData runat="server" />
    </EmptyDataTemplate>

</asp:GridView>

Я в значительной степени пишу свой собственный HTML - я использую ListView и Masterpages, но на самом деле больше не использую элементы управления. Между прочим, мой ListView смеется над твоим глупым старым повторителем.

Однако раздутое ПО - не обязательно плохо. Если мне нужно было создать приложение для интрасети с небольшим объемом, я бы предпочел заплатить менее опытному разработчику за перетаскивание элементов управления, чем за HTML-тиддлер (например, вы или я) за создание каждого тега. Определенно есть место для быстрого и простого подхода. Какова стоимость «раздутого ПО» в этом сценарии, если код, основанный на элементах управления, написан в удобной для обслуживания манере? Часто для соединения элементов управления требуется меньше специального кода, что означает простоту обслуживания.

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

Мне очень нравится телерик радгрид. Их продукт не из дешевых, но вы получаете множество элементов управления и функций. И поддержка привязки данных довольно хороша, как в простом способе привязки источника данных asp.net, так и в более настраиваемом способе обработки событий-привязки-данных.

Я читал ваши посты, ребята, и от этого я почувствовал себя тупым.

Я имею в виду, что в каждом приложении, которое я создал там, где я работаю, есть хотя бы один datagrid / gridview. И у меня не было ощущения, что я чего-то упускаю.

Конечно, я считаю datagrid / gridview раздутым, но так ли отвратительно их использовать?

В моей компании мы везде используем сетки, в основном ComponentArt Grid ( http://www.componentart.com/ ). Да, это раздутое ПО, но вы получаете множество функций, которые было бы не очень интересно изобретать заново: сортировка, разбиение по страницам, группировка, переупорядочение столбцов, встроенное редактирование, создание шаблонов (на стороне сервера и на стороне клиента). Клиентские API тоже хороши.

Каждое приложение, которое мы разрабатываем в моей компании, имеет сетки (все приложения находятся за брандмауэром). Это включает как веб-приложения, так и приложения Winform. Для веб-приложений это хорошая старая сетка с настраиваемой сортировкой для приложений winform, которые мы используем сетку Janus. Я пытаюсь заставить разработчиков / пользователей подумать о лучших пользовательских интерфейсах, но это сложно изменить. Я должен признать, что это все же лучше, чем альтернатива пользователям, создающим свои «собственные» приложения с Access, которые мне затем нужно будет поддерживать!

Мне нравится элемент управления GridView, и я использовал его в нескольких настраиваемых модулях DotNetNuke для веб-сайта моей компании. Во-первых, использование встроенных элементов управления означает меньшее количество зависимостей, о которых нужно беспокоиться. И как только я настроил его так, как я хотел, я в основном скопировал код на другие страницы, и мне оставалось лишь внести незначительные изменения.

Я обнаружил, что существует так много опций с современными элементами управления сеткой (Infragistics, Telerik и т. Д.), Что настройка сетки занимает больше времени, чем что-либо еще. Элементы управления MS довольно просты, но они могут делать все, что угодно.

Это одно из преимуществ asp.net. До недавнего времени я их ненавидел, но чем больше вы их используете, тем легче они становятся, когда вы узнаете, какие настройки вы должны изменить для каких экземпляров. В основном мне нравится вид формы и список, вид сетки все еще требует некоторой доработки.

Использование таких элементов управления, как GridView, отлично подходит для простых приложений. Даже если вы ниндзя, занимающийся серверной HTML-скобкой, они могут значительно упростить разработку простых вещей. Проблема в том, что они обычно рано или поздно начинают обнаруживать свои недостатки, и вам все равно приходится тратить время на их настройку. Но, по крайней мере, вы можете быстро встать и начать движение.

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

В любом случае, дело в том, что готовые компоненты - это хорошо . Они помогают. Но, как обычно, это зависит от того, что вам нужно от них.

Я давно об этом думал. Похоже, здесь все согласны с тем, что элементы управления сеткой - это раздутое ПО. Но может ли кто-нибудь окончательно назвать стоимость использования этих элементов управления? Не отправляется ли в браузер чрезмерный HTML-код? Слишком много ресурсов потреблено на сервере? Генерирует ли HTML-таблицу быстрее (при условии, что она хорошо написана)?

Помимо проблемы с раздутым ПО, я часто попадал на мель, когда требования пользовательского интерфейса расширялись, чтобы включить функции, выходящие за рамки стандартных элементов управления. Например, в ранних версиях ASP.Net мне было сложно помещать изображения в заголовки столбцов. И я считаю, что по-прежнему сложно добавить вторую строку заголовка верхнего уровня, охватывающую несколько столбцов. В какой-то момент становится действительно сложно бороться с управлением для достижения желаемого эффекта. И это неприятно, если вы знаете, какой HTML вам нужен, но вы просто не можете заставить элемент управления делать это.

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

Хотя в этом нет никаких сомнений. Трудно превзойти модные элементы управления сеткой для быстрой разработки, если вы можете просто жить в пределах их ограничений.

В моих корпоративных интранет-проектах без гридов не обойтись. Они являются основой для простой отчетности на платформе веб-форм ASP.NET.

Простота дизайна Вставьте сетку на страницу. Вставьте объекты BoundField для простой привязки. asp:HyperlinkField для легкого связывания.

Привязка

Вы можете связать сетки несколькими способами:

  • совокупность объектов ( List, ArrayList, Hashtable, или любой набор простых)
  • SqlDataReader в вашем коде программной части (yikes, это потребует SQL на вашем уровне представления)
  • SqlDataSource(укажите сохраненную процедуру. Все столбцы в наборе результатов сопоставляются непосредственно со столбцами сетки. Это очень быстро и грязно, если отчет не имитирует хорошо ваш объект домена, то есть суммирования разных вещей.)
  • objectDataSource (привязка к методу в вашем BL)

Для тех, кто может вызвать SqlDataSource и ObjectDataSource, вам не всегда нужно объявлять их в ваших .aspx.cs или .aspx.vb. Я не защищаю их здесь, просто указываю на возможности.

Я не думаю, что вы можете сбрасывать со счетов преимущества RAD встроенного GridView и других сторонних гридов. Типы руководителей любят и хотят табличные данные.

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

If you go near DataGrids or GridViews with a 10-foot pole on a public facing web site then you HAVE to use the CSS friendly Control Adapters. (At this point you might find it easier just to do it in the Repeater.) Prior to Control Adapters being available I would have considered these controls broken out of the box.

I find that too many .NET developers do not have a good understanding of design, accessibility, CSS, javascript, standards etc. which is why they succumb to GridViews, ObjectDataSources etc.

Я думаю, вам нужно научиться использовать GridView, прежде чем осуждать их. Я их широко использую. Сначала было немного сложно разобраться в некоторых вещах, но теперь они необходимы.

GridView в UpdatePanel с AJAX CRUD и разбивкой на страницы работают молниеносно. Одна из более крупных систем, настроенных таким образом (для внутреннего / внешнего приложения), имеет базу данных среднего размера в бэкэнде. Есть много полей nvarchar (2000), и переходы и обновления великолепны.

В любом случае, если вы написали свою собственную версию отображения данных, вы можете продолжить ее использовать, если она работает. (Тот же аргумент можно привести для написания собственного компилятора, написания собственной версии HTML, написания собственной версии двоичных файлов доступа к данным ...) Преимущество использования GridView заключается в том, что есть много людей, которые с ним знакомы, и что MSFT абстрагировала / смоделировала класс, чтобы делать множество вещей, которые раньше приходилось делать вручную.

GridView - прекрасный и очень мощный элемент управления, который хорошо работает с CSS или темой. Единственное, что меня раздражает, это то, что свойство VirtualCount было удалено, когда старый DataGrid 1.1 был заменен на GridView в asp.net 2.0, и это было полезно для реализации настраиваемого разбиения по страницам. Однако то же самое можно сделать с помощью адаптеров данных.
Хотя работа с повторителями, возможно, более понятна, и вы полностью контролируете визуализированный html, я бы не рекомендовал идти этим путем, потому что это сложнее реализовать и поддерживать.

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

Я в значительной степени отказался от сеток, когда начал проектировать, исходя из пользовательских историй, а не из требований таблиц базы данных. И никогда не редактируемые сетки. Старый способ заключался в том, как мы заставляли пользователей выполнять ввод данных / обслуживание таблиц для наших систем, и он никогда не соответствовал их рабочему процессу - любая реальная работа заканчивалась переходом от одной основной / дочерней формы к другой.

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

Исключение составляют аналитические приложения. Но их относительно немного, и они в основном предназначены только для чтения.

Я тоже хотел бы увидеть развернутый ответ о том, почему GridView и др. Считаются «раздутым ПО». Я широко использовал GridView, а также сторонние продукты (Telerik и т. Д.) И обнаружил, что для большинства внутренних и некоторых внешних проектов они отлично работают. Они быстрые, простые в использовании, настраиваемые - и САМЫЕ ЛУЧШИЕ - я могу передать их тому, кто знает GridViews, который затем может легко продолжить с того места, где я остановился. Если бы мне пришлось вручную кодировать все многочисленные приложения / элементы управления, накладные расходы на то, чтобы следующий человек понял, что происходит, были бы огромными даже в самых лучших обстоятельствах.

Что касается меня, то я вижу, что некоторые сторонние продукты являются раздутыми программами (но все же иногда полезными), но простой GridView, который я обнаружил, довольно быстр с умеренными запросами.

Я никогда раньше не использовал стандартную сетку WinForms, но на моей последней работе мы широко использовали ComponentOne FlexGrid, и она прекрасно работала. Попытки получить все необходимые настройки по-прежнему вызывали некоторые неудобства, но в целом это сэкономило нам массу времени и дало прекрасные результаты.

В настоящее время я работаю с Silverlight 3 и RIA Services, и я не могу себе представить, что пытаюсь создать то, что мы делаем, без элементов управления DataGrid и DataForm. Сэкономленное время намного перевешивает любые накладные расходы.

Такие компоненты, как GridView / FormView / DataGrid, следуют правилу 80/20.

Это означает, что в 80% случаев, когда вы используете их для простых целей, они выполняют свою работу и их чрезвычайно легко реализовать.

Но в 20% случаев вы будете пытаться построить что-то сложное (или странное), и вам придется перепрыгивать через дюжину обручей и изменять код разными способами, чтобы попытаться реализовать решение.

Уловка состоит в том, чтобы узнать, является ли проблема проблемой 80 или проблемой 20, если вы можете определить проблему на ранней стадии, вам гораздо лучше написать код с нуля самостоятельно и отказаться от «экономии времени».

Я широко использую их в корпоративной среде, в которой работаю, и я работаю с одним из них прямо сейчас. Люди, которые не используют их, напоминают мне всех тех разработчиков «Я создал это с помощью Блокнота» прошлых лет. Какой смысл использовать asp.net, если вы не собираетесь экономить время?