Czy to dobry pomysł, aby dodać ViewModel dokładnie tak samo jak Model

W moim rozwiązaniu mam następujące warstwy:

1. App.Domain
2. App.Service
3. App.Core (może to się nazywa App.DataLayer)
4. App.Web

Wzorzec projektowania oprogramowania to nie moje pytanie, mam następujący model w Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Chcę użyć tego modelu w widoku (na przykład na stronie głównej) ORAZ chcę użyć Id, Name & Value, więc jeśli chcę utworzyć ViewModel, dodam następujące:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Czy to dobry pomysł? lub po prostu użyj Foozamiast FooViewModel?

Początkowo może to wyglądać na naruszenie zasady DRY, ale twierdzę, że „podobny, a nawet identyczny, kod” niekoniecznie musi „powtarzać się”, jeśli robi coś innego lub jest w stanie zmienić się niezależnie. W przypadku modeli widoku kod określa to, co widzi „klient”, niekoniecznie podmioty i operacje, o których mówi biznes. Często ujawniasz klientowi modele lub interfejs, które są „nawiasem mówiąc identyczne”. Możesz zmienić zasady i warunki biznesowe lub terminologię użytkownika końcowego niezależnie od siebie.

Więc zwrócę ci pytanie. Jeśli domena ulegnie zmianie, czy klienci „wersji 1” mogą nadal korzystać ze starych interfejsów? Czy kiedykolwiek ujawnisz warunki lub operacje w interfejsie, które nie są częścią „podstawowych reguł biznesowych”? I wzajemnie?

Tego rodzaju pytania mają na uwadze, jeśli „funkcja” twojego widoku ma na celu wyłącznie ujawnienie podstawowego modelu domeny, tak, wygląda na to, że narusza zasadę DRY.

_{Należy również pamiętać, że odsłonięcie widoku, który zmienia się bardziej naturalnie wraz ze zmianami modelu, można również osiągnąć w niektórych językach z atrybutami elementu i refleksją. (Lub z mniejszą liczbą powtórzeń poprzez inne wyczyny sprytu ... Ale „spryt” często nie usprawiedliwia powtórzeń, które oszczędzają.)}

Miałbym model widoku zawierający tylko jedną właściwość, instancję Foo. W ten sposób nie naruszasz DRY zgodnie z jakąkolwiek jego definicją, jeśli zmieni się Foo, twój model widoku automatycznie zobaczy zmianę i pozostaniesz wolny od bezpośredniego powiązania modelu widoku z modelem.

Jeśli jutro będzie potrzeba, aby widok pokazywał coś innego, a także Foo, możesz po prostu dodać nową właściwość, a zamiary modelu widoku nadal będą jasne, zawiera ona Foo i coś innego, czego nie będziesz mieć mieszanka właściwości Foo z niepowiązanymi innymi właściwościami.

Nie pomyślałbym o twoim modelu widoku jako modelu FooViewModel, pomyślałbym o tym pod względem tego, co widok ma wyświetlać. Jeśli wyświetla tylko jeden Foo, wówczas model widoku zawiera jedną właściwość, Foo.

Nie jestem pewien, czy wyjaśniłem to jasno. Jeśli nie, daj mi znać, a spróbuję przeredagować to, gdy się obudzę!

Powiedziałbym, że użycie FooViewModelw ten sposób narusza zasadę SUCHEGO. Kiedy musisz dokonać zmiany, Foomusisz również dokonać zmiany w FooViewModel. Myślę, że lepiej byłoby, gdybyś był po prostu użyty Foojako model twojego widoku. Rozważę model widoku, jeśli chcesz wyświetlić rzeczy z Foo i coś innego. Na przykład powiedz, że musisz renderować niektóre informacje Foozi Bar.