Vista y VistaModelo demasiado grande

Question

Al agregar funcionalidad adicional a la vista principal que tengo en mi aplicación, me he dado cuenta de que la cantidad de código pronto se convertirá en un problema (actualmente hay alrededor de 600 líneas de código en mi modelo de vista y todavía tener mucho que agregar).

He estado buscando artículos sobre cómo dividir/diseñar su vista en componentes más pequeños, pero no he encontrado una solución satisfactoria. Una persona sugirió usar modelos de vista secundarios, pero eso presentaba otros problemas (dependencia entre los modelos de vista).

He pensado en usar controles de usuario, pero no hay nada en la Vista que use en otras Vistas, por lo que de alguna manera se frustra el propósito de los controles de usuario.

¿Cuál es el enfoque correcto en esta situación?

Gracias, Adrian

Answer 1

Si desea dividir una vista en partes componentes, entonces usted tiene que hacer la composición de vista. Si está compilando una aplicación MVVM, entonces you should really be using an MVVM framework. Algo como Caliburn.Micro hace que ver la composición sea increíblemente fácil.

No necesariamente tiene que haber dependencias entre los modelos de vista, solo deben saber lo que necesitan para producir su vista. Esto podría ser un subconjunto del objeto comercial que contiene el modelo de vista padre. Como el modelo de vista principal tendrá referencias a todos los modelos de vista secundaria, puede pasarles las partes relevantes del objeto comercial en el momento de su construcción.

Answer 2

También estoy de acuerdo Caliburn.Micro es una buena solución para dividir su aplicación en componentes más pequeños.

En Caliburn.Micro la comunicación entre viewmodels se basa en el patrón Event aggregator.

Esto hace un acoplamiento débil entre ViewModels

Answer 3

estoy de acuerdo con el uso de Caliburn Micro.

Sin embargo, para jugar al defensor del diablo, puede dividir su Archivo de ViewModel en archivos separados (el mismo nombre de clase) y usar la palabra clave partial antes de la palabra clave class. Generalmente es más ordenado y está a un paso (precursor no disruptivo) de la división en clases separadas.

Answer 4

La división no es ideal.

Parece que el kit de herramientas de Caliburn se centra en los eventos, mientras que mi aplicación se basa en gran medida en las implementaciones de ICommand.

Para mí, el primer encuentro con Caliburn.Micro ha sido insatisfactorio. La configuración parecía estar hecha a la medida para VS2010, lo cual sonaba prometedor para mí, porque tengo VS2010 pro. Pero me perdí en la configuración de Silverlight. Comparado con los kits de herramientas como Prism, carece de la facilidad de un inicio. Simplemente lleva mucho tiempo cambiar ahora. Uso mi propio paradigma MVVM, es menos abstracto que el Caliburn, integra soporte multilenguaje en todas partes, y simplemente enfrenta un problema aceptable de que algunas fuentes se vuelvan demasiado grandes debido a la naturaleza del paradigma Binding/DataContext. Para este problema, acepto que la "clase parcial" es una solución, aunque sé que hay una solución más elegante disponible.

En el calor de mi trabajo, no puedo cambiar a otra caja de herramientas.

Espero gentilmente que Microsoft permita una mayor flexibilidad en torno a ese paradigma Binding/DataContext.

Es posible que Caliburn muestre más inteligencia asignando un modelo de vista a algún elemento. Lo hace ? (Creo que sí.)

Lo que podría ser otra opción es definir un objeto personalizado (xaml utilizable) que active un asignador personalizado, que control se asignará a qué modelo de vista. Qué hay sobre eso ?