¿Hay algunas cosas que no puedo hacer con ASP.NET MVC? Las cosas que solo son posibles con WebForms de ASP.NET, o extremadamente son mucho más fáciles con WebForms?Cosas que no puedo hacer en ASP.NET MVC
Consideramos usar ASP.NET MVC para un nuevo proyecto. Pero me pregunto si hay algunas cosas obvias que no podremos hacer con ASP.NET MVC en comparación con WebForms, o lugares donde tendremos que pasar mucho tiempo con ASP.NET MVC.
El más grande estaría utilizando controles existentes de terceros en su formulario. La mayoría de los controles incorporados son bastante fáciles de reproducir, pero si tienes un control de terceros, podrías tener que alojarlo en una página aspx normal (no MVC) (afortunadamente esto es compatible).
Del mismo modo, "partes" web
también - la característica que ASP.NET utiliza diferentes html para diferentes clientes (móviles, etc.) se convierte en ... diferente; usted no querría hacer esto a mano, pero en realidad la mayoría de los clientes ahora trabajan con html estándar, por lo que es un problema menor en primer lugar.
Algunas cosas como i18n a través de archivos resx necesitan más trabajo que en la plantilla MVC de vanilla, pero las muestras están allí en Internet.
Un punto ... MVC tiene licencia solo para MS/ASP.NET; así que una cosa que no puedes hacer (sin violar los términos, según tengo entendido) es ejecutarla en mono/Apache, pero IANAL.
Consideremos ahora las cosas que puede hacer con MVC, que no puede (o son duros) con vainilla:
re resolución de entrada:
public ActionResult Show(string name, int? page, int? pageSize) {...}
seleccionará "nombre", "página" y "página Ajuste "off" (cualquiera de) la ruta, cadena de consulta o formulario, para que no tenga que perder mucho tiempo seleccionando valores de solicitud.
re plantillas - aspx/ascx no son las únicas opciones de plantillas. Por ejemplo, ver here; o puede escribir uno propio si lo desea ... La vista no está vinculada a los controles ASP.NET en absoluto.
Creo que el estado de vista no existe en MVC. Tendrá que seguir su propio estado de vista de otra manera que el estado de vista incorporado en proyectos que no sean MVC.
EDIT: De acuerdo con los comentarios: "Deshacerse de ViewState no es una ventaja desventaja". - Craig
MVC tiene una colección de clave/valor de ViewData que persiste sobre las publicaciones para mantener el estado. una colección TempData también se usa para cambios de estado únicos: ej. mensajes de estado "este registro fue eliminado" –
ViewState es parte del modelo de devolución de datos de WebForms y no tiene uso en MVC, del mismo modo que no se usa con PHP o Python. Deshacerse de ViewState es una ventaja, no una desventaja. – Craig
+1 para Craig.Viewstate es una cosa mejor y más mediocre, y en las peores situaciones es una completa abominación. Es mejor que nos deshagamos de eso. – Kibbee
El grande es Controles. Los controles de usuario no están disponibles con ASP.NET MVC. Incluso he llegado a intentar usar un código como este:
new Label().RenderControl(...ResponseStream...);
No dice ningún dado.
Por supuesto, como parte de eso, no hay necesidad de ver el estado, por lo que no está allí.
Los controles de servidor sí funcionan.
Si bien es cierto, puede usar vistas parciales para algo similar –
esto es por diseño: el enfoque MVC intenta crear simplicidad y un mayor control sobre qué marcas se representan –
MVC tiene controles de usuario, no tiene controles de servidor, ya que están diseñados para ir con el modelo de WebForms. Debido a que MVC no pretende ser una operación de arrastrar y soltar, no se requieren controles de servidor para el desarrollo de tipo impulsado por evento. No es un descuido, es una decisión de diseño. – Craig
Como dijo Marc, las herramientas de terceros y los controles web (en el servidor) no se pueden usar. Así que juntar algo rápidamente arrastrando y soltando algunos controles en un formulario (como una cuadrícula y un control de acceso a datos) ya no es una opción.
Pero con la generación de código, etc., puede hacer algo rápidamente. Y todavía tienes la opción anterior si necesitas algo rápido.
La validación no es tan fácil como en WebForms. En Webforms puede agregar un validador y simplemente establecer una propiedad que habilite la validación del cliente. Puede localizar el mensaje de error. La localización funciona en el lado del cliente y en el lado del servidor.
No hay una validación de cliente fuera de la caja en MVC y debe encontrar una forma de localizar los mensajes de error del lado del cliente.
La localización en sí es diferente. Los recursos obviamente por defecto no existen por página, porque no hay página. Pero hay una buena manera de tener recursos por vista.
Todavía no compruebo, si es posible configurar SSL-required por carpeta.
EDITAR
La historia es diferente con MVC3. Hay un buen soporte de validación ahora.
Todavía hay cosas que no están implementadas en MVC. El mayor problema para mí es una implementación completa para el cobro de donuts y cobro parcial. Hay alguna mejora en MVC3 en esta área, pero aún no está completa. De todos modos, estén atentos: el equipo de MVC parece estar consciente de que esto es algo en lo que deberían trabajar.
Gracias por los comentarios. En cuanto a la validación de servidor/cliente, encontré xval (http://xval.codeplex.com) que parece ofrecer una solución para eso ... –
La validación ha mejorado mucho en MVC2 –
.. y aún más en MVC3 –
ASP.NET Ajax no funciona con ASP.NET MVC por lo que no hay UpdatePanel (debido a la falta de devolución de datos). Afortunadamente, hay un ajax incorporado (Ajax.Form) que se puede usar para realizar actualizaciones parciales, sin mencionar jQuery, que se envía por defecto con la plantilla de proyecto de Visual Studio.
Gracias por la buena respuesta, lo que me hace estar más seguro de que es relativamente seguro ir por mvc. Sin embargo, no entiendo qué hay detrás de sus puntos con 'resolución de entrada automatizada', 'IoC/DI' y 'múltiples opciones de plantillas'. ¿Tienes algunos ejemplos de lo que quieres decir con eso? –
actualizado por pregunta –
ASP.Net MVC es de código abierto bajo el MS-PL, que es una licencia muy liberal, ver http://weblogs.asp.net/scottgu/archive/2009/04/01/asp-net- mvc-1-0.aspx. Es perfectamente legal correr bajo mono. – jeroenh