asp.net - tutorial - ¿Quién realmente usa DataGrid/GridView/FormView/etc en aplicaciones de producción?

dal asp net mvc (26)

Curioso si los demás sienten lo mismo que yo. Para mí, controles como datagrid / gridview / formview / etc. son excelentes para presentaciones o demostraciones solamente. Tomarse el tiempo y ajustar estos controles, anular su comportamiento predeterminado (conectar sus tontos eventos, etc.) es un gran dolor de cabeza. El único control que uso es el repetidor, ya que me ofrece la mayor flexibilidad sobre los demás.

En resumen, son bastante bloatware.

Prefiero tejer mi propio html / css, usar mis propias consultas de paginación personalizadas.

Nuevamente, si necesita lanzar una página rápida, estos controles son geniales (especialmente si está tratando de atraer a la gente hacia la facilidad del desarrollo de .NET ).

Debo ser una minoría, de lo contrario MS no dedicaría tanto tiempo de desarrollo en este tipo de controles ...

De hecho, he usado GridView extensamente para una consola administrativa. Incluso creé un DataFieldControl personalizado que establece el texto del encabezado del campo y ordena la expresión según el campo de datos, crea una fila Insertar en la parte inferior y automáticamente recoge los valores en la fila y los reenvía al método de inserción de la fuente de datos y genera un cuadro de lista si se especifica una fuente de datos de lista adicional. Ha sido muy útil, aunque una gran inversión de tiempo para construir.

También tengo otro control que generará un nuevo formulario de datos basado en los metadatos de los campos cuando no haya registros (en EmptyDataTemplate).

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

