Aspnetcore: ¿MVC es demasiado complejo para ser utilizable?

Si no eres fanático de los ORM (mapeadores de relaciones de objetos) como EntityFramework, puedes escribir el SQL a mano usando ADO.NET. También puede usar un ORM liviano como Dapper que no genera consultas (puede escribirlas a mano). EntityFramework también tiene un método ExecuteSQL para darle más control cuando sea necesario (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql).

Además, si MVC parece demasiado complejo para páginas simples, pruebe Razor Pages

Le sugiero que siga uno de los muchos tutoriales de MVC; uno no puede esperar entender algo como por arte de magia solo con 5 minutos mirando la nueva plantilla de proyecto.

En cuanto a la simplicidad relativa a los formularios web, les recuerdo la desgracia de viewstate, runat=server y dios nos salve a todos del ciclo de vida de la página.
Atentamente

Esto es divertido.

Me parece bastante sencillo.

Además, si MVC parece demasiado complejo para páginas simples, pruebe Razor Pages

Acabo de terminar un proyecto de migración de WebForms -> RazorPages. Para ser honesto, podría haber sido simplemente MVC, pero definitivamente una buena opción para sitios web pequeños 'centrados en páginas'. En los proyectos de MVC, encuentro que estoy 'cazando' demasiado el código, es decir. saltando de Vista a Controlador constantemente, desplazándome a través de montones de Acciones mientras que en RazorPages voy directamente a PageModels.

Odio el EF inflado: Dapper es mucho más simple, especialmente si se usa con algo como Dapper.FastCRUD

No eres solo tú @ LJ9999 , MVC y cualquier marco no tiene todas las respuestas. Puede que no sea la estructura que mejor se adapte a su proyecto, y puede que no encaje con su forma de pensar. No es necesario que intentes encajar clavijas cuadradas en agujeros redondos a menos que te guste el autocastigo.

MVC es una de tus opciones. Evalúe algunos enfoques diferentes y elija el que mejor se adapte a sus necesidades. Encuentra algo que tenga sentido para ti. Encuentra (o crea) algo en lo que seas más productivo. No se deje llevar por lo que es popular. Lo popular no siempre tiene que ver con el mérito, e incluso lo que es mérito para un caso no funciona en otro.

Así que permítanme unirme a ustedes en mi escepticismo sobre la forma más común en que se hacen las cosas. Ser escéptico sobre el enfoque que todos adoptan y pensar críticamente y por uno mismo es un buen lugar para comenzar. Si crees que puedes hacerlo mejor, probablemente puedas hacerlo. ¡Ve a por ello!

Para cualquiera que lea y sienta esto como un ataque contra ellos y su forma popular elegida, en realidad no es un ataque contra ti. Está diciendo encontrar lo que funciona para usted. Así que es solo una declaración sobre cómo, mientras que las computadoras pueden funcionar todas en el mismo lenguaje, las mentes de las personas no. Todo el mundo es diferente, y eso es genial.

+1 a Dapper, úsalo.

En cuanto a por qué usa el marco de entidad, es una manera rápida y fácil de expresar su comportamiento deseado en el mismo idioma en el que define su código, con soporte de generación de código (léase: tiempo de comercialización reducido). Sin embargo, generalmente no lo uso, y tú tampoco tienes que hacerlo.

Parece que puede estar más en desacuerdo con su uso en un ejemplo. La respuesta a eso es el público objetivo: más personas están versadas en paradigmas ORM en 2019 que las que realmente son expertas en SQL. SQL no está muerto, solo tiene mucha competencia fuerte con una alta penetración en el contingente de desarrolladores más jóvenes.

