2009-08-25 18 views
7

Actualmente estamos desarrollando un par de controles de servidor asp.net personalizados. Ahora nos gustaría agregar algo de soporte Ajax para algunos de ellos. Ahora, básicamente, habría dos opcionesMicrosoft Ajax Control Toolkit contra jQuery

  • Microsoft Ajax & Microsoft AJAX Control Toolkit
  • jQuery

ya trabajé con el Kit de herramientas de control, escribir un extensor completa y fue bastante intuitiva, una vez que se entender la historia detrás Pero también me gusta la simplicidad de jQuery.

Así que me gustaría escuchar a algunos de ustedes lo que les gustaría (ventajas/desventajas de cada uno de ellos), teniendo en cuenta también que estamos tratando principalmente con las tecnologías de Microsoft. ¿Van a ir más por el kit de herramientas o jQuery, ... o ambos?

// Edición:
que acaba de hacer algunas pruebas y tengo que admitir que en este momento me parece mejor el kit de herramientas debido a la integración. Mi propósito es principalmente para usarlo en los controles de servidor, por lo que con el conjunto de herramientas que tengo clases correspondientes en el lado del servidor en el que puedo hacer algo como

CalendarExtender toolkitCalendarExtender = new CalendarExtender(); 
toolkitCalendarExtender.TargetControlID.... 
... 

this.Controls.Add(toolkitCalendarExtender); 

Esto es muy agradable porque de esta manera no lo hago tengo que lidiar con la representación de JavaScript predefinido que construyo de alguna manera como una cadena dentro de mi control de servidor personalizado. Con jQuery tendría que hacerlo (excepto por el toolkit Nicolas mencionado, pero el soporte allí es demasiado débil para usarlo en un entorno profesional)

Muchas gracias.

+0

¿A qué te diriges? ¿Base de usuario del control? – Perpetualcoder

Respuesta

5

Mientras que estos podrían no ser los principales puntos, me quedo tratar. jQuery no tiene un UpdatePanel: esto es algo bueno. Sus habilidades jQuery se transferirían fácilmente a otra pila como ASP.NET MVC, Django o Rails. Ha pasado un tiempo desde que vi los documentos Ajax de MS, pero la documentación de jQuery es un gran factor para mí; es excelente.

He oído hablar de algunos desarrolladores que utilizan ambas bibliotecas, que también pueden ser algo a tener en cuenta.

+1

Bueno ... el UpdatePanel es algo que preferiría evitar. Puede conducir a problemas importantes de rendimiento. Usar ambos podría ser una opción, sí ... – Juri

+2

El Panel de actualización es un juguete brillante para desarrolladores principiantes. Una vez que te vas a ajax nunca vuelves. –

2

El primer y más importante punto en mi opinión es la base de usuarios para estos dos.

Creo que jQuery tiene un amplio grupo de usuarios en comparación con Microsoft Ajax. Así que el soporte para jQuery será mucho más.

4
  1. Tiene mucha más documentación para jQuery que para Microsoft ajax.
  2. La base de usuarios de jQuery es mucho más grande
  3. Usted tiene un montón de plugins para jQuery
  4. bonificación: jQuery tiene un nombre fresco :-)
3

De vez en cuando uso ambos. Algunas veces el MS AJAX Toolkit es súper útil para ciertas cosas y otras veces es simplemente un desastre. jQuery es ideal para muchas cosas, pero a veces puede ser limitado.

Sin embargo, me gustaría equivocarme al lado de jQuery ya que no importa a qué plataforma vaya, jQuery siempre será aplicable ya que está completamente basado en el cliente, mientras que las habilidades de MS AJAX Toolkit no lo ayudarán si usted decide para probar otra plataforma del lado del servidor.

3

Para mí, usaría AjaxControlToolkit solo cuando el complemento jQuery no exista. Además, con el uso de jQuery control Toolkit, puede usar jQuery con controles de servidor. Eche un vistazo en codeplex

+0

gracias por la propina. Todavía no escuché sobre jQuery Toolkit. Thx – Juri

+0

+1 es la primera vez que oye hablar sobre los controles del servidor jquery, gracias :) –

