MVP/MVVM - Filtrado de listas, ¿quién tiene la responsabilidad?

Question

Estoy implementando una aplicación wpf que muestra una lista de elementos y proporciona la funcionalidad para filtrar esta lista escribiendo en un cuadro de texto (caso de uso bastante trivial, creo).

Estamos utilizando una estructura MVVM.

Mi pregunta es, ¿de quién es la responsabilidad de filtrar la lista? La vista o el modelo de vista? Debería implementar un evento "OnTextChanged" en xaml.cs, o debería usar una propiedad en ViewModel y usar PropertyChanged para filtrar la lista.
La siguiente pregunta es, ¿debo usar una BindingList/ObservableCollection en el ViewModel, o usar un ICollectionView para vincular ItemsControl a?

Intenté ambos métodos, y ambos funcionan. Darle la responsabilidad a ViewModel mantiene el código detrás de la Vista vacía, pero por otro lado no estoy completamente convencido de que sea responsabilidad de ViewModels aplicar filtros (por ejemplo: diferentes vistas pueden requerir diferentes filtros)

Cualquier idea ?

gracias, Roel

EDIT:

lo que me molesta de ponerlo en el modelo de vista es que (en mi aplicación actual) hay una referencia al System.Windows.Data. Esta es una referencia que preferiría no tener en ViewModel porque es claramente algo relacionado con View. ¿O me estoy perdiendo algo? código relevante:

ICollectionView customerView = CollectionViewSource.GetDefaultView(customers); 

Answer 1

ViewModel, sin lugar a dudas. Evitar el código subyacente es el objetivo final del patrón; de hecho, ViewModel es el código detrás de la vista.

por ejemplo: puntos de vista diferentes pueden requerir diferentes filtrado

diferentes puntos de vista deben tener diferentes ViewModels. ViewModel es básicamente un enfoque (algo más) orientado a objetos para archivos de código subyacente.

En cuanto a CollectionView: puede definir CollectionViewSource en la vista XAML, y luego vincular sus propiedades de clasificación y filtrado a ViewModel. Eso debería mantener el control en ViewModel y CollectionView a la vista, pero creo que es una sobreingeniería.

Answer 2

Creo que este tipo de funcionalidad de filtrado pertenece al modelo de vista. Recuerde, usted desea mantener el mayor código posible de verificación en el modelo de vista (que realizará una prueba unitaria, ¿no?). Por el contrario, querrás mantener la vista delgada y mala.

La funcionalidad de filtrado es genérica y no está vinculada a la vista como tal. Pero si una vista diferente necesita un filtrado diferente, debería verlo como una funcionalidad adicional admitida por el modelo de vista.

Answer 3

No hay una respuesta técnica correcta. El objetivo del patrón es dividir las preocupaciones de la funcionalidad y la estética, sobre la base de que una persona diseñadora artística no entiende cómo implementar la funcionalidad, y las IU son difíciles de probar.

Pero si puede parametrizar el filtrado a algo muy simple, p. una propiedad de texto llamada "Región" que se puede configurar como "Europa", "América del Norte", "Aisa", etc., que es bastante fácil de entender y se puede probar independientemente. Te permite poner un poco de control sobre la funcionalidad (en un sentido muy limitado) en la vista. Si eso tiene algún valor para sus esfuerzos, entonces hágalo. Si no lo hace, no lo haga.

Y en última instancia, si intenta aplicar este patrón hace que se detenga y se pregunte acerca de las distinciones filosóficas, al costo de la productividad, entonces no lo está ayudando.

Answer 4

Puede consultar this article en mi blog donde utilizo la metodología MVVM para filtrar una colección de artículos. Creo que esto es definitivamente responsabilidad de la clase VM.

Answer 5

Estoy de acuerdo con usted en que es preocupante que haya una fuga de tecnología View en VieModel. En una línea similar, uso un objeto RelayCommand en mi ViewModels que está usando System.Windows.Input.

Por todos los motivos publicados aquí, creo que ViewModel es la opción de diseño correcta para este medio (wpf/silverlight), aunque no sea perfecto.