¿Cómo elegir NO usar un marco (Caliburn.Micro, etc.) en una aplicación MVVM dada?

28

Una vez comencé un proyecto MVVM / WPF, que finalmente se construyó e implementó, y para eso estudié mucho el Marco Caliburn.Micro MVVM. El hecho es: terminé no usando Caliburn.Micro para eso, y terminé implementando algunos conceptos MVVM (específicamente, solo las clases ViewModelBasey RoutedCommand).

Ahora me asignaron a un proyecto algo más grande en la misma línea: una "Aplicación de escritorio fuera de línea de cliente enriquecido para un solo usuario", por así decirlo, y decidí usar Caliburn.Micro. Y ahí es donde comienza mi "problema".

He leído en esta famosa publicación de blog , cuyo título dice que "si estás usando MVVM, entonces necesitas un marco", que:

"Tratar de hacer algo como MVVM sin un marco es una gran cantidad de trabajo. Toneladas de código duplicado, reinventar la rueda y volver a capacitar a las personas para que piensen de manera diferente" .

Al menos con un marco de trabajo, evita el código duplicado y, con suerte, no tendrá que reinventar la rueda, lo que le permite concentrarse en volver a capacitar a las personas. La parte de reentrenamiento es generalmente inevitable, pero un marco proporciona código y estructura de plomería, lo que facilita el proceso. "

Estaría de acuerdo con la primera lectura, pero mi experiencia real con Caliburn.Micro (CM) en mi aplicación actual es de falta de idea y desorientación. Es decir, el marco no facilitó el proceso en absoluto, sino todo lo contrario. Leyendo los ejemplos siempre repetidos proporcionados por Rob Eisenberg en la documentación informal (demasiado), e intentando inferir patrones de uso a partir de las muestras proporcionadas enrevesadas, y sus relaciones de clase e interfaz completamente indirectas, donde las cosas parecen estar diseñadas para funcionar en función de efectos secundarios, parece humanamente imposible a menos que seas un genio experimentado (perdón por la queja, pero supongo que sabes a lo que me refiero).

Sin mencionar que cualquier escenario anterior trivial parece involucrar contenedores IoC, que es algo con lo que nunca he trabajado, y que parecen resolver un problema que ni siquiera podría tener . No tengo ganas de pasar más horas del proyecto aprendiendo esas cosas en lugar de pensar en mis problemas y dominios de aplicación. Solo quería un plátano, pero CM me dio un gorila (IoC) sosteniendo una canasta de plátanos.

Ahora que estoy considerando volver a mi marco MVVM casero, compuesto solo por el puñado de clases específicas de MVVM que realmente quiero implementar, me gustaría al menos darle una oportunidad a CM, en caso de que esté perdiendo algo aquí, o simplemente haciendo las cosas "al revés" por pura inexperiencia e ignorancia. Y entonces la pregunta es:

Existe un consenso generalizado de que "los marcos hacen las cosas más fáciles y más naturales", pero si estoy experimentando todo lo contrario, ¿significa esto que no debería usar el marco o que estoy tratando de aprenderlo de manera incorrecta? ¿Hay alguna pista de que ni siquiera debería estar usando un marco en primer lugar? ¿O hay alguna forma "correcta" de descubrir cómo usar CM para el desarrollo simple de MVVM?

frameworks wpf mvvm

— heltonbiker
fuente

1

Personalmente, elijo y elijo elementos de cada marco para usar para comportamientos específicos, e ignoro el resto. Por ejemplo, me gusta usar Microsoft PRISM EventAggregatorpara mensajes, y NotificationObjectpara ViewModelBase, y MVVM Light RelayCommandpara comandos. Lo importante es identificar qué problemas resolverá el marco para usted y solo usar esas soluciones. No sienta que está obligado a usar toda la biblioteca de framework.

— Rachel

@Rachel Estaba planeando usar este enfoque con Caliburn.Micro, pero no pude encontrar una RelayCommandimplementación (ya que "se une" directamente a los métodos por convención, en lugar de vincularse a las propiedades de ICommand).

