Кто на самом деле использует DataGrid/GridView/FormView/etc в производственных приложениях?
Любопытно, если другие чувствуют то же самое, что и я. Для меня, такие элементы управления, как datagrid / gridview / formview / etc. отлично подходят для презентаций или только для демонстрации. Потратить время и настроить эти элементы управления, переопределить их поведение по умолчанию (подключиться к их глупым событиям и т. Д.) - большая головная боль. Единственный элемент управления, который я использую, - это повторитель, поскольку он предлагает мне наибольшую гибкость по сравнению с остальными.
Короче говоря, они в значительной степени вздор.
Я предпочел бы сплести свой собственный html / css, использовать свои собственные пользовательские пейджинговые запросы.
Опять же, если вам нужно быстро открыть страницу, эти элементы управления хороши (особенно если вы пытаетесь убедить людей в легкости .NET развитие).
Я должен быть в меньшинстве, иначе MS не потратила бы столько времени на разработку этих типов элементов управления...
26 ответов
Любой, кто думает, что никто не использует *Grid, явно никогда не работал во внутреннем корпоративном веб-приложении.
Я в основном пишу свой собственный HTML - я использую ListView и Masterpages, но больше не пользуюсь элементами управления. Кстати, мой ListView смеется над твоим старым глупым ретранслятором.
Тем не менее, раздувание не обязательно плохо. Если бы мне нужно было создать приложение для интранета с небольшим объемом, я бы скорее заплатил менее опытному разработчику за перетаскивание элементов управления, чем за тиддлера HTML (такого как вы или я), чтобы создать каждый тег. Там определенно есть место для быстрого и простого подхода. Какова стоимость "раздутого ПО" в этом сценарии, если код, основанный на элементах управления, написан в поддерживаемом виде? Зачастую для подключения элементов управления требуется меньше специального кода, что означает простоту обслуживания.
Единственное, с чем я не согласен - практически независимо от приложения - это создание собственных пейджинговых запросов. Возможно, вам нравится делать такие вещи, но в этом нет абсолютно никакой коммерческой ценности. Существует несколько инструментов DAL профессионального уровня, которые обычно пишут более удобные и быстрые запросы, чем большинство разработчиков. Даже если вы с любовью создадите идеальный запрос подкачки, он не будет в курсе изменений в схеме, если вы не будете бросать часы после него. Я думаю, что лучше использовать эти часы, чтобы создать легковесную систему и использовать эти часы для мониторинга и устранения определенных узких мест, а не для немедленного перехода к слою "язык ассемблера баз данных".
Я читал ваши посты, ребята, и это заставило меня чувствовать себя глупым.
Я имею в виду, что в каждом приложении, которое я сделал, где я работаю, есть по крайней мере одна таблица данных /gridview. И у меня не было ощущения, что я что-то упустил.
Конечно, я считаю, что datagrid/gridview довольно раздутый, но так ли это отвратительно?
Я думаю, что вам нужно научиться использовать GridViews, прежде чем осуждать их. Я использую их широко. Сначала было немного сложно понять некоторые вещи, но теперь они необходимы.
GridViews в UpdatePanel с AJAX CRUD и нумерацией страниц работают молниеносно. Одна из более крупных систем, настроенных таким образом (для внутреннего / внешнего применения), имеет небольшую базу данных в бэкэнде. Существует много полей nvarchar(2000), и переходы и обновления великолепны.
В любом случае, если вы написали свою собственную версию отображения данных, вы можете продолжать использовать ее, если она работает. (Можно привести тот же аргумент в пользу написания собственного компилятора, написания собственной версии HTML, написания собственной версии двоичных файлов доступа к данным...) Преимущество использования GridView состоит в том, что есть много людей, которые знакомы с ним и что MSFT абстрагировал / смоделировал класс, чтобы сделать много вещей, которые мы обычно делали вручную.
Каждое приложение, которое мы разрабатываем в моей компании, имеет сетку (все приложения находятся за брандмауэром). Это включает как веб-приложения, так и приложения Winform. Для веб-приложений это хороший старый вид сетки с настраиваемой сортировкой для приложений winform, в которых мы используем сетку Janus. Я пытаюсь заставить разработчиков / пользователей думать о лучших пользовательских интерфейсах, но это сложно изменить. Я должен признать, что это все еще лучше, чем альтернатива пользователей, создающих свои "собственные" приложения с помощью Access, которые мне тогда нужно будет поддерживать!
Использование элементов управления, таких как GridView, отлично подходит для простых приложений. Даже если вы серверный HTML-ниндзя, он может сделать разработку простых вещей гораздо менее трудоемкой. Проблема в том, что они, как правило, начинают со временем выявлять свои недостатки, и вам в конечном итоге приходится тратить время на их доработку. Но, по крайней мере, вы можете быстро встать и начать.
Например, подкачка по умолчанию в GridView не поддерживает подкачку в самой базе данных (вам нужно загрузить все строки, прежде чем они будут разбивать их на страницы), поэтому, как только вы начнете ощущать повышение производительности, вам, возможно, придется подумать о развертывании свой или, возможно, лучше, найти более способный контроль сетки.
В любом случае, дело в том, что готовые компоненты хороши. Они помогают. Но, как обычно, это зависит от того, что вам нужно сделать.
Я на самом деле широко использовал GridView для административной консоли. Я даже создал пользовательский DataFieldControl, который задает текст заголовка поля и сортирует выражение на основе поля данных, создает строку "Вставка" внизу, автоматически собирает значения в строке и перенаправляет их в метод вставки источника данных, а также генерирует окно списка. если указан дополнительный источник данных списка. Это было действительно полезно, хотя огромные затраты времени на строительство.
У меня также есть другой элемент управления, который будет генерировать новую форму данных на основе метаданных полей, когда нет записей (в EmptyDataTemplate).
<asp:GridView ...>
<Columns>
<my:AutoField HeaderText="Type"
DataField="TypeId"
ListDataSourceID="TypesDataSource"
ListDataTextField="TypeName" />
</Columns>
<EmptyDataTemplate>
<my:AutoEmptyData runat="server" />
</EmptyDataTemplate>
</asp:GridView>
В моей компании мы используем сетки везде, в основном это ComponentArt Grid ( http://www.componentart.com/). Да, это раздутая программа, но вы получаете множество функций, которые было бы не так уж и интересно изобретать: сортировка, разбиение по страницам, группировка, изменение порядка столбцов, встроенное редактирование, создание шаблонов (на стороне сервера и на стороне клиента). Клиентские API тоже хороши.
Мы используем Infragistics UltraWebGrid + LinqDataSource в наших приложениях для внутренней сети.
Это дает нам ajax, сортировку, фильтрацию, пейджинг на всю серверную часть.
"Экспорт в Excel" также является убийственной функцией.
У нас более 5000 пользователей, много данных, отличная производительность.
Я широко их использую в корпоративной среде, в которой я работаю, и сейчас я работаю с ней. Люди, которые их не используют, напоминают мне обо всех тех разработчиках "Я построил это с помощью Блокнота" прошлых лет. Какой смысл использовать asp.net, если вы не собираетесь использовать экономию времени?
Я в значительной степени отказался от гридов, как только начал проектировать из пользовательских историй, а не из требований таблиц базы данных. И никогда не редактируемые сетки. Старый способ заключался в том, как мы принуждали пользователей выполнять ввод данных / обслуживание таблиц для наших систем, и они никогда не соответствовали их рабочему процессу - любая реальная работа в конечном итоге переходила от одной главной / дочерней формы к другой.
И пользователи так и не поняли - но они точно знали, что наши приложения труднее использовать, чем следовало бы.
Исключение составляют аналитические приложения. Но их относительно немного, и они в основном доступны только для чтения.
Они являются одним из преимуществ asp.net. До недавнего времени я ненавидел их, но чем больше вы их используете, тем легче они становятся, как только вы узнаете, какие настройки вы должны изменить для каких экземпляров. В основном мне нравится представление формы и просмотр списка, но gridview все еще нуждается в доработке.
Я также хотел бы видеть расширенный ответ о том, почему GridView и др. Считаются "раздутым ПО". Я широко использовал GridView, а также сторонние продукты (Telerik и т. Д.) И обнаружил, что для большинства внутренних и некоторых внешних проектов они отлично работают. Они быстрые, простые в использовании, настраиваемые - и ЛУЧШИЕ - я могу передать их кому-то, кто знает GridViews, который затем может легко подобрать то, где я остановился. Если бы я должен был вручную закодировать все многочисленные приложения / элементы управления, затраты следующего человека, выясняющего, что происходит, были бы огромными даже в самых лучших обстоятельствах.
Что касается меня, я вижу, что некоторые продукты сторонних производителей являются программным обеспечением (но все же иногда полезным), но простой GridView, который я нашел, довольно быстр с умеренными запросами.
Для моих корпоративных проектов в интранете сетки являются обязательными. Они являются основой для удобной отчетности на платформе веб-форм ASP.NET.
Простота дизайна Вставьте сетку на страницу. Вставьте объекты BoundField для простой привязки. asp:HyperlinkField для легкой ссылки.
переплет
Вы можете связать сетки несколькими способами:
- коллекция предметов (
List,ArrayList,Hashtableили любая простая коллекция) SqlDataReaderв вашем коде (да, это потребовало бы SQL на вашем уровне представления)SqlDataSource(укажите сохраненный процесс. Все столбцы в наборе результатов сопоставляются непосредственно со столбцами сетки. Это очень быстро и грязно, если отчет плохо имитирует объект вашего домена. То есть суммирование разных вещей.)- objectDataSource (привязка к методу вашего BL)
Для тех, кто может взывать SqlDataSource а также ObjectDataSourceВам не всегда нужно объявлять их в ваших.aspx.cs или.aspx.vb . Я не защищаю их здесь, просто указываю на возможности.
Я не думаю, что вы можете сбрасывать со счетов преимущества RAD встроенного GridView и других сторонних сетей. Типы управления любят и хотят табличные данные.
Компоненты, такие как GridView/FormView/DataGrid, следуют правилу 80/20.
Это означает, что в 80% случаев, когда вы используете их для простых целей, они выполняют свою работу и чрезвычайно просты в реализации.
Но в 20% случаев вы будете пытаться создать что-то сложное (или странное), и вам придется прыгать через дюжину обручей и разными способами изгибать код, пытаясь реализовать решение.
Хитрость заключается в том, чтобы узнать, является ли проблема проблемой 80 или 20, если вы можете определить проблему 20 на ранней стадии, вам гораздо лучше писать код с нуля и отказаться от "экономии времени".
Мне нравится элемент управления GridView, и я использовал его в нескольких пользовательских модулях DotNetNuke для веб-сайта моей компании. Во-первых, использование встроенных элементов управления означает меньше беспокойств по поводу зависимостей. И как только я настроил его так, как я хотел, я в основном скопировал код на другие страницы и просто должен был сделать небольшие изменения.
Я обнаружил, что с современными элементами управления сеткой (Infragistics, Telerik и т. Д.) Существует так много вариантов, что настройка сетки занимает больше времени, чем что-либо еще. Средства управления MS довольно просты, но они могут делать практически все что угодно.
Мне очень нравится Telerik Radgrid. Их продукт не дешевый, но вы получаете множество элементов управления и функций. И поддержка связывания данных довольно хороша, как с помощью простого способа привязки источника данных asp.net, так и с помощью более настраиваемого способа обработки событий, связанных с вашими собственными данными.
Я никогда раньше не использовал стандартную сетку WinForms, но на моей последней работе мы широко использовали ComponentOne FlexGrid, и он прекрасно работал. Были некоторые неприятности с попытками получить все настройки, которые мы хотели, но в целом это сэкономило нам массу времени и дало прекрасные результаты.
В настоящее время я работаю с Silverlight 3 и RIA Services и не могу представить, что пытаюсь создать то, что мы делаем, без элементов управления DataGrid и DataForm. Экономия времени значительно перевешивает любые накладные расходы.
Я задавался вопросом об этом в течение длительного времени. Здесь, кажется, существует консенсус в отношении того, что элементы управления сеткой являются вредоносными программами. Но может ли кто-нибудь окончательно назвать стоимость использования этих элементов управления? Чрезмерный HTML отправляется в браузер? Слишком много ресурсов пожирается на сервере? Быстрее ли генерируется таблица HTML (при условии, что она хорошо написана)?
В дополнение к проблеме с вредоносным ПО, я часто сталкиваюсь с мошенничеством, когда требования к пользовательскому интерфейсу расширены и включают функции, выходящие за рамки стандартных элементов управления. Например, в ранних версиях ASP.Net я пытался поместить изображения в заголовки столбцов. И я считаю, что все еще трудно добавить вторую строку заголовка верхнего уровня, охватывающую несколько столбцов. В какой-то момент становится действительно трудно бороться с контролем, чтобы достичь желаемого эффекта. И это огорчает, если вы знаете, какой HTML-код вам нужен, но вы просто не можете заставить его делать это.
В одном проекте я, наконец, сдался и написал себе класс таблиц HTML для создания очень сложной сетки. Потребовалось несколько дней, чтобы понять это правильно. Но теперь у меня есть основной код, и будет гораздо эффективнее настроить его для будущих сетей.
Без сомнения об этом, все же. Трудно превзойти необычные элементы управления сеткой для быстрой разработки, если вы можете просто жить в рамках их ограничений.
В долгосрочной перспективе я бы старался избегать сетки данных / сетки, иногда она становится слишком хакерской, заставляя ее делать именно то, что вы хотите, после определенного числа этих твиков вы начинаете понимать, что это не экономит время в долгосрочной перспективе, и вы не сможете получить контроль над разметкой, которая вам нужна.
Однако встроенные функции подкачки и сортировки работают хорошо, и в 2008 году появился новый элемент управления ListView, который призван решить некоторые из этих проблем и дать вам более жесткий контроль над HTML, который выводится.
Если вы много работаете с дизайнерами на общедоступных веб-сайтах, вам следует отказаться от GridView и придерживаться повторителей. В любом случае, это мое мнение - мне пришлось разделить сотни GridView и превратить их в простые повторители, чтобы выполнить требования дизайна.
Если вы приближаетесь к DataGrids или GridViews с 10-футовым шестом на общедоступном веб-сайте, тогда вы ДОЛЖНЫ использовать CSS-дружественные управляющие адаптеры. (В этот момент вам может оказаться проще сделать это в повторителе.) До появления адаптеров управления я бы считал эти элементы управления нестандартными.
Я считаю, что слишком многие разработчики.NET не имеют хорошего понимания дизайна, доступности, CSS, javascript, стандартов и т. Д., Поэтому они уступают GridViews, ObjectDataSources и т. Д.
Я никогда не использовал это. Я полностью согласен, это вздор. Я обычно заканчиваю тем, что использую репитер с пользовательскими элементами управления, которые я сделал.
GridView - это прекрасный и очень мощный элемент управления, который хорошо работает с CSS или темами. Единственное, что меня раздражает, это то, что свойство VirtualCount было удалено, когда старый DataGrid 1.1 был заменен на GridView в asp.net 2.0, и это было полезно для реализации пользовательской подкачки страниц. Однако то же самое можно сделать через адаптеры данных.
Хотя работа с повторителями, возможно, более понятна, и у вас есть полный контроль над отображаемым html, я бы не советовал идти по этому пути, потому что его сложнее реализовать и поддерживать.
Я разработчик среднего уровня, я могу сказать, что без этих элементов управления я не смог бы научиться разрабатывать. Просто нужно какое-то время признаться в этом, пока вы не найдете способ настроить его, и конечный результат будет отличным
Я пытаюсь смотреть на все это в контексте. У меня есть страница, которая имеет хороший вид сетки (отображает 10 строк за раз, 6 столбцов, сортировка и разбиение на страницы), и если я просто смотрю на HTML-таблицу, которая создается вместе с viewstate, я вижу только 29k кода,
Стоит ли 29К против 18К для использования ретранслятора или списка просмотра действительно стоит всех усилий в эти широкополосные времена?
Лично я придерживаюсь gridviews, однако дизайнер, с которым я работаю, иногда жалуется на то, что пытается стилизовать его с помощью CSS.
Просто читаю ваши посты. Я согласен, что PHP легче, чем asp. но я только начал использовать визуальную студию для просмотра формы и сетки. Не может быть намного проще для программистов VB или C#. ASP по-прежнему имеет проблемы с загрузкой больших файлов. PHP это совсем несложно. Я запускаю PHP под IIS 7.5