Como alguien que ha pasado por cada iteración de Asp.Net y MVC hasta lo que tenemos ahora con Asp.Net Core, puedo decirle que depurar errores del ciclo de vida de la página e intentar crear cualquier cosa de relativa complejidad con formularios web fue una pesadilla en comparación. a MVC. WebForms oculta gran parte del trabajo real que se lleva a cabo detrás de lo que parecen ser eventos mágicos. Abstrae toda la forma en que funcionan las solicitudes web al tratar de tomar su mano y pretender que la web no es apátrida. Te miente y te dice que eres bonita y que tu trasero se ve bien en esos jeans. Construye falsamente su confianza y hace que las tecnologías web sean confusas. Y felizmente continúa con su día pensando que si puede crear una página web con un formulario y guardarlo en una tabla, entonces puede hacer cualquier cosa. Hasta que obtenga ese nuevo requisito para crear un formulario dinámico personalizado. O hacer que algo funcione con este marco del lado del cliente en particular, porque el cliente piensa que es bonito. Te das cuenta de que ahora estás trabajando contra la corriente y te preguntas cómo lo están haciendo los demás.
MVC no es ciencia espacial, es un patrón probado que ha evolucionado en la comunidad de desarrollo después de darse cuenta de que "tiene que haber una mejor manera" y años de pegar clavijas redondas en agujeros cuadrados. Si cree que es complicado, probablemente se deba a que no ha encontrado ninguno de los problemas que se supone que debe solucionar y no ha dedicado suficiente tiempo a resolver problemas complejos. Comience con tutoriales más simples si este es abrumador.
Si decide que esto no es para usted, siempre hay PHP o NodeJs.

Para algo que es más que una unión trivial, simplemente usaría ExecuteSQL de EF. Creo que podría subestimar la complejidad que podría estar tratando de representar porque no tiene una forma de nombrar las tablas de unión de forma lógica y es posible que deba ser flexible con la asignación de la oficina. Si no te gusta EF, no estás solo. La mayoría de las personas que usan MVC probablemente no estén usando EF. Uno no requiere del otro.

Personalmente, creo que los formularios web son mucho más complicados que MVC porque tienen una lógica de eventos muy compleja que oscurece lo que en realidad es un ciclo de respuesta de solicitud. MVC para alguien que nunca ha pensado en ello es difícil al principio porque es un modelo diferente de organización, pero después de años de uso, la industria parece haber decidido que MVC es en realidad más simple a largo plazo. Es solo una cuestión de preferencia, pero abrir un ticket como este en una tecnología que ha sido la corriente principal durante años es solo desahogo.

Recomiendo aprender MVC con ejemplos que no usan el marco de entidad para que aprenda un solo concepto a la vez. Sin embargo, este no es realmente el lugar correcto para conversar al respecto.

Dios mío, me estoy riendo tanto en este momento.

Mira amigo, si parece demasiado difícil o complejo, aléjate y usa otra cosa. Nadie te está apuntando con un arma a la cabeza, ¿verdad?

Algunos de nosotros hemos estado alrededor del bloque varias veces y preferimos la simplicidad de asp mvc sobre los formularios web porque hemos tenido que lidiar con la horrenda pila de código espagueti no comprobable que surge de las monstruosidades monolíticas de los formularios web.

Pero en serio, si te gustan los formularios web y alguien está dispuesto a pagarte para codificar formularios web, ¡entonces hazlo! Y deja de quejarte por cosas que no entiendes.

¿Es esta una publicación de sátira? No estoy seguro si en reddit o github...

He trabajado en el desarrollo de ERPs bajo formularios web Asp.net y Asp.net MVC para dos sistemas diferentes, puedo decir con confianza que trabajar en formularios web es una tortura, especialmente cuando tienes una solución enorme con una arquitectura deficiente, y al contrario MVC puede convertir mágicamente una arquitectura de aspecto feo en una solución de alto nivel con la capacidad de organizar capas y hacer uso de un patrón de repositorio con ORM fuerte y confiable como EF.
pero, sinceramente, la mayoría de los desarrolladores que he conocido que se quejan de MVC tienen una experiencia y un conocimiento limitados del nuevo patrón.
Personalmente, aconsejo a los desarrolladores que quieran aprender MVC de cero a héroe que prueben https://www.pluralsight.com en lugar de recorrer la web y perder tiempo y dinero en temas controvertidos y blogs sobre MVC que, en muchos casos, son sesgados o deficientes. en el contexto.

Wow, eso de que el tiempo ha cambiado a los desarrolladores es realmente cierto. Elogié a Microsoft por lo fáciles y directos que eran EF y MVC cuando los encontré por primera vez en 2013. Como ya se ha dicho, ¡comprender estos marcos no sucede automáticamente por arte de magia! Sigue los tutoriales, mira algunos de los cientos de videos que hay e inténtalo de nuevo. Lo siento hombre, pero desarrollas una comprensión de estas cosas a medida que pasas tiempo con ellas.

