2008-09-19 25 views

Respuesta

9

Me encantan los formularios web, pero ASP.NET AJAX es un montón de basura.

Prefiero usar WebForms + HTTPHandlers personalizados que manejan el lado del servidor de cualquier llamada AJAX.

Je, downvoted ...

ASP.NET AJAX es un montón de basura debido a una devolución de llamada requiere toda la clase de página que se reinstantiated, no está llamando a un método único, que va a reconstruir toda la página en el servidor cada vez.

Además, UpdatePanels devuelve toda la página, solo aparece la sección en el panel de actualización, es una pérdida total de ancho de banda.

Entiendo por qué está hecho de esta manera, porque los controles de WebForms no pueden ser fácilmente de otra manera, pero aún así son muy malos.

+0

Ahora tengo curiosidad. ¿Cómo sería una implementación de muestra de WebForms + ASHX? – Bullines

+0

No está limitado a ASHX con la implementación del controlador, puede agrupar manejadores en archivos de clase y agregar los controladores a su webconfig. También es muy eficiente, pero depende de lo que quieras lograr. A, por ejemplo, sería realizar una llamada con sobrecarga limitada para bloquear un registro en un DB. –

+2

¿Puedes elaborar sobre "montón de mierda"? –

0

He utilizado asp.net winforms con ajax.net y prototype/ext/jquery. Creo que algo a considerar es el objetivo del sitio ... MVC es un patrón popular. No puedo decir nada en contra de ASP MVC porque no he tenido la oportunidad de usarlo, pero quiero asegurarme de que sepas que no estás limitado a ajax.net si eliges formularios web.

+0

Yo quería aclarar. Tengo muchas ganas de hacer un proyecto de MVC, simplemente no he tenido una chispa para comenzar uno. No quería sonar como si estuviera desalentando el desarrollo de MVC. –

2

ASP.NET MVC todavía está en forma de "vista previa", y como tal, no lo consideraría hasta que madure. Puedes rodar tu propio patrón de MVP con bastante facilidad sin mucha plomería.

En el frente de Ajax, yo diría que intente encontrar bibliotecas (comerciales o de otro tipo) que hagan lo que está buscando. Los conceptos básicos (Cuadrículas, árboles, cuadros de texto de autocompletar, etc.) se han destruido. No reinventar la rueda.

+0

ASP.NET MVC puede estar en RC, pero es interesante observar que Stackoverflow está completamente desarrollado sobre ASP.NET MVC. – Notorious2tall

+0

Claro, eso no significa que confíe en un sistema que se usa para pagar las facturas. StackOverflow.com, cuando se inició fue solo un juguete. –

29

He hecho ambas cosas últimamente, tomaría MVC nueve veces de cada diez.

  • Realmente no me gusta la implementación de los controles asp.net ajax, me he encontrado con un montón de problemas con el tiempo, los eventos y la depuración de los problemas de devolución de datos. Aprendí mucho de http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
  • El proyecto asp.net usamos el patrón MVP http://www.codeplex.com/aspnetmvp, y el patrón funcionó muy bien. Sin embargo, terminamos con un montón de código en la vista porque estábamos interactuando directamente con los controles del lado del servidor (es decir, muchas manipulaciones de gridview). Este código es casi imposible de verificar con los marcos de prueba de la unidad. Deberíamos haber sido más diligentes para mantener el código fuera de la vista, pero en algunos casos era más fácil y menos complicado.

La única vez que elegiría mediante el desarrollo de formas de ASP.NET sería utilizar el control GridView.Estamos utilizando jquery para nuestro framework javascript con MVC y aún no hemos encontrado una muy buena gridview como control. Tenemos algo que es funcional, pero la cantidad de tiempo que nos hemos dedicado a aprender, modificar y depurar frente a los controles del lado del servidor asp.net ha sido sustancial. Uno pierde todos los lindos widgets que ofrece Microsoft de forma inmediata al hacer el desarrollo de formularios no asp.net. La pérdida de esos widgets es liberadora y atemorizante al mismo tiempo cuando comienzas por primera vez.

Al final del día, estoy contento de que estemos realizando el desarrollo de MVC. Mi equipo y yo hemos aprendido un nuevo marco (antes solo éramos desarrolladores de asp.net) y nos hemos ensuciado las manos con html y javascript. Estas son habilidades que podemos llevar a otros proyectos u otros idiomas si alguna vez lo necesitamos.

+0

Estoy de acuerdo con usted, totalmente en esto ... buenos puntos :) – Marko

+2

¿Ha considerado una cuadrícula del lado del cliente con jQuery y DataTables.Net? Muchas veces un control de grid del lado del servidor puede ser over kill. –

2