— heltonbiker

Nunca he usado el marco Caliburn porque no me gustó cuán estrechamente parecía vincular las Vistas con la capa Modelo / Modelo de vista. En su caso, no veo ninguna razón por la que no pueda utilizar una RelayCommandde otra biblioteca si la utilizada por Caliburn Micro no funciona para usted.

— Rachel

@Rachel con respecto a "qué tan cerca [caliburn] vincula la vista a la capa MVM", ¿qué quiere decir exactamente? ¿Cuál sería la forma "no calibrante" de unir esas capas de una manera mejor y más MVVM? (Pido sinceramente porque no lo sé actualmente).

— heltonbiker

Sinceramente, nunca he usado Caliburn Micro, así que siento que soy un mal juez del marco. Recuerdo haber tenido la impresión de que la Vista se creó primero y fue responsable de decidir los objetos de código subyacente, que es un aspecto que no me gustó ya que no me gusta el desarrollo de View-First. Otro fueron los enlaces automáticos que se basaban en cómo nombrar los componentes XAML, ya que pensé que vinculaba demasiado la interfaz de usuario a la capa empresarial. Sin embargo, he escuchado cosas buenas sobre el marco y no sugeriría evitarlo solo en mi opinión. Pruébelo usted mismo y vea si le gusta :)

— Rachel

16

He intentado CaliburnMicro y MVVMLight y cuando uso Caliburn realmente siento lo que sientes, seguro que se siente realmente mágico poder vincular el control a la propiedad simplemente usando Name = "PropertyName" en lugar del antiguo Text = "{Bind PropertyName}" pero en el fin Caliburn se va por la borda para hacer esta cosa mágica, cuando algo sale mal es realmente difícil de depurar, para empeorar las cosas, tienen muchas maneras de hacer una cosa.

Pero cuando usa MVVMLight es delgado, cuando lo usa, probablemente se dé cuenta de que es casi 100% como su MVVM Framework, con algunas características rociadas.

Sé que esto no responde a su pregunta "Cómo NO usar el marco", pero, francamente, no puedo recomendarle que siga esa ruta porque simplemente está mal, también creo que está perdido porque usa el marco con todas las funciones en lugar de usar un simple uno primero.

— kirie
fuente

¿Crees, entonces, que al menos debería intentar usar MVVMLight como una especie de "cura" de "Caliburn.Micro desorientación"? Seguramente echaría un vistazo si ese es el caso.

— heltonbiker

@heltonbiker Definitivamente, pruébalo. Es mucho más simple, al menos debería darle un buen punto de apoyo en MVVM Framework.

— kirie

Estoy de acuerdo en que hay demasiada magia. Viniendo de ac y antecedentes de montaje, supongo. E algo no funcionará solo para encontrarlo, debido a la magia en el fondo. Imposible de depurar y cuando tiene problemas de rendimiento a menudo no puede hacer mucho al respecto.

— llega el

10

Es importante darse cuenta de lo que es MVVM. No es un poco de funcionalidad compartida lo que no tiene que volver a implementar (analizar un archivo JPEG o conectarse a un servidor de base de datos SQL dado), es un patrón, un patrón de cómo uno puede elegir implementar una GUI enriquecida. Entonces, si su implementación del patrón es simple y directa, no creo que necesite sentir vergüenza al usarlo en lugar de un marco.

De hecho, creo que toda la idea de patrones como marcos ha ido demasiado lejos. Para que cualquier cosa sea un patrón, tiene que ser la forma general de una clase de soluciones. Como esto es así, es de esperar que los patrones deban adaptarse a los sistemas que los usan y no puede hacerlo si intenta usar un patrón de talla única. Sería mucho más constructivo dejar la implementación del patrón al diseñador de la aplicación y proporcionar bibliotecas que encapsulan la funcionalidad, en lugar de la arquitectura.

— Miguel
fuente

2

