Ciao,
puoi anche non usare AutoMapper per riconvertire i DTO in entità. Lo usano tutti perché è la maniera più conveniente di mappare un oggetto all'altro.
Se non vuoi usare AutoMapper, semplicemente crei un'istanza del DTO, lo passi a TryUpdateModel in modo che le sue proprietà vengano popolate con i valori indicati nel form, e poi copi a mano i valori sull'entità.
Esempio:
var dto = new BarcaDto();
TryUpdateModel(dto);
//recupero l'entità
var barca = context.Barche.Find(id);
//Copio a mano i valori sull'entità
barca.Descrizione = dto.Descrizione;
barca.Lunghezza = dto.Lunghezza;
...
//Risalvo
context.SaveChangesAsync();
Presentata così, sembra che entità e dto siano un'inutile duplicazione di codice dato che hanno una forma simile. Quindi se ti sembra un'inutile spreco di tempo torna pure ad usare l'entità, modificandola così come ti serve per la UI. Come ripeto: lo puoi fare.
In realtà, se fossi io, non consentirei mai di dare in pasto un'entità alla UI. In primo luogo perché un'entità scritta da me avrebbe quasi tutti i setter privati e la modifica sarebbe consentita solo attraverso metodi che esplicitano l'intento di chi la vuole aggiornare. Per esempio, per assegnargli uno skipper non lascerei mai che si possa fare questo:
entità.Skipper = dtoDelMegaForm.Skipper;
Piuttosto farei:
entità.ImpostaSkipperConLicenza(dtoDiRichiestaAggiornamentoSkipper.Skipper, dtoDiRichiestaAggiornamentoSkipper.Licenza);
...perché immagino che per cambiare skipper si debba verificare se la sua licenza è idonea e valida a condurre quella barca. Inoltre, non lascerei sovrascrivere il precedente Skipper perché di solito lo si deve notificare in qualche modo. Se alcune di queste condizioni vengono violate, il metodo deve sollevare un'eccezione appropriata che faccia capire bene all'utente cosa ha sbagliato a fare. E non posso mettere questa roba nel setter della proprietà perché mi andrebbe in esecuzione anche quando EF materializza l'oggetto e comunque non mi da modo di coinvolgere oggetti aggiuntivi, come la licenza che si vuol usare per condurre quella barca.
Inoltre, anziché fare un mega form di modifica, di solito faccio
task-based UI, cioè mini form che hanno uno scopo specifico. In questo caso, il dto che si occupa dell'aggiornamento dello skipper conterrà solo le proprietà Skipper e Licenza. Quindi, per ogni entità ci sarà un certo numero DTO. Però capisco che per chi è abituato ad applicazioni data-driven con mega form questa roba può sembrare sovraingegnerizzazione.
ciao,
Moreno
Modificato da BrightSoul il 08 novembre 2018 21.06 -