¿Debo mantener los Business Objects separados de la interfaz de usuario en WPF?

Question

La forma de hacer las cosas orientada al modelo de vista de WPF hace que sea muy tentador usar solo objetos de negocios en la interfaz de usuario. ¿Has visto algún problema con esto? ¿Por qué o por qué no harías esto?

Answer 1

La guía de los equipos de productos de Microsoft (por ejemplo, eso es lo que está usando el equipo de Blend) es la arquitectura Model-View-ViewModel, una variante del popular patrón MVC. Un buen punto de partida es http://blogs.msdn.com /johngossman/archive/2005/10/08/478683.aspx . También hay buenos artículos del Dr. WPF sobre este tema.

Esencialmente, abogan por crear una capa ViewModel que utilice objetos de negocios amigables con los enlaces, como ObservableCollection y similares.

Además, si eventualmente se muda a Silverlight 2, es posible que desee mantener los objetos comerciales fuera de la capa de IU para que pueda intercambiar la tecnología de IU (hasta que WPF y Silverlight sean compatibles con el código fuente).

Answer 2

Creo que lo veo con una luz diferente. Intento mantener todo lo posible fuera de la IU para poder usar la presentación de IU que necesito (es decir, web, WPF, WinForms). Mientras más lógica de negocios haya en la capa de presentación, más tendrá que reescribir más adelante si migra hacia una IU diferente.

Answer 3

No es un problema tener objetos de negocios en la interfaz de usuario, siempre que todo lo que esté haciendo sea verlos . En otras palabras, si desea cambiar las propiedades de uno, o eliminar uno, o crear uno nuevo, debe enviar un mensaje al controlador, presentador o lo que sea que haga; y los resultados deberían actualizarse en la vista.

Lo que no debe hacer es usar el método ToString de sus objetos (o cualquier otro método o propiedades en sus objetos) para afectar cómo aparecerán en la vista. Debe usar DataTemplate s para representar la vista de sus objetos. Si necesita una representación más compleja, puede usar un IValueConverter para cambiar el objeto a su representación visual.

Answer 4

No soy un gurú de WPF, no puedo estar seguro, pero la razón habitual para separar tu M, V y C es para que puedas probar el controlador independientemente de la vista, y viceversa.

Nada lo detiene, por supuesto, pero debería ser mucho más comprobable (es decir, pruebas unitarias) si está separado. El patrón MVP, que generalmente es el que promueve MS, está más orientado a que el presentador (es decir, su formulario WPF) tenga más control, y eso también está bien ...

Answer 5

Dependiendo de la arquitectura de su aplicación o de la forma en que planea reutilizar sus componentes y objetos, puede elegir un cierto grado de independencia de la interfaz de usuario (en este caso, WPF).

Aquí hay una muestra de mi experiencia:

  

He trabajado un poco con WPF, en   un proyecto relativamente pequeño, donde el   la capa empresarial ya estaba definida,   y solo necesitábamos crear un usuario   interfaz. Por supuesto, la interfaz   había definido sus propias reglas y objetos   con el que estaba trabajando y porque   la aplicación se definió solo para   UX hemos elegido crear nuestro propio   objetos específicos, principalmente extendiendo    DependencyObject (principalmente para datos   Fines vinculantes ).

     

Algunas personas pueden argumentar que no está bien   usar objetos de dependencia porque   no son serializables (en realidad   son - a XAML), traen un   dependencia a WPF (la    System.Windows (espacio de nombres), y algunos   otros argumentos También,    DependencyObjects admite otros   opciones, como propiedades adjuntas   y propiedades de dependencia . Otros   podría usar, por ejemplo    INotifyPropertyChanged si es   tiene sentido, y otros podrían decir que   todos estos patrones no pertenecen a   otra capa que la interfaz de usuario.   (Si quieres aprender más hay   algunos buenos WPF enlace de datos   artículos en la biblioteca de MSDN,   incluidas las mejores prácticas para   rendimiento y para la interfaz de usuario)

Es algo malo que Microsoft haya elegido agregar algunas de las ventajas al espacio de nombres System.Windows , en lugar de, por ejemplo, al System.ComponentModel donde en mi opinión, podrían haber sido más útiles (al proporcionar todos estos patrones importantes no solo a WPF sino también a .NET Framework).

Por supuesto, esto es solo el comienzo y muchos de nosotros sabemos que la cosa evolucionará en la dirección correcta al final. (Con el riesgo de salirse del tema: tome el marco silverlight 2.0, por ejemplo. Fue una versión apresurada, con algunos de los objetos del modelo WPF que faltan y otros no en su lugar natural).

  

Al final, todo depende de usted, su estilo de programación, sus decisiones arquitectónicas y su conocimiento de la tecnología.

     

¡Si parece más natural hacerlo de una manera que en el libro, piense por qué debería y por qué no debería antes de tomar cualquier decisión!