framework - MVVM, Unity, Prism, MEF, Caliburn-¿Qué debo usar?

prism mvvm

Question

Por favor ayuda, me estoy perdiendo!

Estoy escribiendo una pequeña aplicación de escritorio que tiene algunos controles y algo de pantalla. Esto debería integrarse más adelante con un pequeño sitio web, también con algunas pantallas. La idea es permitir al usuario editar videos y seleccionar imágenes, y luego compartir sus resultados con sus amigos.

La aplicación de escritorio está utilizando C # WPF, el sitio web - ASP.Net MVC.

Leí que hacer crecer la aplicación más allá de algunas pantallas sería más fácil usando MVVM. Así que empecé a buscar y descubrí Caliburn.Micro y MVVM.Light. He descargado algunos tutoriales pero, justo cuando me estaba preparando para profundizar en el material, lo encontré aquí en SO . que también hay Prisma, MEF, Unidad, ReactiveUI - ¡Esto se está volviendo demasiado!

Soy terrible para aprender cosas nuevas. Me está llevando años estudiar WPF y ASP.Net MVC. No quiero estudiar mucho material nuevo solo para descubrir más tarde que no es relevante. Y no tengo un arquitecto que me instruya.

Entonces, mi pregunta es: ¿podría poner estos marcos y tecnologías en perspectiva, y sugerir cuál debería centrarme en estudiar y usar (especialmente, qué se puede usar más adelante con Windows 8)?

Answer 1

Esta respuesta reproduce algunos fragmentos abreviados del artículo del blog de Rockford Lhotka " Usar el patrón MVVM requiere un marco ", que fue citado en otra respuesta .

Es una especie de meta-respuesta a esta pregunta (aunque contiene una recomendación específica), pero, en primer lugar, me pareció muy útil para explicar el rol de un marco en MVVM.

Hay tres patrones de diseño de capas de presentación bastante populares que en conjunto llamo los patrones "M": MVC, MVP y MVVM. Esto se debe a que todos tienen una "M" que significa "Modelo", además de algunas otras construcciones.

La cosa con todos estos patrones "M" es que para los desarrolladores típicos los patrones son inútiles sin un marco . Usar los patrones sin un marco casi siempre conduce a confusión, complicaciones, altos costos, frustración y, en última instancia, desesperación.

Estos son solo patrones después de todo, no implementaciones. Y son patrones grandes y complejos que incluyen bastantes conceptos que deben funcionar juntos correctamente para permitir el éxito.

...

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

Al menos con un marco, evitas el código duplicado y, con suerte, no tienes que reinventar la rueda, lo que te permite concentrarte 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.

Podría preguntarse por qué el patrón MVC solo se hizo popular en ASP.NET hace unos pocos años ...

Curiosamente, MVC solo comenzó a convertirse en la corriente principal en el mundo de Microsoft cuando apareció ASP.NET MVC. Este es un marco completo con herramientas integradas en Visual Studio. Como resultado. Los desarrolladores típicos pueden simplemente construir modelos, vistas y controladores. Antes de ese punto, también tenían que construir todo lo que hace el framework MVC, que es una gran cantidad de código. Y no solo un montón de código, sino un código que no tiene absolutamente nada que ver con el valor comercial , y solo se relaciona con la implementación del patrón en sí.

...

Los desarrolladores típicos realmente quieren centrarse en construir modelos, vistas y modelos de vista. No quieren tener que crear enrutadores de eventos basados ​​en referencias débiles, modelos de navegación, abstracciones de vista y todas las otras cosas que debe hacer un marco.

...

Mientras tanto, Caliburn Micro parece ser el mejor marco MVVM que existe, ciertamente el más utilizado [a partir de 2012] ...

(Texto copiado en línea por razones de conservación).

Answer 2

PRISM ya incluye lógica MEF y MVVM :)

Ok un poco de explicación aquí:

MVVM significa lógica en su aplicación. Una manera realmente inteligente de desacoplar la vista, el modelo de vista y el modelo. No conozco el mejor marco (?) Para hacerlo: puede marcar Catel si lo desea o MVVM Light, pero es solo un montón de código de alguien que comprende la lógica MVVM y simplemente facilita su implementación. En realidad, podría intentar escribir su propio marco MVVM y ver que "no hay ningún ingrediente secreto", solo el mismo código repetitivo y las mismas clases, etc. En realidad , no necesita ningún marco MVVM para implementar MVVM.

