¿Debo mantener los Business Objects separados de la interfaz de usuario en WPF?
Pregunta
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?
Solución
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).
Otros consejos
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.
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.
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 ...
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 datosFines 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 ejemploINotifyPropertyChanged
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
ypor qué no debería
antes de tomar cualquier decisión!