Una vez comencé un proyecto MVVM / WPF, que finalmente se construyó e implementó, y para eso estudié mucho Caliburn.Micro MVVM Framework. El hecho es que terminé no usando Caliburn.Micro para eso, y terminé implementando algunos conceptos MVVM yo mismo (específicamente, solo ViewModelBase y RoutedCommand clases).
Ahora me asignaron a un proyecto algo más grande en la misma línea: un » Single-User Rich Client Offline Desktop Application «, por así decirlo, y decidí utilizar 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 necesita un marco «, que:
» Intentar hacer algo como MVVM sin un marco es una gran cantidad de trabajo. Toneladas de código duplicado, reinvención de la rueda y reentrenamiento de la gente para pensar de manera diferente .
Al menos con En un marco, evita el código duplicado y, con suerte, no tiene 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 en la primera lectura, pero mi experiencia real con Caliburn.Micro (CM) en mi aplicación real está siendo de desorientación y desorientación. Es decir, el marco no facilitó el proceso en absoluto, todo lo contrario. Leyendo los ejemplos siempre repetidos proporcionados por Rob Eisenberg en la documentación bastante (demasiado) informal, y tratando de inferir patrones de uso de las complicadas muestras proporcionadas, y sus relaciones de clase e interfaz totalmente indirectas, donde las cosas parecen estar diseñadas para funcionar basadas en efectos secundarios, parecen humanamente imposibles a menos que seas un genio experimentado (perdón por la perorata, pero supongo que sabes lo que quiero decir).
Sin mencionar que cualquier escenario trivial anterior parece involucrar contenedores de IoC, que es algo con lo que nunca he trabajado, y que parecen resolver un problema que quizás ni siquiera tenga . No tengo ganas de pasar más horas de proyecto aprendiendo esas cosas en lugar de pensar en mi problema y los 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 regresar a mi marco MVVM casero, compuesto solo por un puñado de MVVM- clases específicas que realmente quiero implementar – Me gustaría al menos darle una oportunidad a CM, en caso de que esté perdiendo algo aquí, o simplemente estoy haciendo las cosas » de la manera incorrecta » por pura inexperiencia e ignorancia. Entonces la pregunta es:
Existe un consenso generalizado de que los marcos » hacen las cosas más fáciles y naturales «, pero si estoy experimentando todo lo contrario, ¿significa esto que no debería usar el marco o que estoy tratando de aprenderlo de la manera incorrecta? ¿Una 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?
Comentarios
Responder
He probado CaliburnMicro y MVVMLight y cuando uso Caliburn realmente siento lo que sientes, seguro que se siente realmente mágico poder vincular un control a una propiedad con solo usar Name = » PropertyName » en lugar del antiguo Text = » {Bind PropertyName} » pero al final Caliburn se va por la borda para hacer esta cosa mágica . Cuando algo sale mal, es muy difícil de depurar y para empeorar las cosas, tienen muchas formas de hacer una cosa.
Por el contrario, MVVMLight es realmente delgado. Cuando lo use, probablemente se dé cuenta de que es casi 100% como su MVVM Framework, con algunas características en él.
Sé que esto no responde a su pregunta » Cómo NO usar framework » pero, francamente, no puedo recomendar que sigas ese camino. Creo que estás perdido porque usaste un marco con todas las funciones en lugar de usar uno simple primero.
Comentarios
- ¿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 Definitivamente, pruébalo. Es mucho más simple que al menos debería darle un buen punto de apoyo en MVVM Framework.
- Estoy de acuerdo en que hay demasiada magia. Viniendo de un fondo de ensamblaje y cy supongo. E algo no ‘ no funcionará sólo para descubrir que sí funciona debido a la magia de fondo. Imposible de depurar y cuando tiene problemas de rendimiento, a menudo no puede hacer mucho al respecto.
Respuesta
Es importante darse cuenta de qué es MVVM. No es una funcionalidad compartida que no tenga que volver a implementar (analizar un archivo JPEG o conectarse a un servidor de base de datos SQL determinado), es un patrón , un patrón de cómo se puede elegir para implementar una GUI rica. Entonces, si su implementación del patrón es simple y directa, no creo que deba sentir vergüenza por usarlo en lugar de un marco.
De hecho, creo que toda la idea de patrones como marcos tiene ido demasiado lejos. Para que algo sea un patrón, tiene que ser la forma general de una clase de soluciones. Debido a que 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 único para todos. 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.
Comentarios
- Agregado a eso, MVVM ofrecido por Microsoft (fuera de la caja, WPF) carece mucho. Muy frustrante incluso para los programadores que se consideran a sí mismos (y con razón) como desarrolladores experimentados. Cadenas mágicas, oscuras excepciones en tiempo de ejecución, la mayoría de las cosas básicas, como vincular un grupo de botones de radio a una enumeración, se parece a stackoverflow.com/q/397556/168719 – ¿qué pueden hacer los frameworks? Tienen que hacerse eco de este nivel de complejidad o tratar de proporcionar una abstracción muy densa sobre él
- @KonradMorawski WPF por sí solo no es MVVM; puede hacer código detrás con WPF, pero eso ‘ no es MVVM. Entonces, si desea hacer WPF y MVVM, ‘ necesitará usar un marco MVVM o implementar uno usted mismo.
- @Andy, por supuesto, pero ‘ Es seguro decir que WPF está destinado a MMVM.’ me refiero a la funcionalidad MVVM que viene incorporada con WPF. Sé que todavía puedes hacer código detrás
- @KonradMorawski Puedes usar WPF con MVVM, y lo construyeron con esa posibilidad en mente, 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 tal vez ‘ estemos discutiendo definiciones ahora. Lo que quiero decir es que todo el » pegamento » que hace posible MVVM ya está allí: enlaces de datos en XAML,
DataContextetc.
Respuesta
Mi primera experiencia con WPF fue con 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, he encontrado que es un placer usarlos en 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 del código sea bastante inflada e innecesariamente compleja.
Definitivamente estoy de acuerdo en que hay algunos errores con Caliburn.Micro, que puede complicar la depuración, sin embargo, una vez experimentados, es mucho menos probable que vuelvan a ser un problema. La mayor velocidad de desarrollo, el código más limpio y más ágil y el marco general que fomenta una mejor MVVM valen la pena para mí.
Caliburn.Micro tampoco invalida el archivo WPF, simplemente se construye sobre él, lo que significa que aún puede usar las funciones de WPF si lo desea y usar Caliburn para algunas partes si lo desea. Esto es similar a cómo TypeScript y JavaScript coexisten juntos 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.
Comentarios
- 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í de la excelente libro de Mark Seeman ‘ s » DI en .NET «.
Respuesta
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 gran parte 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 sencillo sin suponer que desea vadear la jerga técnica. Mucho mejor para principiantes.
Además, Stylet adopta un enfoque de ViewModel-First. Caliburn.Micro y muchos otros marcos adoptan un enfoque View-First, que viene con algunos problemas incómodos. Si ya eres muy bueno con los principios SOLID y el código con patrones, es probable que encuentres un enfoque de ViewModel-First más natural, ya que toma la perspectiva de que tu lógica debe impulsar el sistema, no la vista.
EventAggregatorpara la mensajería yNotificationObjectpara un ViewModelBase y MVVM Light ‘ sRelayCommandpara los comandos. Lo importante es identificar qué problemas va a resolver el marco por usted y solo usar esas soluciones. No ‘ no sienta que ‘ se ve obligado a utilizar toda la biblioteca del marco.RelayCommandimplementación (ya que » enlaza » directamente a los métodos por convención, en lugar de enlazar a las propiedades de ICommand).RelayCommandde otra biblioteca si la utilizada por Caliburn Micro no funciona para usted.