Cuando estoy diseñando un sitio, una de las cosas más importantes que prefiero es el principio DRY. IMO ASP.NET MVC es mucho más seco que los formularios web.

Recientemente he pasado de webforms a MVC y espero no tener que volver nunca más.

1

Webforms con ASP.NET Ajax es cielo. La integración entre los 2 es simplemente increíble y se siente tan natural para trabajar.

Usar formularios web en lugar de mvc le dará la capacidad de utilizar el ciclo de vida para desarrollar controles muy buenos y reutilizables.

Pero todavía me gustaría agregar un poco de jQuery en la mezcla para recorrer el dom y agregar animaciones, solo me gusta usar asp.net ajax para obtener la integración con el lado del servidor.

+0

Mis pensamientos exactamente, espero que el AJAX para MVC sea tan fácil cuando llegue a aprenderlo –

+0

No sé sobre * heaven *, pero no conozco ningún otro marco que se aproxime a la capacidad de plugabilidad de los controles de formularios web. –

0

Acepto que asp.net ajax UpdatePanels no es una solución ideal.

Hemos evitado usarlos y en su lugar hemos estado utilizando las bibliotecas del lado del cliente para hacer cualquier comunicación con el servidor. Me gusta lo que vi en PDC sobre las características que vienen en asp.net ajax 4.0 con componentes declarativos y plantillas del lado del cliente, ¡muy lindo! Combinar JQuery con las bibliotecas existentes proporciona bastante, y he cuestionado el uso exclusivo de JQuery, dado que es mucho más pequeño y tiene la capacidad de hacer muchas cosas similares a la biblioteca del cliente asp.net ajax.

En cuanto a la pila de servidores: aún no he usado MVC, pero hemos tenido éxito utilizando un enfoque de MVP rodado en casa utilizando formularios web.

1

El concepto detrás de MVC es genial, pero prepárate para perder prácticamente toda la funcionalidad de todos los controles de servidor que has utilizado durante tantos años. Solo he examinado la implementación de MVC durante aproximadamente una semana, pero el ciclo de vida de la página y el estado de la vista se han ido, por lo que estos controles ya no funcionan correctamente.

También me sorprendió encontrar una serie de ejemplos que contenían una gran cantidad de código lógico en el marcado. Así es, declaraciones 'if' y 'foreach' en los archivos aspx: un horrible paso hacia atrás. Estuve muy feliz de dejar el ASP clásico pero en la implementación actual del patrón asp.net mvc vuelves a codificar en tu marcado, la necesidad de utilizar ayudantes en todas partes y la falta de prácticamente cualquier control de servidor utilizable.

Si está comenzando un nuevo proyecto ahora, le recomendaría seguir con los formularios web asp.net y utilizar un asp.net ajax integrado, el kit de herramientas y jQuery, según sea necesario. La implementación de asp.net ajax puede no ser la mejor implementación, o la más eficiente, pero a menos que consigas un millón de únicos el día 1 o que tu servidor sea un commodore vic 20, el rendimiento no será tan notable.

Esto, por supuesto, depende del tamaño de su proyecto.Si está comenzando una aplicación de nivel empresarial de 5 años que espera millones de visitas a la página, es posible que UpdatePanel no la corte, pero si está creando un sitio promedio, lanzando un prototipo o simplemente necesita moverse rápidamente, asp.net ajax funciona perfectamente bien y tiene una curva de aprendizaje extremadamente baja.

Y para ser claros, la página completa no se devuelve absolutamente cada vez que se realiza una llamada ajax./Solo/el contenido del panel que necesita actualizarse se envía a través del cable. Cualquier monitor http probará este punto. Sí, se realiza la página/ciclo de vida/pero, sabiendo que puede, puede crear aplicaciones asp.net ajax bastante eficientes.

+0

Re: UpdatePanels, que no es remotamente precisa. Incluso los sitios que prestan servicio a un solo usuario concurrente ven aumentos de rendimiento masivos al reemplazar los UpdatePanels. Le debe importar muy poco la experiencia de sus usuarios en su sitio para usarlos en la producción. –

+0

Perspectiva interesante sobre ASP.NET MVC ... estamos comenzando un nuevo proyecto y casi fuimos con ASP.NET, pero ninguno de nosotros pudo entender cómo usarlo (nuestro equipo tiene HTML, winforms y algo de PHP de fondo, pero nadie sabía ASP.NET). Por alguna razón, ASP.NET MVC parecía MUCHO más natural ya que estaba estrechamente relacionado con el producto final en lugar de tratar de hacer que todo pareciera una forma de inversión. –

+0

