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

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

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

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

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

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

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

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

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

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

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

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

Использование элементов управления, таких как 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>

Я широко использую их в корпоративной среде, в которой работаю, и сейчас работаю с одним из них. Люди, которые не пользуются ими, напоминают мне всех этих "I built it with Notepad" разработчиков прошлых лет. Какой смысл использовать asp.net, если вы не собираетесь воспользоваться преимуществами экономии времени?

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

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

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

Хитрость заключается в том, чтобы узнать, является ли проблема проблемой 80 или проблемой 20, если вы можете определить проблему 20 заранее, вам гораздо лучше написать код с нуля самостоятельно и выбросить "time saving".

Я тоже хотел бы получить развернутый ответ на вопрос, почему GridView и др. считаются "bloatware." я широко использовал GridView, а также продукты сторонних производителей (Telerik и т. д.) и обнаружил, что для большинства внутренних и некоторых внешних проектов они отлично работают. Они быстры, просты в использовании, настраиваемы - и BEST - я могу передать их кому-то, кто знает GridViews, кто может легко продолжить с того места, где я остановился. Если бы мне пришлось вручную кодировать все многочисленные apps/controls,, то накладные расходы у следующего человека, выясняющего, что происходит, были бы огромными даже при самых благоприятных обстоятельствах.

Для меня, я могу видеть, что некоторые из продуктов 3-й партии являются bloatware (но все еще иногда полезны), но голые кости GridView, которые я нашел, довольно быстры с умеренными запросами.

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

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

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

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

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

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

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

"export to excel" также является убийственной функцией.

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

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

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

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

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

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

Обязательный

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

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

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

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

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

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

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

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

Однако встроенная функция разбиения на страницы и сортировки работает хорошо, и в 2008 году появился новый элемент управления ListView, который призван решить некоторые из этих проблем и дать вам более жесткий контроль над html, который выводится.

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

Если вы идете рядом с DataGrids или GridViews с 10-футовым шестом на общедоступном веб-сайте, то вы HAVE, чтобы использовать CSS дружественные адаптеры управления. (В этот момент вам, возможно, будет проще просто сделать это в ретрансляторе.) До того, как появились адаптеры Управления, я бы считал, что эти элементы управления вырваны из коробки.

Я нахожу, что слишком много разработчиков .NET не имеют хорошего понимания дизайна, доступности, CSS, javascript, стандартов и т. д. вот почему они поддаются GridViews, ObjectDataSources и т. д.

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

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

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

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

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

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

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

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

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