Comments on Variable not found: 12 buenas prácticas en ASP.NET MVC

Analizando sus comentarios, veo que esto de usar e...

2009-11-30T22:17:20.625+01:00

Analizando sus comentarios, veo que esto de usar el codigo de la interfaz (al menos en la Web), es una cuestion de gustos, de hecho tienes razon amigo jose, cuando manifiestas que no hay limitantes en los desarrollos ha realizar y lo que siempre he escuchado es que es una cuestion de gustos (Opcional), solo que en tu articulo, al leerlo lo senti como algo fuera de orden mas que de gustos. Gracias por el debate aunque sencillo importante para aclarar.

Hola, Rome. :-) Como decía en mi comentario anter...

2009-11-24T16:52:49.021+01:00

Hola, Rome. :-)

Como decía en mi comentario anterior, no es cuestión de ser bueno ni malo... simplemente en ASP.NET MVC nunca me ha hecho falta hasta el momento. Sólo eso.

La propia separación impuesta por el patrón Modelo-Vista-Controlador hace innecesaria la implementación de lógica en la capa de presentación más allá de la necesaria para preparar el interfaz, y por ello el codebehind deja de tener el sentido... o al menos, el sentido que tiene en webforms. Y como comentaba, no he encontrado en ASP.NET MVC ningún caso en el que tenga que utilizar codebehind para solucionar un problema concreto.

Lo mismo ocurre, pero al revés, al programar con Webforms: siempre he utilizado codebehind, pues es la práctica habitual y, como dices, te permite separar la lógica de control de la presentación. Nunca he encontrado un motivo para tener que prescindir de él, por lo que lo lógico es seguir usándolo.

Saludos y gracias por aportar!

Saludos.. Soy nuevo en eso.. Pero me llama la aten...

2009-11-24T15:28:29.879+01:00

Saludos.. Soy nuevo en eso.. Pero me llama la atención el no uso de codeBehind.. mi preguntra.. ¿que lo hace ser tan malo? Yo lo uso comunmente para maximizar la capacidad de reusabilidad de elementos y facilidad en el entendimiento del la estructura general de la aplicación. Ademas la idea de tener componentes como css, java script, separados no es nada malo. Te da mejor comprension y manejabilidad.
Gracias por el debate..

¡Hola, Andrés! Encantado de que vengas a sembrar l...

2009-11-19T12:27:22.701+01:00

¡Hola, Andrés! Encantado de que vengas a sembrar la semilla del debate (que no de la discordia) ;-D

Obviamente, el autor del artículo que cito (Simone) y yo mismo pertenecemos a la corriente filosófica del "para qué el code-behind". Partamos de ahí. :-)

Conozco el debate al que haces referencia y que bien citas en ese post de tu magnífico blog. Pero sin radicalismos, no creo que sea diabólico, ni que haga aparecer al mal programador que todos llevamos dentro ;-), ni que el hecho de usarlo vaya a provocar que introduzca ahí código más propio del controlador... Se puede crear un sistema perfectamente ajustado al patrón utilizando el code-behind, seguro. :-)

En mi caso, la cuestión es bastante simple: nunca lo he necesitado. Suelo ser bastante práctico y a priori no me cierro en banda a ninguna de las opciones, pero sí es verdad que hasta la fecha no he encontrado ningún motivo para utilizar el code-behind.

Bueno, miento ;-). De hecho, en las primeras previews del producto el code-behind se utilizaba exclusivamente para declarar las clases genéricas, puesto que la directiva inherits de las páginas no permitía utilizar notación C# o VB para la herencia y había que utilizar la notación estándar del CLR. Después, desapareció y nunca más lo he echado en falta.

Por otra parte, la idea de mezclar en una vista html, javascript, css y C# en el mismo fichero no me parece tan terrible. Los tres primeros debes tenerlos juntos cuando desarrollas para la web obligatoriamente, por lo que el problema se reduce a la unión de "lenguajes web" + C#. Hay que tener en cuenta que el C# que vamos a encontrarnos en una vista ha de ser obligatoriamente simple, en caso contrario puede ser una señal de que estamos haciendo algo mal: iteraciones, condiciones simples, llamadas a helpers... siempre y exclusivamente destinado a generar marcado y código de presentación. Existen, además, técnicas para simplificar el marcado, como el uso de helpers o vistas parciales que nos pueden ayudar cuando estemos trabajando en escenarios más complejos sin necesidad de recurrir al code-behind, un sitio en el siguiendo las convenciones propuestas por el framework, no se espera que haya nada.

Por eso cuando encontré ese "nunca" del punto 9 en el post de Chiaretta me sentí totalmente identificado pues, en mi caso, se trataba simplemente de la constatación de un hecho.

Un saludo, y gracias por compartir otro punto de vista en este tema tan interesante, Andrés!

Perdón por sembrar la semilla de la discordia. Ven...

2009-11-18T21:15:07.925+01:00

Perdón por sembrar la semilla de la discordia. Vengo a poner entre signos de interrogación al "nunca" de la 9 ("No utilices el code-behind. Nunca").

Yo diría "medita en cada caso acerca de la necesidad del codebehind, minimizando su uso en lo posible y dentro de lo razonable".

Y antes de que se me vengan encima déjenme decirles que puedo justificar esa opinión sin ponerme colorado (y que no soy el único). Pégenle si no una mirada a El estilo, la legibilidad, los “malos” programadores y el ¿diabólico? codebehind en el Microsoft .Net MVC (perdón por el autobombo), donde condenso un poco la discusión que es -en serio- más que interesante.