¿Es MVC la mejor manera de codificar aplicaciones asp.net?

Question

actualización: Sé que no hay una mejor manera de hacer todo. Perdón por no decir eso de inmediato. En el contexto de los tutoriales de acceso a datos, si tuviera que hacer el proyecto que hizo en ese tutorial, ¿haría lo que hizo o usaría usar MVC, si tuviera que elegir uno de ellos?

Actualización: Es MVC la forma más adecuada para programar aplicaciones ASP.NET, en lugar de los tutoriales que aparecen aquí:

http://www.asp.net/Learn/data-access/

original:

te pido, porque aprendió inicialmente sobre MVC con aplicaciones Java, luego cosas como RoR y Django. Estos otros proyectos y compañías hablaron como si MVC hubiera existido por mucho tiempo, y por lo que descubrí que tenía. Entonces Microsoft comenzó a poner MVC en .NET Framework.

Lo pregunto porque no sé cómo diseñar las cosas muy bien y pensé que estaba haciendo bien para emular lo que está en el sitio asp.net con el tutorial de Scott Mitchell. Pensé que la creación de capas abstractas en un BLL era el camino a seguir hasta que descubrí MVC y ahora el MVC de asp.net.

Honestamente, no sé cuál es la forma "correcta" de hacer las cosas. Solo creo lo que necesito, pero no puedo evitar sentir que me falta algo.

MVC es la forma correcta de empezar a hacer cosas en proyectos grandes, específicamente me refiero a MVC y ASP.NET, pero también podría significar PHP y uno de sus frameworks MVC.

Me gustaría establecerme en una forma estándar de hacer las cosas ... por ahora de todos modos.

Y, por curiosidad, ¿por qué Microsoft solo ahora comenzó a hacer MVC?

ACTUALIZACIÓN: ¿Es MVC mejor que el tutorial actual establecido en asp.net?

Me refiero a los tutoriales de Scott Mitchell donde crea el BLL para la abstracción. ¿O es una pregunta también? Debería haber dicho que entiendo la necesidad de mantener la lógica y la presentación por separado, pero no estoy seguro de la mejor manera de hacerlo. Estaba usando los tutoriales de asp.net. Funcionó bien Luego descubrí que el resto del mundo, como lo vi de todos modos, estaba usando MVC. Entonces Microsoft comenzó a desarrollar MVC, por lo que para mí el otro método parece obsoleto y la forma incorrecta de hacer las cosas.

Answer 1

No, no es la única manera de hacer las cosas.

MVC es solo un patrón de diseño. El objetivo de todos los patrones de diseño es la simplicidad. Por lo tanto, siempre que simplifique su diseño, acéptelo. Si hace las cosas más complejas para su aplicación específica, pruebe con un enfoque diferente.

Desafortunadamente, algunas personas piensan que si ven un patrón, deberían usarlo. Simplemente no es verdad. Los patrones de diseño no mejoran inherentemente su aplicación. Ellos no son un final. Son un medio para un fin (que es simplicidad). Entonces debería usarlos solo si valen la pena.

En mi opinión, sobre-diseñar cosas sin una buena razón es peor que escribir código sin ningún diseño específico.

EDIT: En cuanto a ASP.NET MVC: Tengo un sesgo personal negativo hacia los formularios Web de ASP.NET. Antes de MVC, hice la mayoría de los aspectos dinámicos de proyectos avanzados al escribir controladores personalizados para tener un control detallado sobre el HTML. Los formularios web hacen que el desarrollo web sea muy fácil, pero tienen particularmente un par de cosas que son buenas pero que a veces son problemáticas. El primero de los cuales es ViewState y el segundo es la arquitectura compleja WebControl. No me malinterpretes Esos son signos de brillantez de ASP.NET. No he visto una sola plataforma para desarrollo web tan fácil como ASP.NET Web Forms y esto solo se debe a la gran compatibilidad con WebControl que requiere ViewState. Sin embargo, en algunos proyectos, usted quiere tener un control preciso sobre el HTML renderizado (especialmente cuando tiene alguna lógica del lado del cliente). También desea que el código del lado del servidor se pueda mantener en proyectos grandes. En esas áreas, ASP.NET MVC realmente brilla. Pero creo que ASP.NET Web Forms seguirá siendo una gran tecnología donde sea más aplicable. Después de todo, como dije sobre los patrones de diseño en general, debe evaluar cuidadosamente su diseño para ver cuál se ajusta mejor a sus necesidades.

