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

Question

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

1. Tenemos que utilizar la tecnología Microsoft (lógica de negocio es todo C#)
2. rendimiento es crítico
3. me gustaría probar tanto como sea posible

Mi equipo solo ha usado PHP para el desarrollo web, pero tiene mucha experiencia con .NET winforms (así que de cualquier manera 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.

¿Debería reconsiderar los formularios web, o seguir con mi intuición y usar ASP.NET MVC?

relacionadas:

Should I build my next web app in ASP.NET MVC? https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc

Answer 1

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.

ASP.NET MVC, por otro lado, puede tardar un poco más en desarrollarse y requiere que los desarrolladores entiendan 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.

Por lo que respecta a la escalabilidad, diría que son prácticamente iguales en lo que a técnica se refiere. 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 ahora mismo para hacer esta pregunta de la versión está basado en ASP.NET MVC y tienen 2 servidores web y un servidor db de gran tamaño.

Answer 2

Stick con los intestinos. ASP.NET MVC ayuda a facilitar las pruebas porque casi toda la API se deriva de las interfaces.

Answer 3

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 viewstate 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 comprender muy bien 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 código inicialmente, pero es SO mucho más fácil de desarrollar que los formularios 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 se puede librar con la pesadilla estatal que es tan común en el desarrollo de webforms, 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 horneadas 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 impared evidente, si se utiliza un marco que sienta el ontop del marco ASP.NET, como MVC o cualquier otro que escribió o que alguien más escribió, OBVIAMENTE algunas de estas observaciones no aplicar

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.

¿Se puede escribir código 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.

Answer 4

Yo diría que vaya con MVC si necesita o desea sus funciones. 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.

Answer 5

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 puede usar todos los prácticos controles de la caja que obtiene con los formularios web de ASP.NET y probablemente terminará realizando más desarrollo de JavaScript del lado del cliente, de modo que la inicial El presupuesto de desarrollo probablemente debería ser mayor si elige ASP.NET MVC sobre formularios web, pero tendría una solución superior a largo plazo.

Answer 6

Todo lo que he leído sobre asp.net MVC dice que puede atender 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 hay una gran cantidad de experiencia que detalla los pequeños problemas o problemas que puede encontrar.

Lo he estado utilizando 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.

Answer 7

"Con MVC, no puede salirse con la pesadilla estado que es tan común en los formularios web de desarrollo, lo que significa que los medios sus páginas web son meth-adicto delgada"

Upmodded para esa cita!

Answer 8

ASP.NET MVC no es un problema para Enterprise, pero tampoco lo son ASP.NET, Silverlight, etc. Todas son tecnologías UI. 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.

1. tenemos que utilizar la tecnología Microsoft
2. rendimiento es crítico
3. me gustaría probar tanto como sea posible

base en 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.

Answer 9

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.

Answer 10

Mi opinión: use ASP.NET Webforms.

Deshabilitar ViewState en la Web.Config.

No es necesario conservar 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 envoltorios del lado del servidor en forma de etiquetas de control para su procesador de componente del lado del cliente. Así es como he estado trabajando desde hace años, y es rápido, confiable, comprobable y organizado.

Lleva cierto tiempo establecer un marco de trabajo decente para este método de trabajo, pero eventualmente prevalecerá.

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

Answer 11

He usado WebForms durante años y nunca me gustaron. 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á solucionar problemas de rendimiento utilizando uno de los muchos puntos de extensión proporcionados por Asp.Net MVC, como por ejemplo Binders.