En mi empresa usamos redes en todas partes, principalmente ComponentArt Grid ( http://www.componentart.com/ ). Sí, es bloatware pero obtienes mucha funcionalidad que no sería muy divertido reinventar: clasificación, paginación, agrupamiento, reordenamiento de columna, edición en línea, creación de plantillas (del lado del servidor y del lado del cliente). Las API del lado del cliente también son agradables.

Estoy escribiendo mi propio HTML. Estoy usando ListView y Masterpages, pero ya no uso mucho los controles. Mi ListView se ríe de tu viejo y tonto repetidor, por cierto.

Sin embargo, bloatware no es necesariamente algo malo. Si necesitaba una aplicación de intranet de bajo volumen, prefiero pagar a un desarrollador menos experimentado para que arrastre y suelte los controles que para un twiddler HTML (como tú o yo) para crear cada etiqueta. Definitivamente hay un lugar para el enfoque rápido y simple. ¿Cuál es el costo de "bloatware" en ese escenario, siempre y cuando el código basado en el control esté escrito de manera mantenible? A menudo, los controles de cableado juntos requieren menos código personalizado, lo que significa un mantenimiento simple.

El único lugar en el que tengo que estar en desacuerdo contigo, independientemente de la aplicación, es crear tus propias consultas de paginación. Es posible que desee hacer ese tipo de cosas, pero no tiene absolutamente ningún valor comercial. Hay varias herramientas DAL de nivel profesional que generalmente escribirán consultas más rápidas y fáciles de mantener que la mayoría de los desarrolladores. Incluso si elabora con amor la consulta de búsqueda perfecta, no se mantendrá actualizado con los cambios en el esquema a menos que continúe lanzando horas después. Creo que un mejor uso de esas horas es construir un sistema liviano y poner esas horas en el monitoreo y la reparación de cuellos de botella específicos, en lugar de saltar de inmediato al nivel de "lenguaje de ensamblaje de la base de datos".

Realmente me gusta el telerik radgrid. Su producto no es barato, pero obtienes muchos controles y funciones. Y el soporte de enlace de datos es bastante bueno, tanto en una forma simple de enlace de fuente de datos asp.net como en una forma más personalizada de manejar su propio enlace de datos.

Cada aplicación que desarrollamos en mi empresa tiene cuadrículas (todas las aplicaciones están detrás del firewall). Eso incluye aplicaciones web y aplicaciones de Winform. Para las aplicaciones web, es la buena vista de grid de ole con clasificación personalizada para las aplicaciones winform que utilizamos Janus grid. Estoy intentando que los desarrolladores / usuarios piensen en mejores interfaces de usuario, pero es difícil de cambiar. ¡Debo admitir que es aún mejor que la alternativa de que los usuarios construyan sus "propias" aplicaciones con Access que yo necesitaría entonces!

Cualquiera que piense que nadie usa * controles de cuadrícula claramente nunca funcionó en una aplicación web corporativa interna.

Ellos son uno de los beneficios de asp.net. Hasta hace poco los odiaba, pero cuanto más los utilizas, más fáciles se vuelven, una vez que aprendes qué configuración debes cambiar para qué instancias. Principalmente me gusta la vista de formulario y la vista de lista, la vista de cuadrícula todavía necesita algo de trabajo.

Me gusta el control GridView y lo he usado en varios módulos DotNetNuke personalizados para el sitio web de mi compañía. Por un lado, usar los controles integrados significa menos dependencias de las que preocuparse. Y una vez que lo configuré como lo quería, básicamente copié el código en otras páginas y solo tuve que hacer ajustes menores.

Descubrí que hay tantas opciones con los controles de cuadrícula modernos (Infragistics, Telerik, etc.) que la configuración de la grilla demora más que cualquier otra cosa. Los controles de MS son bastante simples, pero pueden hacer casi cualquier cosa.

Usar controles como el GridView es ideal para aplicaciones simples. Incluso si eres un ninja del twiterdling del corchete HTML del lado del servidor, pueden hacer que el desarrollo de cosas simples consuma menos tiempo. El problema es que generalmente comienzan a exponer sus deficiencias eventualmente, y terminas teniendo que perder tiempo ajustándolos de todos modos. Pero al menos puede levantarse y ponerse en marcha rápidamente para comenzar.

Por ejemplo, la paginación predeterminada en un GridView no admite paginación en la base de datos (tienes que cargar todas las filas antes de que las pagine), así que una vez que empieces a sentir ese pellizco en el rendimiento, es posible que tengas que pensar en rodar el suyo o, quizás mejor, encuentre un control de red más capaz.

De todos modos, el punto es que los componentes preconstruidos son buenos . Ellos ayudan. Pero, como de costumbre, depende de lo que necesite que haga.

Nunca lo he usado. Estoy completamente de acuerdo, es bloatware. Suelo terminar usando el repetidor con controles personalizados que hice.

Para cualquier cosa a largo plazo, trataría de evitar DataGrid / gridview, a veces se vuelve demasiado hacky haciendo que haga exactamente lo que quiere, después de un cierto número de estos ajustes, comienza a darse cuenta de que no está ahorrando tiempo a largo plazo y es posible que no esté obtener el control sobre el marcado que necesita.

Sin embargo, la función integrada de paginación y clasificación funciona bien y en 2008 hay un nuevo control ListView que tiene como objetivo resolver algunos de estos problemas y brindarle un control más estricto del html que se genera.

Me he preguntado sobre esto durante mucho tiempo. Parece que hay un consenso aquí en cuanto a que los controles de cuadrícula son bloatware. Pero, ¿alguien puede citar definitivamente el costo de usar estos controles? ¿Hay un HTML excesivo enviado al navegador? Demasiado recurso devorado en el servidor? Está generando la tabla HTML más rápido (asumiendo que está bien escrita)?

Además del problema de bloatware, a menudo he enloquecido cuando los requisitos de UI se han mejorado para incluir funciones que van más allá del alcance de los controles estándar. Por ejemplo, en las primeras versiones de ASP.Net, tuve problemas para poner imágenes en los encabezados de las columnas. Y, creo que sigue siendo un desafío agregar una segunda fila de encabezado de nivel superior que abarca varias columnas. En algún momento, se vuelve realmente difícil luchar con el control para lograr el efecto deseado. Y es frustrante si conoces el HTML que deseas, pero simplemente no puedes hacer que el control lo haga.

En un proyecto, finalmente me rendí y escribí una clase de tabla HTML para generar una grilla muy complicada. Me tomó un par de días para hacerlo bien. Pero, ahora tengo el código básico, y será mucho más eficiente ajustarlo para futuras grillas.

Sin embargo, no hay dudas al respecto. Es difícil superar los sofisticados controles de cuadrícula para un desarrollo rápido, si puedes vivir dentro de sus limitaciones.

Creo que debes aprender a usar GridViews antes de condenarlos. Los uso extensivamente. Al principio era un poco difícil descubrir ciertas cosas, pero ahora son indispensables.

GridViews dentro de UpdatePanel con AJAX CRUD y la paginación son muy rápidos. Uno de los sistemas más grandes configurados de esta manera (para aplicaciones internas / externas) tiene un db de tamaño moderado en el back-end. Hay muchos campos nvarchar (2000) y las transiciones y actualizaciones son geniales.

En cualquier caso, si ha escrito su propia versión de visualización de datos, puede seguir utilizándola si funciona. (Se podría hacer el mismo argumento para escribir su propio compilador, escribir su propia versión de HTML, escribir su propia versión de binarios de acceso a datos ...) La ventaja de usar GridView es que hay muchas personas que están familiarizadas con él y que MSFT ha abstraído / modelado la clase para hacer muchas cosas que solíamos hacer manualmente.

GridView es un control fino y muy potente que funciona bien con css o theme. Lo único que me molesta es que la propiedad VirtualCount se eliminó cuando el antiguo 1.1 DataGrid fue reemplazado por GridView en asp.net 2.0 y fue útil para implementar paginación personalizada. Sin embargo, lo mismo se puede hacer a través de adaptadores de datos.
Aunque trabajar con repetidores es quizás más claro y tienes un control total sobre el html renderizado, no recomendaría seguir así porque es más difícil de implementar y mantener.

Si trabajas mucho con diseñadores en sitios web públicos, entonces deberías abandonar GridViews y mantenerte en los repetidores. Esa es mi opinión de todos modos: he tenido que separar cientos de GridViews y convertirlos en repetidores simples para cumplir con los requisitos de diseño.

Si te acercas a DataGrids o GridViews con un poste de 10 pies en un sitio web público, entonces TIENES que usar los adaptadores de control compatibles con CSS. (En este punto, puede que le resulte más fácil simplemente hacerlo en el repetidor). Antes de que los adaptadores de control estuvieran disponibles, habría considerado estos controles fuera de la caja.

Me parece que demasiados desarrolladores de .NET no tienen una buena comprensión del diseño, accesibilidad, CSS, javascript, estándares, etc. por lo que sucumben a GridViews, ObjectDataSources, etc.

Usamos Infragistics UltraWebGrid + LinqDataSource en nuestras aplicaciones de intranet.

Nos da ajax, ordenando, filtrando, paginando todo el lado del servidor.

La "exportación para sobresalir" también es una característica clave.

Tenemos más de 5000 usuarios, muchos datos, el rendimiento es excelente.

En gran medida, abandoné las redes una vez que comencé a diseñar a partir de historias de usuarios, en lugar de los requisitos de la tabla de la base de datos. Y nunca rejillas editables. La vieja era simplemente cómo coaccionaba a los usuarios a hacer el mantenimiento de entrada / tabla de datos para nuestros sistemas, y nunca coincidía con su flujo de trabajo: cualquier trabajo real terminaba saltando de un formulario maestro / secundario a otro.

Y los usuarios nunca lo descubrieron, pero seguramente sabían que nuestras aplicaciones eran más difíciles de usar de lo que deberían ser.

Una excepción son las aplicaciones analíticas. Pero hay relativamente pocos de ellos, y son principalmente de solo lectura.

Soy un desarrollador de nivel moderado, puedo decir sin estos controles que nunca pude aprender a desarrollar. Simplemente tiene que admitirlo por un tiempo hasta que encuentre la forma de personalizarlo y el resultado final será genial.

También me gustaría ver una respuesta ampliada sobre por qué GridView y otros se consideran "bloatware". He utilizado ampliamente GridView, así como productos de terceros (Telerik, etc.) y encuentro que para la mayoría de los proyectos internos y algunos externos, funcionan muy bien. Son rápidos, fáciles de usar, personalizables, y MEJOR , puedo entregárselos a alguien que conozca GridViews y que pueda retomarlos fácilmente donde lo dejé. Si tuviera que codificar manualmente todas las aplicaciones / controles, la sobrecarga de la próxima persona que averigüe qué está pasando sería enorme incluso en las mejores circunstancias.

Para mí, puedo ver que algunos de los productos de terceros son bloatware (pero a veces son útiles), pero el barebone GridView me parece bastante rápido con consultas moderadas.

Estoy tratando de verlo todo en contexto. Tengo una página que tiene una buena vista de cuadrícula (muestra 10 filas a la vez, 6 columnas, clasificación y paginación) y si solo miro la tabla html que se crea junto con viewstate, solo estoy viendo 29k de código .

¿Vale la pena el esfuerzo en estos tiempos de banda ancha de 29k contra 18k para usar un repetidor o una lista de listas?

Personalmente me quedo con las vistas de la red, sin embargo, el tipo de diseño con el que trabajo a veces se resiste a intentar adaptarlo a través de css.

He estado leyendo tus mensajes chicos y me hizo sentir tonto.

Quiero decir en cada aplicación que hice donde trabajo hay al menos una cuadrícula de datos / vista de cuadrícula. Y no tenía la sensación de que me estaba perdiendo algo.

Seguro que encuentro que datagrid / gridview está algo hinchado, pero ¿son tan repugnantes de usar?

Nunca utilicé la grilla WinForms estándar anteriormente, pero en mi último trabajo utilizamos ComponentOne FlexGrid extensamente y funcionó maravillosamente. Todavía había algunas molestias con tratar de obtener toda la personalización que queríamos, pero en general nos ahorró muchísimo tiempo y produjo hermosos resultados.

Actualmente estoy trabajando con Silverlight 3 y RIA Services y no me puedo imaginar tratando de producir lo que estamos haciendo sin los controles DataGrid y DataForm. El tiempo que se ahorra supera con creces cualquiera de los gastos generales.

Para mis proyectos de intranet corporativa, las redes son indispensables. Son la base para generar informes fácilmente en la plataforma de formularios web de ASP.NET.

Fácil de diseñar Pega la cuadrícula en la página. Inserte objetos BoundField para un enlace simple. asp:HyperlinkField para asp:HyperlinkField fáciles.

Unión

Puedes enlazar grillas de varias formas:

una colección de objetos ( List , ArrayList , Hashtable o cualquier colección simple)
SqlDataReader en su código subyacente (por ejemplo, eso requeriría SQL en su nivel de presentación)
SqlDataSource (especifique un procedimiento almacenado Todas las columnas en el mapa del conjunto de resultados directamente a las columnas de la grilla. Es muy rápido y sucio si el informe no imita muy bien su objeto de dominio, es decir, suma de cosas diferentes).
objectDataSource (vinculante a un método en su BL)

Para aquellos que pueden llamar a SqlDataSource y ObjectDataSource , no siempre es necesario declararlos en .aspx.cs o .aspx.vb. No los defiendo aquí, solo señalando las posibilidades.

No creo que pueda descontar los beneficios de RAD del GridView incorporado y otras cuadrículas de terceros. Los tipos de gestión adoran y desean datos tabulares.

Componentes como el GridView / FormView / DataGrid siguen la regla 80/20.

Esto significa que el 80% del tiempo cuando los usa para fines simples hacen el trabajo y son extremadamente fáciles de implementar.

Pero el 20% del tiempo intentarás construir algo complejo (o extraño) y te verás obligado a pasar por una docena de aros y doblar el código de muchas maneras para tratar de implementar una solución.

El truco está en saber si el problema es un problema 80 o problema. Si puedes identificar el problema temprano, es mejor escribir el código desde cero y abandonar el que ahorra tiempo.

Los uso ampliamente en el entorno corporativo en el que trabajo y estoy trabajando con uno ahora mismo. Las personas que no los usan me recuerdan a todos los desarrolladores de "Lo construí con el Bloc de notas" de años pasados. ¿De qué sirve utilizar asp.net si no va a aprovechar el ahorro de tiempo?

Solo leyendo tus publicaciones. Estoy de acuerdo en que PHP es más fácil que asp. pero acabo de empezar a usar Visual Studio para las vistas de formulario y las vistas de cuadrícula. No puede ser mucho más fácil para los programadores vb o C #. ASP todavía tiene problemas para cargar archivos de gran tamaño. PHP es muy fácil. Ejecuto PHP bajo IIS 7.5