Chciałbym zaprosić do tego wątku @somekind .
Generalnie z MVC jest tak, że z jednej strony "encja na twarz i pchasz", co ponoć jest złym podejściem, a z drugiej strony mamy zdublowane modele. Chciałbym rozpocząć konstruktywną dyskusję na ten temat - kiedy tak, kiedy inaczej i dlaczego.
Ogólnie rzecz biorąc (zaznaczam - przypadek OGÓLNY) uważam, że nie ma sensu duplikować modeli. No bo co. Załóżmy, że mamy model:
public class Client: DbItem
{
public string Name {get;set;}
public string EmailAddress {get;set;}
public Address Address {get; set;}
public string PassHash {get;set;}
}
//DbItem to jakaś klasa trzymająca dane wszystkich modeli będących w bazie danych, np. pole Id.
//Przyjmijmy, że model nie jest anemiczny.
Teraz, jeśli chcemy zmodyfikować go, wystarczyłoby ten obiekt wysłać do widoku i widok ładnie sobie wszystko poogarnia.
Możemy stworzyć coś w rodzaju ClientViewModel:
public class ClientViewModel
{
[Required(MinLength=5)]
public string Name {get;set;}
[Required]
[EmailAddress]
public string EmailAddress {get;set;}
public Address Address {get; set;}
}
Ale to mi wygląda już na duplikowanie kodu - a więc łamiemy zasadę DRY (zaznaczam - mowa o przypadku ogólnym).
A jeśli widok jest nieco bardziej skomplikowany, możemy skończyć z czymś takim:
public RegisterUserViewModel
{
public ClientViewModel Client {get;set;}
public RegistratorViewModel Reg {get;set;}
public InnyViewModel VM {get;set;}
//inne dane
}
Więc czemu technika powielania modeli miałaby być lepsza? Jeśli zmieni się coś w modelu głównym, wtedy zmiany w kodzie mogą być w wielu miejscach. Rozumiem potrzebę zdublowania modelu, jeśli chodzi o Api. W takich przypadkach prawdopodobnie powinniśmy tworzyć DTO. Ale co w sytuacji widoków?