¿Por qué tener un código de usuario / manuscrito mínimo y hacer todo en XAML?

Siento que la comunidad MVVM se ha vuelto demasiado entusiasta como los programadores de OO en los años 90: es un nombre inapropiado MVVM es sinónimo de código. De mi pregunta cerrada de StackOverflow :

Muchas veces me encuentro con publicaciones aquí sobre alguien tratando de hacer el equivalente en XAML en lugar de código detrás. Su única razón es que quieren mantener su código "limpio". Corrígeme si estoy equivocado, pero no es el caso que:

XAML también se compila, en BAML, luego, en tiempo de ejecución, debe analizarse en código de todos modos. XAML puede tener potencialmente más errores de tiempo de ejecución ya que el compilador no los detectará en el momento de la compilación, debido a la ortografía incorrecta, estos errores también son más difíciles de depurar. Ya hay código detrás, nos guste o no InitializeComponent (); tiene que ejecutarse y el archivo .gics en el que está contiene un montón de código, aunque puede estar oculto. ¿Es puramente psicológico? Sospecho que son los desarrolladores que provienen de un fondo web y les gusta el marcado en lugar del código.

EDITAR: No propongo código detrás en lugar de XAML - use ambos - Prefiero hacer mi enlace en XAML también - Estoy en contra de hacer todo lo posible para evitar escribir código detrás de esp en una aplicación WPF - debería ser una fusión de ambos para sacarle el máximo provecho.

ACTUALIZACIÓN: Ni siquiera es idea de Microsoft, cada ejemplo en MSDN muestra cómo puede hacerlo en ambos.

Nunca he oído de nadie que sugiera poner todo en XAML.

De hecho, esa sería una idea terrible, OMI.

El problema, históricamente, vino de las aplicaciones de Winforms que tenían lógica en su código detrás que no pertenecía allí, porque era lógica . De ahí viene la importancia de VM. Le permite aislar las partes que unen la Vista al Modelo.

Por lo tanto, la Vista se deja solo para manejar lo que mejor hace, que es la IU.

Ahora, si tiene situaciones en las que su interfaz de usuario requiere código, entonces hágalo y colóquelo en su código. Sin embargo, diría que para el 95% de los escenarios, lo más probable es que sea mejor dejar la interfaz de usuario en el archivo de marcado, y si necesita algo de código, es probable que esté intentando escribir algo. eso se deja más apropiadamente al Modelo de vista. Las excepciones a esto son cosas como los comportamientos, pero son animales completamente separados y requieren un lugar especial (es decir, no en su código detrás).

Para responder directamente a su pregunta, y suponiendo que cuando dice "código" que en cada caso se refiere específicamente al código subyacente (código que está en una clase de control visual), la razón es para que su interfaz de usuario pueda implementarse por completo y manipulado en Blend, usando solo una tecnología. La suposición es que sus diseñadores de UX no son desarrolladores y no quieren trabajar en código, y que son expertos en diseño y XAML en lugar de expertos en codificación. Si implementa todo sin código subyacente, puede dar a ese tipo de diseñadores las herramientas que necesitan para trabajar completamente en su idioma.

Proporciona una separación limpia entre la programación imperativa y el diseño declarativo.

Es la razón principal de la existencia de "comportamientos" en Silverlight y WPF: en lugar de introducir algo de código en el código subyacente, convierta el comportamiento en su propio módulo reutilizable. Si lo hace, Blend le brinda el beneficio de literalmente poder arrastrarlo y soltarlo en un control. Ahora, en lugar de tener una parte móvil única en un control XAML todo lo demás, ha abstraído las partes móviles en un contenedor agradable que puede manipularse utilizando herramientas de diseño.

En mi experiencia, esto a menudo se reduce a tratar de usar una lógica complicada en los desencadenantes XAML para mantenerlo fuera del código subyacente, cuando el enfoque mejor y más simple sería poner esa lógica en ninguno de los dos: pertenece a la vista -modelo.

Una de las mayores ventajas de hacer todo lo posible en xaml es que mantiene todo el comportamiento en un solo lugar. Cada vez que el desarrollador tiene que saltar entre el xaml y el código, se hace más difícil entenderlo.

He estado en un equipo de WPF que no hizo de la reducción del código subyacente una prioridad. Hubo más de unas pocas veces que la depuración fue mucho más difícil porque algún controlador de eventos estaba manipulando el control y no fue inmediatamente aparente porque el comportamiento se dispersó en dos archivos.

Dicho esto, creo que tiene razón al pensar que a veces es mejor comprometer el principio de diseño. Algunas cosas son muy difíciles de hacer en xaml. He pasado horas o incluso días tratando de lograr que un comportamiento funcione en xaml que podría haber hecho en mucho menos tiempo usando el código subyacente. He venido a tratar el código subyacente como último recurso, pero nunca le diría a alguien que nunca deberían usarlo. Es solo otra compensación que un buen ingeniero necesita entender.

editar: Según los comentarios, parece que mi publicación se interpreta como un argumento en contra de xaml. Mi intención era argumentar lo contrario. El xaml puro siempre es preferible porque mantiene todo el comportamiento en un solo lugar. Una combinación de xaml y código subyacente puede ser complicada, por lo que minimizar el código subyacente es ideal. Xaml es preferible al código subyacente puro por muchas razones. WPF y Silverlight están diseñados para escribirse en xaml.

Solo tengo un conocimiento muy superficial de XAML, pero me desconcierta que el compilador no detecte errores tipográficos.

La diferencia básica es que XAML es declarativo , mientras que C #, por ejemplo, es imperativo.

Simplemente pon:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

vs.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

El código superior realmente crea una jerarquía por efectos secundarios, mientras que el inferior simplemente lo declara. También vale la pena señalar que, si bien, por ejemplo addChild, se puede cambiar el nombre del método, la relación hijo-padre está en el centro del modelo semántico y se representa como tal en el fragmento declarativo. Está muy lejos de la implementación, lo que permite mucha optimización debajo, como la instanciación perezosa, de manera completamente transparente.
La programación declarativa tiene una serie de ventajas. Es más conciso, expresivo y muy cercano a su modelo. Yo iría tan lejos como eso es preferible.

Sin embargo, esto no significa que debas intentar insertar todo en XAML. C # tiene muchas construcciones de alto nivel que permiten un estilo declarativo.

Al final, desea que su código sea corto y fácil de leer. Entonces, si puede lograr lo mismo en C # con menos código que en XAML, usar C # es lógico. Tenga en cuenta que, sin embargo, el código XAML es más "portátil" en el sentido de que es mucho menos vulnerable a los cambios en los componentes utilizados, abstrayendo el marco .NET (por ejemplo, los detalles de cómo se implementan los enlaces).