Ese es un buen punto, debo aclarar, si virtualmente no tienes antecedentes de asp.net, MVC es probablemente el camino a seguir. El patrón es sólido y, lógicamente, tiene mucho sentido. No tener el ciclo de vida de la página es excelente * SI * no ha trabajado con esto durante años. Simplemente estoy frustrado porque mi bolsa de herramientas ya no funciona y no tengo tiempo para hacer una nueva bolsa. – Mike

2

Si necesita un panel de actualización, le sugiero que utilice el código abierto MagicAjax o ComfortASP. Si necesita framework ayuda a desarrollar ajax personalizado, sugiero jQuery.

9

No dejes que la gente te engañe haciéndote pensar que es una elección clara. Puedes obtener lo mejor de ambos mundos. Mi enfoque es crear un proyecto de MVC, pero en lugar de añadir puntos de vista, añadir páginas ASP.NET estándar, pero cambiar el código detrás de heredar de MVC.ViewPage así:

public partial class SamplePage : System.Web.Mvc.ViewPage 
{ 
    protected void Page_Load(object sender, EventArgs e) 
    { 
    } 
} 

Si se confine a la sola etiqueta de formulario (con runat = "servidor") en el código en el frente, luego tiene código completo detrás del acceso a los controles de su servidor asp.net estándar. Esto significa que usted obtiene un control completo del lado del servidor de la presentación (por ejemplo, usando databinding y repetidores) sin tener que hacer el viejo código de estilo ASP.

protected void Page_Load(object sender, EventArgs e) 
    { 
     IObjectDefinition instance = (IObjectDefinition)ViewData["definition"]; 
     _objectName.Text = instance.DisplayName;//textbox or label 

     DataTable itemVals = new DataTable(); 
     itemVals .Columns.Add("itemName"); 
     itemVals .Columns.Add("itemValue");    


     IDictionary<string, string> items = (IDictionary<string, string>)ViewData["items"]; 
     foreach (KeyValuePair<string, string> datum in items) 
     { 
      conditions.Rows.Add(new object[] { datum.Key, datum.Value}); 
     } 

     _itemList.DataSource = itemVals;//repeater 
     _itemList.DataBind(); 
    } 

La publicación de cualquier control no se publica en la página, sino en el controlador. Si recuerda usar la propiedad de nombre en los controles de su servidor, terminan en la colección FormControls para acceder a las variables de su página según el MVC estándar.

Entonces, ¿qué es lo que consigue ?:

  • completo de control del lado del servidor de la presentación de su código delante es puramente HTML y etiquetas de control de servidor asp.net
  • la separación completa de las preocupaciones - sólo la página hace la presentación y todo orquestación y de clasificación se realiza en el controlador (en vez de hacerlo en la página de asp.net)
  • plena capacidad de prueba MVC código
  • No hTML tejer
  • Puede ajustar el estado de la vista y reducir la saturación de la página

¿Qué pierde?

  • Una vez más tiene que permanecer en una forma por página si desea utilizar sólo los controles de servidor
  • Es posible que tenga que especificar manualmente objetivos de devolución de datos para los botones y la forma
  • una vez más tiene 2 archivos para su presentación

Ah, y para AJAX - jQuery definitivamente. Hacer una solicitud a un método de controlador que devuelve un JsonResult realmente simplifica las cosas.

+1

Un enfoque novedoso. Me sorprende que ninguno de los expertos residentes de ASP.NET haya intervenido. –

8

Veo que la mayoría de las respuestas salieron antes de MVC 1.0. Como ahora estamos en Vista previa 2.0, pensé que sería bueno volver a visitar.

Yo era un ASP.Desarrollador de NET durante aproximadamente cinco años antes de realizar el cambio a MVC en marzo pasado. No me he arrepentido por un segundo. Ahora me doy cuenta de que cuanto más fuerte me pongo en ASP.NET WebForms, más difícil me resulta aprender otras tecnologías, como JavaScript y la implementación de AJAX que no es de Microsoft. Microsoft aprovechó su enfoque de desarrollo ASP.NET desde su enfoque de desarrollo WinForms, que ayudó con la curva de aprendizaje si venía del desarrollo de WebForms, pero no es una buena forma de desarrollar aplicaciones web si comprende las diferencias entre los dos enfoques.

El último proyecto en el que estoy trabajando me requirió aprender ASP.NET MVC, JavaScript, jQuery, CSS 2 y AJAX (que no son de Microsoft). Después de solo nueve meses, me siento mucho mejor preparado para abordar proyectos de desarrollo web que después de cinco años de desarrollo de ASP.NET. La implementación de ASP.NET hace las cosas mucho más difíciles de mantener a largo plazo. MVC hace las cosas mucho más fáciles, porque eres menos dependiente de los atajos. Lleva un tiempo aprender el marco, pero cuanto más aprende sobre el marco, menos depende del marco en el que se convierte y más comienza a aprender y comprender los estándares establecidos, como JavaScript y AJAX.