Además de eso, MVVM como lo ofrece Microsoft (listo para usar, WPF) carece mucho. Muy frustrante incluso para programadores que piensan en sí mismos (y con razón) como desarrolladores experimentados. Las cadenas mágicas, las oscuras excepciones en tiempo de ejecución, las cosas más básicas, como vincular un grupo de botones de radio a una enumeración, se parecen a stackoverflow.com/q/397556/168719 : ¿qué pueden hacer los marcos? Tienen que hacer eco de este nivel de complejidad, o tratar de proporcionar una abstracción realmente gruesa sobre él

— Konrad Morawski

2

@KonradMorawski WPF por sí solo no es MVVM; puedes hacer código detrás con WPF, pero eso no es MVVM. Entonces, si desea hacer WPF y MVVM, deberá usar un marco MVVM o implementar uno usted mismo.

— Andy

1

@Andy, por supuesto, pero es seguro decir que WPF está destinado a MMVM. Me refiero a la funcionalidad MVVM que viene integrada con WPF. Sé que todavía puedes hacer código detrás

— Konrad Morawski

@KonradMorawski Puede usar WPF con MVVM, y lo crearon teniendo en cuenta esa posibilidad, pero NO hay una funcionalidad específica de MVVM integrada en WPF. Al igual que puede usar MVP con WinForms, pero WinForms no ofrece nada específicamente para usar ese patrón, depende de usted.

— Andy

3

@ Andy, tal vez estamos discutiendo sobre las definiciones ahora. Lo que quiero decir es que todo el "pegamento" que hace posible MVVM ya está allí - enlaces de datos en XAML, DataContextetc.

— Konrad Morawski

7

Mi primera experiencia con WPF ha sido usar Caliburn.Micro, por lo que probablemente sea bastante diferente de la mayoría de los desarrolladores. He encontrado que tanto WPF como Caliburn.Micro son una curva de aprendizaje bastante empinada, proveniente de WinForms, sin embargo, después de un poco de experiencia con ambos, me ha parecido un placer usarlos como pareja. Actualmente trabajando en una organización diferente donde no se usa Caliburn.Micro, encuentro que hay MUCHO código de plomería duplicado que hace que la base de código esté bastante hinchada e innecesariamente compleja.

Definitivamente estoy de acuerdo en que hay algunos problemas con Caliburn.Micro, que pueden complicar la depuración, sin embargo, una vez experimentados, es mucho menos probable que vuelvan a ser un dolor. La mayor velocidad de desarrollo, el código más limpio y ágil y el marco general que fomenta un mejor MVVM merecen la pena.

Caliburn.Micro tampoco invalida el stock WPF, solo se acumula sobre él, lo que significa que aún puede usar las funciones de WPF si lo desea y usar Caliburn para algunos bits si lo desea. Esto es similar a cómo TypeScript y JavaScript coexisten en mi mente.

Definitivamente usaría Caliburn.Micro en cualquier nuevo proyecto de WPF en el que trabaje en el futuro si tuviera la oportunidad.

— Ross
fuente

3

Gracias por tu respuesta. Dos años después, me resultó mucho más fácil "aceptar" estos marcos después de comprender el concepto de Contenedores de inyección de dependencia, que aprendí del excelente libro "DI en .NET" de Mark Seeman.

— heltonbiker

1

Para cualquiera que llegue aquí por frustración con Caliburn.Micro, eche un vistazo a este marco: Stylet

Está inspirado en Caliburn.Micro, excepto que elimina mucha de la magia que te deja desorientado sobre lo que está sucediendo. Además, la documentación está escrita en un lenguaje mucho más claro sin suponer que desea pasar por la jerga técnica. Mucho mejor para principiantes.

Además, Stylet adopta un enfoque ViewModel-First. Caliburn.Micro y muchos otros frameworks adoptan un enfoque View-First, que viene con algunos problemas incómodos. Si ya es muy bueno con los principios SÓLIDOS y el código modelado, es probable que encuentre un enfoque ViewModel-First más natural, ya que toma la perspectiva de que su lógica debe conducir el sistema, no la vista.

— JamesHoux
fuente