Estoy de acuerdo con el autor. Para aquellos de personas que usan mvc por primera vez. El enfoque no es tan amigable como otros como php, rail... demasiado concepto para entender antes de usarlo. Sin embargo, una vez que entiendes el concepto, mvc parece ser muy efectivo.

¿Por qué alguien odiaría el marco de la entidad? No he tenido que escribir más de 5 consultas SQL en los últimos tres años.

Si bien esto no es ciencia espacial, al final hay algo de ciencia detrás de esto y, como con todo, puede llevar algo de tiempo y esfuerzo comprender completamente, estoy con el autor original, que MVC y las muestras son un poco abrumador cuando se trata de comprender todo de una sola vez, tal vez si hubiera una especie de hoja de trucos para usar al aplicar conocimientos o conceptos de otros marcos, podría hacer que el aprendizaje de MVC sea más llevadero para aquellos que lo encuentran desafiante.

Si bien los comentarios siempre se agradecen, porque si alguien se queja, significa que hay algo que mejorar, por otro lado, si investiga un poco las publicaciones del autor, encontrará que es muy vocal y compara muchas cosas con ciencia espacial.

Algunas muestras:
https://github.com/dotnet/docs/issues/9115
https://github.com/dotnet/docs/issues/9299
https://github.com/dotnet/docs/issues/9274
https://github.com/dotnet/docs/issues/9234
https://github.com/MicrosoftDocs/azure-docs/issues/20313
https://github.com/dotnet/docs/issues/9396
https://github.com/aspnet/EntityFramework6/issues/671
https://github.com/aspnet/EntityFramework6/issues/686
https://github.com/twbs/bootstrap/issues/27783
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2237
https://github.com/aspnet/EntityFramework.Docs/issues/1254
https://github.com/aspnet/EntityFramework.Docs/issues/1240

Incluso cuando las cosas no son ciencia espacial, aún pueden ser complicadas y requieren paciencia para estudiar. Leer más sobre el tema en lugar de quejarse de que es demasiado difícil puede ser un buen punto de partida.

Parece que sus problemas no son con MVC, sino con Entity Framework. Para algunos de nosotros que nos sentimos cómodos escribiendo SQL, Entity Framework agrega una capa de abstracción no deseada. Personalmente, uso Dapper, que hace que el uso de Readers sea mucho más fácil. Todavía puedes escribir tu propio SQL. MVC es un patrón bastante simple. Se vuelve un poco más complicado comprender cómo pasar datos hacia adentro y hacia afuera y cómo usar algunas de las funciones auxiliares de manera efectiva, pero conceptualmente no es difícil.

MVC no requiere el uso de EF, aunque la autenticación de usuario integrada lo usa.

Amigos, comenten con ayuda o positivismo, pero no con burla. El OP parece tener preocupaciones con EF, y el comentario de David es excelente. https://github.com/aspnet/AspNetCore/issues/7039#issuecomment-457869924

Problemas es un lugar para ayudar. Si desea discutir los méritos de MVC frente a otra cosa, pruebe uno de los otros sitios de quejas populares de Internet.

Hola, bienvenido @LJ9999 . Desearía que más personas hicieran preguntas como esta.
Comenzaré diciendo que esta es simplemente mi opinión, así que siéntete libre de estar de acuerdo o en desacuerdo con algo o con todo.

Estoy totalmente de acuerdo en que el desarrollo web/software es difícil. Yo personalmente llevo años estudiando y experimentando para ganar la experiencia que tengo. Cada vez que quiero usar un nuevo marco o biblioteca, todavía es difícil. Requiere que pase más tiempo aprendiendo y experimentando nuevamente para sentirme cómodo y seguro al usarlo. A medida que he aprendido más y más a lo largo de los años, creo genuinamente que me he vuelto mejor y más rápido en el aprendizaje, por lo que se vuelve más fácil.
A lo largo de los años, creo que los desafíos involucrados han cambiado. Algunas cosas se han vuelto más fáciles, sin embargo, también se han introducido nuevos desafíos. En general, sin embargo, creo que es mucho más fácil ahora en comparación con cuando empecé. También creo que es una experiencia menos frustrante y la encuentro más agradable.
Habiendo dicho todo eso, creo que como industria siempre podemos seguir esforzándonos por mejorar. Creo que son preguntas como esta las que resaltan los desafíos que enfrentamos e inspiran la necesidad de seguir mejorando la situación.

