español - ¿ASP.NET MVC es una mala opción para un proyecto de una gran empresa?

asp.net mvc versions (11)

"Con MVC, no puede salirse con la pesadilla del estado que es tan común en el desarrollo de formularios web, lo que significa que sus páginas web son meramente adictas a la metanfetamina "

Upmodded para esa cita!

Estamos a punto de embarcarnos en una gran aplicación empresarial. Estoy considerando seriamente usar ASP.NET MVC porque:

Necesitamos usar la tecnología de Microsoft (la lógica de biz es todo C #)
El rendimiento es crítico
Me gustaría probar tanto como sea posible

Mi equipo solo usó PHP para el desarrollo web, pero tiene mucha experiencia con las formas de pago .NET (de todos modos, tenemos una curva de aprendizaje). Mi preocupación es que algunas personas han expresado su preocupación sobre la escalabilidad de ASP.NET MVC para aplicaciones grandes. Pero de lo que leo los webforms tienen sus propios problemas también.

¿Debo reconsiderar los formularios web, o seguir con mi instinto y usar ASP.NET MVC?

Relacionado:

¿Debo construir mi próxima aplicación web en ASP.NET MVC? https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc

ASP.NET WebForms se parece mucho a Winforms y permite RAD (desarrollo rápido de aplicaciones). Es muy rápido obtener algo en poco tiempo. El problema con esto es que las pruebas pueden ser un gran problema y, si se usan para cualquier aspecto público, pueden significar algunos problemas importantes con ViewState. WebForms puede contener el estado haciendo que cosas como un asistente sean fáciles de usar.

Por otro lado, ASP.NET MVC puede tardar un poco más en desarrollarse y requiere que los desarrolladores comprendan cómo funciona HTTP. Es una arquitectura sin estado, lo que significa que cada solicitud es su propio pequeño mundo y, por lo general, no tiene conocimiento de solicitudes anteriores. El marco también permite una alta capacidad de prueba.

En lo que respecta al rendimiento, probablemente sean los mismos porque ASP.NET MVC es solo un marco construido sobre la arquitectura ASP.NET existente. Aunque para la experiencia del lado del cliente, diría que MVC es un poco más rápido.

En cuanto a la escalabilidad, diría que son más o menos lo mismo en términos técnicos. Cómo en cuanto al uso de la API e integrarlo MVC probablemente sería un poco más fácil.

El sitio web que está utilizando en este momento para hacer esta pregunta de la versión está basado en ASP.NET MVC y tienen 2 servidores web y un servidor db robusto.

No. Una cosa que ASP.NET MVC tiene sobre ASP.NET Web Forms en términos de rendimiento es que no hace uso de un árbol de control. El árbol de control consume mucha memoria del lado del servidor y mantiene el recolector de basura muy ocupado en páginas con muchos controles. Yo diría que obtendrás un rendimiento superior del MVC de ASP.NET. Los aspectos de prueba de la unidad son una verdadera victoria para.

La otra cara de esto es que no puedes usar todos los prácticos controles que obtienes con los formularios web de ASP.NET y probablemente terminarás haciendo más desarrollo de JavaScript del lado del cliente, por lo que el presupuesto de desarrollo inicial probablemente debe ser mayor si elige ASP.NET MVC sobre formularios web, pero tendría una solución superior a largo plazo.

Quédate con tu instinto ASP.NET MVC ayuda a facilitar las pruebas porque casi toda la API se deriva de las interfaces.

Todo lo que he leído sobre asp.net MVC dice que es capaz de servir más solicitudes de página que los formularios web asp.net.

Aunque tengo algunas dudas sobre su estabilidad y seguridad. Ambos se derivan del hecho de que ni siquiera se lanzó, e incluso con el RC vimos algunos cambios en el marco. Estoy seguro de que habrá más cambios a medida que pase el tiempo y se encuentren cosas. Es nuevo, por lo que no existen realmente las "mejores prácticas" y no existe una gran cantidad de experiencia que detalla los pequeños problemas o problemas que puede encontrar.

Lo he estado usando y da como resultado páginas más pequeñas y un rendimiento más rápido. Pero hay tantas cosas que puedo hacer en webforms que no tengo ni idea de cómo hacerlo con mvc porque mvc no promueve el uso de los controles de formularios web.

Yo diría que vaya con MVC si necesita o desea sus características. Si está creando una aplicación de línea de negocio, como un sistema ERP o CRM, usaría formularios web; si estás construyendo un portal o un sitio tipo wiki comunitario, yo iría con MVC sin inconvenientes. En definitiva, todo se reduce a las preferencias y lo que su aplicación empresarial precisa lograr.

Los formularios web ASP.NET son pesados y eliminan un montón de cosas en sus páginas web, tanto en html / javascript como en viewview serializado. Recuerdo mi primer sitio web ASP.NET que causó que el GC explotara debido a todos los objetos efímeros que se rehidrataban desde ese deslumbrante viewstate. Oh, cuando era joven e ingenuo (es decir, hace 2 años) ... Debes tener una muy buena comprensión de los formularios web para crear sitios web escalables a partir de ellos. ¿Posible? Seguro. ¿Fácil? No.

ASP.NET MVC es más difícil de codificar inicialmente , pero es TAN mucho más fácil de desarrollar que las formas web. Las cosas más difíciles de aprender son 1) las convenciones también conocidas como "cadenas de magia", 2) HTML + código en línea también conocido como ASP y 3) formularios html.