Específicamente, sobre el acceso a datos, MVC generalmente requiere más código que las contrapartes de Web Forms. Para presentar datos tabulares (es decir, donde se aplica GridView), creo que ASP.NET Web Forms es la manera más fácil de lograr cosas. Sin embargo, la mayoría de las aplicaciones web basadas en datos no solo manipulan una tabla directamente en una base de datos. Tienen un diseño complejo. StackOverflow es un gran ejemplo de esto. Sin duda, se basa en datos, pero ASP.NET MVC es más adecuado.

Answer 2

MVC es solo una forma de hacer las cosas. Me gusta porque ayuda a promover la extensibilidad y está estructurado para permitir la prueba y la reutilización de código. No hay una bala de plata, una verdadera forma de hacer todo, pero la uso con bastante frecuencia.

Con respecto a Microsoft, diría que adoptaron el patrón como una alternativa al desarrollo de WebForms por las razones que mencioné anteriormente. Recomendaría mirar Rob Conery's MVC Storefront y jugar con los ejemplos para ver cómo funciona para usted.

Answer 3

No hay una forma "correcta" de hacer las cosas sin saber qué son las "cosas". MVC es un design pattern que resuelve un problema común específico: separación de la lógica de presentación y de dominio. Cada patrón de diseño es una solución "válida" comúnmente aceptada para un problema específico.

Esas soluciones, combinadas con el conocimiento y la experiencia, son los cimientos para un buen diseño. La forma "correcta" de hacer las cosas es estudiar el dominio de su problema, investigar sobre posibles soluciones y aplicar el conjunto de soluciones que mejor funcionan para resolverlo. Cometer errores también es parte del proceso, así que no tema experimentar y luego refactor con rigor hasta llegar a la solución que le sirva mejor.

Answer 4

MVC es la peor forma de desarrollar aplicaciones, a excepción de todas las demás formas que se han probado. :-)

Bromas aparte, MVC es un diseño de aplicación que nos alienta a no escribir código de espagueti. Es una guía que nos recuerda mantener el código comercial separado del código de presentación. Esto es muy útil ya que la aplicación se vuelve más compleja.

Existen otras variaciones que logran el mismo beneficio, pero no son estrictamente las mismas que MVC. Presentation-abstraction-control (PAC) es un ejemplo.

En cuanto a por qué Microsoft está tan retrasado en la adopción de MVC, no me sorprende que lo sean. Son bastante conocidos (al menos en los últimos años) por ser conservadores en lugar de innovadores. Prefieren dejar que otras empresas más pequeñas asuman los riesgos en un mercado no probado, luego aprenden de los errores, crean una solución competitiva sobreestimado y dominan a través del marketing.

Ejemplo: Microsoft Internet Explorer se consideró un participante tardío en el mercado de los navegadores. Netscape se había vuelto muy popular, marcando el camino al proporcionar una plataforma para que las personas vean HTML. Una vez que la cantidad de contenido HTML en Internet estaba en un nivel útil, Microsoft renunció a su producto onomatopéyico "IE" y rápidamente capturó una cuota de mercado abrumadora.

Answer 5

No hay una "mejor" forma de codificar cosas. Depende de la aplicación en cuestión; a veces MVC es la elección correcta, y otras no. Un buen desarrollador es capaz de sopesar su/sus opciones y elegir la que mejor se adapta para una tarea en cuestión, en lugar de ir con el método du jour

Answer 6

Si MVC resuelve el primaria imperativo técnico de gestión complejidad en su aplicación, entonces puede ser una buena solución, pero de ninguna manera es la única solución.

Answer 7

MVC es uno de los muchos patrones de diseño. Si es el mejor tecnológicamente, o el más simple, o para qué tipo de proyectos es apropiado, son todos discutibles (ver otros hilos SO). En cualquier caso, pocos argumentarían contra el consenso prevaleciente de que para la mayoría de los casos, es "suficientemente bueno".

Pero tiene el innegable beneficio de que mucha gente lo usa, en muchas plataformas diferentes.

Por lo tanto, si desea utilizar una metodología que probablemente durará un tiempo; o no desea depender de un proveedor para soporte y extensión y refinamiento; o trabajas en un grupo al que le gustaría crecer mediante la contratación de personas de diversos orígenes que asimilarán rápidamente una metodología compartida; o si desea maximizar sus oportunidades de seguir adelante si lo necesita, entonces MVC es una de las mejores maneras de respaldar esos objetivos.

Answer 8

MVC siendo el patrón "Mejor" o "Peor" es relativo al proyecto.