0

Si codifica principalmente en MS Shops con Visual Studio, entonces el kit de herramientas es el camino a seguir, aún necesitará saber algunos javascript para hacer algunas cosas, pero en esta situación el kit de herramientas permite un desarrollo realmente rápido y algún código detrás del soporte para ciertos controles. Dicho esto, nunca está de más aprender ambas cosas, el kit de herramientas es realmente sencillo, por lo que la curva de aprendizaje es pequeña y, en cierta medida, depende principalmente de su conocimiento de javascript, por lo que es jquery. La mayoría de las aplicaciones que estoy viendo ahora usa ambos y funciona bastante bien y una vez que aprendes lo suficiente de cada una, podrás decidir qué usar donde ... básicamente ambas crean una caja de herramientas más grande y una gran caja de herramientas es siempre una gran ventaja para ti. tener.

1

Nunca me emocioné con el kit de herramientas Ajax. Parecía torpe e hinchado.

Cuando me topé con jQuery nunca miraron hacia atrás ...

0

no son controles web supone que la aplicación cliente abstracta hasta cierto punto? Y si es así, ¿no es factible que la MS implemente el kit de herramientas de Ajax usando jquery algún día?

Jquery es genial y me gusta jugar con él, pero también hay algo muy duradero sobre los controles web en el sentido de que su implementación puede actualizarse automáticamente junto con las tecnologías del cliente.

1

JQuery permite que su aplicación esté libre de versiones de ASP.NET. Usamos MS AJAX toolkit y tuvimos que preocuparnos por sus versiones y ver si es compatible con ASP.NET 2.0, etc. Comenzamos a usar los controles JQuery y encontramos que nuestra aplicación era mucho más rápida y nuestros controles podían evolucionar independientemente de las versiones .NET . Incluso podríamos descartar .NET a favor de PHP ya que la mayoría de nuestras cosas están basadas en WebService. Por lo tanto, para la presentación, podría tener páginas HTML simples con JQuery y la mayoría de las otras cosas se pueden implementar como WebServices.

3

Razones para la API jQuery más AjaxControlToolkit:

  1. No había problemas con "DLL Hell" cuando otro desarrollador recoge el proyecto
  2. ampliable a otras tecnologías del lado del servidor
  3. Mucho mejor documentación (ACT vs JQuery)
  4. No tiene que preocuparse por la versión de .NET Framework que el servidor y el desarrollador están usando para usar una versión específica
  5. Toda la fuente se mantiene en una sola.archivo JS por lo que no hay duda en cuanto a lo que hay que ir a donde para el despliegue
  6. No requiere compilación JIT de librerías de código adicionales en el servidor
  7. Más funcionalidad granular para que pueda tomar una mayor variedad de interfaces de
    1. Es decir, mientras puede hacer un control de acordeón con cualquiera de los marcos, puede extender mucho más fácilmente el JQuery para decir, tener 2 paneles abiertos a la vez o realizar otra acción en otro lugar de la página cuando se abre, o elimine una de las secciones según la acción del cliente (es decir, si no puede encontrar un control donde alguien ya lo haya hecho)
    2. También sabe exactamente cómo de detrás de su sitio funciona y no hay una "caja mágica negro" que participan en el comportamiento de su sitio
  8. No requiere espaldas de correos para llevar a cabo cuantas acciones
  9. funciona bien con cualquiera de las formas o MVC
  10. Biblioteca de controles personalizados es mucho más extensa y con el apoyo de ACT entonces que
2

Si está utilizando formularios Web (controles de servidor), usted debe utilizar extensores de organizar la secuencia de comandos y proporcionar una presencia en el servidor para él. Dado que ya existe un conjunto de herramientas completo (Ajax Toolkit), esa es la mejor opción, pero si realmente desea usar JQuery, escriba sus propios extensores que llamen a JQuery. Sin embargo, si está utilizando MVC, simplemente use JQuery desnudo; está incluido en esas aplicaciones de forma predeterminada, y no hay controles del lado del servidor que necesiten extensiones del lado del servidor para corresponder.

Cuestiones relacionadas