Para mí, es es una clara elección. Nunca volveré a ASP.NET. Si no puedo usar ASP.NET MVC, aprenderé Ruby o PHP. Quiero que el progreso y el avance de mis herramientas de desarrollo web estén motivados por las necesidades de la comunidad de desarrolladores, no por las ganancias.

+2

Debo decir que seguí casi exactamente la misma ruta que tú y que nunca volvería a utilizar ASP.NET WebForms otra vez.Hasta ahora, en los últimos meses aprendí (aún lo hago) JS, jQuery (regular), más sobre estándares HTML y HTTP (que pensé que sabía bien pero no sabía casi nada sobre el interior) y es mucho más fácil para hacer cosas como renderizado parcial, mensajes/visitas de AJAX, control de HTML puro, simplemente todo. MS nos ocultó todo con WebForms, y fue una tecnología agradable y me gustó, pero a partir de ahora solo la mantendré, pero desarrollaré cosas nuevas en MVC. – mare

1

Mi experiencia ha sido con la programación de aplicaciones web para servidores apache en php y ruby. Cuando conseguí un trabajo para mantener una aplicación web escrita en asp.net (formularios web), aprendí a aprender la manera microsoft de crear aplicaciones web. ¡Tendré que decir que estaba completamente mortificada! Estaba pensando que la WTF es toda esta basura viewstate enviada de vuelta hacia adelante. ¿Esto es incluso necesario?

Y luego decidí hacer algunas cosas simples con ajax y jquery, lo que me llevó a actualizar paneles y clientIDs que se generan, y no a lo que configuré en la vista. ¡Qué desperdicio de mi tiempo! ¿Por qué no puedo tener múltiples formularios en una página? ¿Por qué no puedo usar llamadas ajax regulares? ¿Por qué mis vistas tienen lógica de servidor? Estas fueron todas las preguntas que estoy seguro que muchos programadores web enfrentan con formularios web asp.net. Entonces, descubrí .NET MVC. Mi vida se volvió mucho más fácil.

Estaba acostumbrado a usar frameworks MVC como Rails y CakePHP para crear aplicaciones web de la manera en que deberían ser programadas. Con tecnologías realmente pensadas para la web.

Mi sugerencia sería esta, deje WebForms para las personas que están acostumbradas a programar aplicaciones tipo winforms porque intenta abstraer el hecho de que está programando en la web. Si desea tener verdadera libertad para desarrollar aplicaciones para la web que realmente tengan sentido para los programadores web, utilice .NET MVC o algo similar que no se interponga en su camino.

Ésta es mi granito de arena ...

+0

Aunque tengo menos experiencia, solía programar lógica basada en la web usando Perl. Fui de alguna forma a PHP después de eso, y luego ingresé a ASP. Tengo que decir que la forma en que Microsoft siente la necesidad de "microadministrar" todo es un dolor real en el culo. Me gusta mucho C# como lenguaje, y escribir la lógica de negocios es un placer para la vista. Hacer que interactúe con la página web real es una pesadilla. Todo esto se debe a que MS cree que hace todo más seguro (y puede venderlo a los gerentes de negocios de esa manera). No he tocado MVC, pero por lo que he escuchado, ¡necesito esto en mi vida! – Alex

1

para complementar @ respuesta de Ben, que utiliza formularios web ASP.NET para el enlace de datos sencilla, y jQuery para todas las transacciones de Ajax. Para ser sincero, todavía no podía dejar de enlazar datos debido a su simplicidad. Viewstate es casi inútil, así que básicamente lo apago. Sin embargo, puede usar MVC, pero tenga cuidado, le llevará la mayor parte de su tiempo desarrollar funcionalidades que usted da por hecho en Forms. ¡Buena suerte!

0

Ha pasado mucho tiempo desde la pregunta original. Ahora tenemos MVC3 y .NET 4

¿El MVC es ahora una mejor solución que antes?

+0

Respondí esta pregunta en febrero. Hoy, después de mirar profundamente a MVC2 y brevemente en MVC3, elegí quedarme con MVC1. Para mí, no quería caer en la trampa originalmente establecida por WebForms. Quiero convertirme en un mejor desarrollador web, no en un mejor desarrollador ASP.NET MVC. Quiero acercarme más a los estándares HTML/CSS/JS, en lugar de continuar con la abstracción de Microsoft. Estoy usando jQuery y JavaScript mucho más que hace un año. Mi dependencia de las etiquetas de servidor MVC se ha reducido significativamente, porque simplemente no las necesito. Mis páginas son comparativamente más pequeñas. ¿Por qué cambiar? –