Con MVC, no puede salirse con la pesadilla del estado que es tan común en el desarrollo de formularios web, lo que significa que sus páginas web son meramente adictas a la metanfetamina. También significa que tienes que codificar tu estado un poco más inteligente. El código también es MUCHO más simple y escalas MUCHO mejor que los formularios web tradicionales, imho.

Además, las pruebas con ASP.NET son casi imposibles, debido a las dependencias rígidas y no codificables integradas en el marco. ASP.NET MVC reemplazó todo esto con miembros de System.Web.Abstractions que son envoltorios simulables alrededor de estos objetos mal diseñados e inestables.

Corre, no vayas, a MVC.

Para el impactado obvio, si usa un marco que se encuentra en la parte superior del marco ASP.NET, como MVC o cualquier otro que haya escrito o que alguien más haya escrito, OBVIAMENTE algunas de estas observaciones no se aplican.

Si, por otro lado, codifica como lo hizo el hombre primitivo contra el modelo de formularios web ASP.NET (por ejemplo, Response.Write () en Page_Load), se aplican mis comentarios.

¿Puedes escribir código que sea comprobable contra ASP.NET? Por supuesto. ¿Puedes hacerlo sin incluir el código de prueba especial que tú o alguien más escribió? Por supuesto. Si tiene TypeMock.

ASP.NET MVC no es un problema para Enterprise, pero tampoco lo son ASP.NET, Silverlight, etc. Son todas las tecnologías de interfaz de usuario. La mayoría de la lógica de la aplicación debe existir en bibliotecas debajo de la capa de IU de todos modos, por lo que prácticamente se puede usar cualquier IU.

Necesitamos usar la tecnología de Microsoft
El rendimiento es crítico
Me gustaría probar tanto como sea posible

En base a lo anterior, ASP.NET MVC funcionará. Pero puede mover el código debajo de la IU y probarlo. Si sus algoritmos están por debajo de la IU, puede sintonizarlos sin alterar la IU. Y, si la capa de IU es muy delgada, el golpe de perforación para la IU es insignificante.

Si puede usar procedimientos almacenados, entonces no necesita un gran nivel medio como los generados por MVC. Todo lo que tiene que hacer es pasar XML a sus procesos almacenados a través de un controlador HTTP simple, obtener resultados de un proceso almacenado y convertir los resultados a JSON. MVC y otras cosas de nivel medio solo sirven para ganar dinero para las empresas que venden IDEs como VS.

He usado WebForms durante años y nunca me han gustado. Ahora usa Asp.Net MVC por algunos años y esto es mucho mejor. Sin duda, recomendaría MVC.

Asp.Net MVC tiene una excelente arquitectura y es de código abierto. Entonces, si identificas los bottelnecks en la cadena de procesamiento de http, puedes arreglarlo. En la mayoría de los casos, podría solucionar problemas de rendimiento utilizando uno de los muchos puntos de extensión proporcionados por Asp.Net MVC, como por ejemplo Binders.

Mi opinión: use ASP.NET Webforms.

Deshabilitar ViewState en Web.Config.

No es necesario preservar el estado porque todo lo que realmente necesita está en el objeto Request. Utilice Javascript junto con AJAX para la recuperación de datos para procesar los controles de su interfaz de usuario desde el lado del cliente.

Cree envolturas en el servidor en forma de etiquetas de control para su procesador de componentes del lado del cliente. Así es como he trabajado durante años, y es rápido, confiable, comprobable y organizado.

Lleva tiempo establecer un marco de trabajo decente para este método de trabajo, pero finalmente lo decidirá.

Prefiero no tener código de espagueti como MVC. He estado allí con PERL / PHP y ASP clásico.