Quiero tener especial cuidado de no recomendarle que elija una solución u otra porque no creo que haya suficiente información para hacerlo.
Uno de los mayores desafíos que encuentro con la resolución de problemas es identificar el problema real que se está resolviendo. Sería muy fácil categorizar este problema como la necesidad de "construir un sitio web", sin embargo, con tantas soluciones para elegir para "construir un sitio web", cualquiera de ellas podría funcionar. El problema debe desglosarse tanto como sea posible porque esto proporciona un criterio para evaluar las diferentes soluciones.
En segundo lugar, todos tenemos preferencias personales. Tienes derecho a los tuyos y nadie puede decirte qué prefieres o con qué te sientes más cómodo trabajando. Esto está completamente basado en ti.
Además, cuando hay otros involucrados, un equipo o una empresa, es posible que sea necesario considerar factores adicionales, como las preferencias del equipo, así como las políticas y la estrategia de la empresa.
Estos son solo algunos de los factores involucrados que deben tenerse en cuenta al evaluar diferentes soluciones.

Una última cosa que me gustaría abordar es su mensaje. Creo que no es lo suficientemente específico para comprender lo que espera de una respuesta. En mi interpretación, hay muchas preguntas diferentes para las que está tratando de obtener una respuesta, además de brindar sus opiniones. Todos estos son válidos y útiles, sin embargo, cuando se les pregunta y se plantean juntos en un problema de github, es difícil armar una respuesta clara y concisa o comenzar una discusión para brindarle las respuestas que busca.
Mi sugerencia para usted sería intentarlo de nuevo y ser más específico con sus preguntas u opiniones. No se preocupe por abrir muchos problemas, si están bien escritos y abarcados, serán mucho mejor recibidos y es mucho más probable que obtenga respuestas a sus preguntas o que se le dirija de manera adecuada.

Espero que esta respuesta ayude de alguna manera. Solo sepa que hay muchas personas que están dispuestas a ayudar, sin embargo, es su responsabilidad facilitar que alguien lo ayude.

@ LJ9999 un comentario (con suerte constructivo)...

Según el SQL que publicó, es posible que esté utilizando Entity Framework 6. Entity Framework Core (una versión más nueva escrita desde cero) tiene el objetivo explícito de generar un SQL sano y legible que intente parecerse a lo que escribiría usted mismo: hay una gran posibilidad de que si lo intenta, verá algo más razonable: pruébelo y háganoslo saber.

Mi criterio final es simple... Número de líneas de código para implementar. Más código: más riesgo de errores, mayor curva de aprendizaje, más horas desperdiciadas (a menos que sea un contratista que factura por hora).
He visto un volumen de código 8 veces mayor al hacer mvc con el marco Javascript. Sobre páginas cshtml de la vieja escuela. Y 5 veces más tiempo.

Tenga cuidado con los que usan la frase "camino correcto"

MVC como arquitectura de software es más útil para usted en este caso.
M es el modelo, que podría ser su base de datos, puede responder a solicitudes de información, responder a instrucciones para cambiar el estado de su información e incluso notificar a los observadores en sistemas controlados por eventos cuando cambia la información.
V es la vista, que efectivamente proporciona el elemento de interfaz de usuario de la aplicación. Representará los datos del modelo en un formato adecuado para la interfaz de usuario.
C es el controlador, que recibe la entrada del usuario y realiza llamadas para modelar objetos o simplemente representar la vista.

Su elección de tecnología no significa que MVC sea bueno o malo, es solo una arquitectura de software.

@shanselman

Amigos, comenten con ayuda o positivismo, pero no con burla. El OP parece tener preocupaciones con EF, y el comentario de David es excelente. #7039 (comentario)

Estoy completamente de acuerdo Scott.

También es comprensible que algunos usuarios más experimentados se sientan fuertemente acerca de un título que parece robar un gran marco y años de arduo trabajo por parte del equipo central de ASP.NET y la comunidad como 'no utilizable' en una sola declaración a pesar de que eso fue probablemente no sea la intención. Creo que eso probablemente causó el ridículo.

Puede ser útil cambiar el título para que coincida con el problema real.

Periódicamente cerramos problemas de 'discusión' que no se han actualizado en un largo período de tiempo.

Pedimos disculpas si esto causa algún inconveniente. Le pedimos que si todavía tiene un problema, registre un nuevo problema con información actualizada y lo investigaremos.