Una vez que aprendes y escribes MVVM, inmediatamente te encuentras con una pregunta: ¿Cómo puedo no probarlo en modo de desacoplamiento (esto no es un problema trivial en Silverlight, por ejemplo)? Así que aquí entra en juego todo el marco IOC / Inject. Por ejemplo MEF. Considere el siguiente ejemplo para comprender un panorama general de Inject framework:

Proyecto ''Compartido'', escrito en ''mínimo delimitador'' (por ejemplo, Biblioteca portátil)

    public interface IAmSharedInterface
    {
        string SayHello();
    }

Proyecto ''Main'', referencia solo proyecto ''Shared''

    public class IAmMainClass
    {
        [ImportingConstructor]
        public IAmMainClass(IAmSharedInterface SharedInterface)
        {
             SharedInterface.SayHello();
         }
    }

Proyecto ''Implementador'', referencia solo proyecto ''Compartido''

   [Export(IAmSharedInterface)]
   public class IAmImplementor: IAmSharedInterface
   {
       public string SayHello()
       {
          return "Hello from implementator class to whoever using it";
       }
    }

Verá, no hay una referencia directa entre los proyectos ''Principal'' e ''Implementador''; todo ''magia'' ocurre en el proceso de compilación / resolución de MEF / Unity. Por lo tanto, podría ejecutar fácilmente la prueba NUnit en Main sin utilizar el proyecto ''Implementor'' y ''Implementor'' con ''Main''. También hay un escenario donde otro proyecto podría implementar y exportar ''IAmSharedInterface'' especialmente para propósitos de prueba.

Así que de vuelta a PRISM - tiene todo (!) Esto. Sé que no es fácil entender el marco y no es adecuado para programas simples "Hello World", pero una vez que lo aprendes, no hay vuelta atrás. Simplemente pegue todas las partes y le dará un gran grado de libertad en el uso del marco moq que desee (por ejemplo, Rhino ).

Prism se está desarrollando en Microsoft, así que espero que sea compatible no solo en Windows 8 sino en Windows 9 y en todas las versiones futuras.

Lo que sea que pregunte, todo está dentro: MVVM, inyectar, desacoplar / plug-ins, fácil de leer y probar

Answer 3

Para guardar la adición a la información detallada anterior, intentaré hacerte la vida más fácil.

1) Por ahora, olvídese de la arquitectura IOC / Inyección de dependencias / Plugin. Usted dice que está creando una aplicación simple, así que olvídese de esto por ahora. Mantenga su código ordenado y podrá implementarlo más tarde si es necesario (es bueno).

2) Fuera de los marcos que has enumerado, sugeriría Caliburn.Micro. Es relativamente sencillo y ligero. No tardarías mucho en ponerte en marcha.

3) Cree su modelo en un ensamblaje separado que pueda usar tanto para su aplicación de Windows como para su sitio web de MVC.

Mantenlo simple y no te enredes con todas las tecnologías.

Answer 4

Si desea compilar una aplicación MVVM (lo que probablemente haga por varias ventajas), entonces desea un marco MVVM .

Recomendaría Caliburn.Micro , ya que es sencillo de implementar siguiendo los ejemplos en la página de documentación de Caliburn.Micro. También tiene una convención muy convincente sobre el mecanismo de configuración, y utiliza un sistema de Actions para invocar verbos (métodos) en sus modelos de vista desde la vista. Esto es más poderoso que cualquier otro mecanismo que haya visto.

Prism es un marco bastante pesado que incluye elementos de diseño de MVVM para ayudar a la implementación, además de estar especialmente adaptado para crear aplicaciones compuestas (aplicaciones que están compuestas de componentes desacoplados dentro de un shell de alojamiento).

MEF es útil para este tipo de aplicaciones que necesitan descubrir complementos o extensiones de la aplicación (incluso después de que la aplicación haya arrancado), y se puede usar junto con un marco MVVM como Caliburn.Micro. MEF también se puede usar para implementar la inversión de control, pero no proporciona algunas de las características principales que se encuentran en otra inversión de los contenedores de control, por lo que puede decidir usarlo solo para implementar la funcionalidad del complemento.

Unity es un contenedor de IoC y se usaría para implementar la inyección de dependencias para su infraestructura general de aplicaciones. Sin embargo, hay muchos contenedores IoC en el espacio .NET, algunos de los cuales ofrecen un rendimiento mejorado, características adicionales o una API más amigable.

No sé sobre ReactiveUI ya que no lo he usado.

Si está hablando de maximizar la reutilización del código para un movimiento a WinRT, entonces MVVM es una excelente opción .