Przeczytałem dziś artykuł http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx o używaniu wzorca MVVM w aplikacji silverlight, w której masz swoje jednostki domeny i wyświetlasz spesualne jednostki, które są w zasadzie podzbiorem rzeczywistych obiektów obiektu. Czy nie jest to wyraźne naruszenie zasady DRY? a jeśli tak, jak możesz sobie z tym poradzić w miły sposób?Model-View-ViewModel wzór naruszający DRY?
Osobiście nie podoba mi się to, co robi Dino i nie podchodzę do problemu w ten sam sposób. Zazwyczaj myślę o maszynie wirtualnej jako filtrowanej, pogrupowanej i posortowanej kolekcji klas modeli. VM to dla mnie bezpośrednie odwzorowanie do widoku, więc mogę utworzyć klasę NewOrderViewModel, która ma wiele widoków kolekcji używanych w widoku (być może jedno CV dla klientów i inne CV dla produktów, prawdopodobnie oba są filtrowane). Stworzenie całkowicie nowej klasy VM dla każdej klasy w modelu narusza DRY w mojej opinii. Wolałbym używać wyprowadzeń lub klas częściowych w celu rozszerzenia Modelu tam, gdzie było to konieczne, dodając Właściwości specyficzne (często obliczane). IMO .NET RIA Services to doskonała implementacja połączenia danych M i VM z dodatkową premią, z której można korzystać zarówno na kliencie, jak i na serwerze. Dino jest genialnym facetem, ale sposób, by zadzwonić do niego na ten temat.
SUCHA to zasada, a nie zasada. Jesteś człowiekiem i potrafisz odróżnić. E.g. Jeśli DRY naprawdę był trudną regułą, nigdy nie przydzieliłbyś tej samej wartości dwóm różnym zmiennym. Domyślam się, że w każdym nietrywialnym programie miałbyś więcej niż jedną zmienną zawierającą wartość 0.
Ogólnie rzecz biorąc: DRY zwykle nie ma zastosowania do danych. Te specyficzne obiekty widokowe prawdopodobnie byłyby tylko obiektami transferu danych bez żadnej godnej uwagi logiki. Dane mogą być powielane z różnych powodów.
Ciągle uważam, że jest to bardzo złe, ponieważ tworzysz lekkie klasy obiektów dla viewmodelu i powtarzasz je dla rzeczywistych jednostek. – terjetyl
Dlaczego uważasz to za złe? – EricSchaefer
Myślę, że to złe naruszenie suche, ponieważ tworzysz 2 prawie identyczne klasy reprezentujące ten sam podmiot również bez korzystania z dziedziczenia – terjetyl
Myślę, że odpowiedź naprawdę zależy od tego, co Twoim zdaniem powinno być w ViewModel. Dla mnie ViewModel reprezentuje model aktualnie wyświetlanego ekranu.
Dla czegoś takiego jak ViewCategoryViewModel, nie ma duplikacji pól w kategorii. Narażam obiekt kategorii jako właściwość na ViewModel (pod powiedzą "SelectedCategory"), wszelkie inne dane, które widok musi wyświetlić i polecenia, które może wykonać ekran.
Zawsze będzie pewne podobieństwo między modelem domeny i modelem widoku, ale wszystko sprowadza się do sposobu, w jaki wybierasz tworzenie ViewModel.
Jest taki sam, jak w przypadku obiektów przenoszenia danych (DTO).
domeny dla tych dwóch typów obiektów jest inny, więc nie jest to naruszenie DRY.
Rozważmy następujący przykład:
class Customer
{
public int Age
}
a corsponding Widok Model:
class CustomerViewModel
{
public string Age;
// WPF validation code is going to be a bit more complicated:
public bool IsValid()
{
return string.IsNullOrEmpty(Age) == false;
}
}
Differnt domen - differnet rodzaje nieruchomości - różne przedmioty.
1. Czym jest domena w tym kontekście? 2. Twój model biznesowy ma jednostkę klienta. Wyobraź sobie, że masz jednostkę Klienta, klienta DTO i CustomerViewModel, oczywiście masz tam wiele duplikatów nieruchomości. Widzę to jako wyraźne naruszenie DRY – terjetyl
1. Klient jest prawdopodobnie mapowany z NH do bazy danych, może nawet zawierać pewne hacki z powodu nie tak doskonałego schematu db. Ma wiele metod biznesowych, kolekcji, które najprawdopodobniej nie są potrzebne, gdy wyświetlasz je na ekranie. 2. Zasada pojedynczej odpowiedzialności (SRP) mówi, że obiekt powinien mieć tylko jeden powód do zmiany, jeśli klasa klienta jest używana jako model biznesowy, DTO i ViewModel w MVVM, niż wyraźnie wymienia SRP. Zauważ, że zgadzam się, że są sytuacje, w których łatwiej jest mieć tylko jedną klasę, wszystko zależy od kontekstu. –
Rozważ również właściwości takie jak IsSelected na ViewModel i anulowanie edycji na ekranie (musisz przywrócić obiekt klienta, jeśli nie wiążisz jakiejś klasy CustomerViewModel), implementacja INotifyPropertyChanged. Tylko w bardzo uproszczonym scenariuszu wydaje się to naruszeniem DRY. –
Uzgodnione, VM powinna być tylko tymi częściami modelu, o których powinien wiedzieć View. –