asp.net web api e architettura mvc per applicazioni web

3

Abbiamo un'unica applicazione Web di Visual Studio con più progetti. Uno dei progetti (progetto Servizi) ha le API per i nostri client di app (Android / Ios). Esiste un progetto separato per l'applicazione MVC che alimenta il nostro sito Web desktop e mobile. C'è un progetto per DTO che ha classi POCO per oggetti richiesta / risposta. Un progetto è per entità che ha tutte le nostre entità aziendali. Le classi ViewModel vengono salvate nel progetto MVC / UI stesso. Le classi Adapter (per convertire DTO in entità ed entità in DTO) sono rispettivamente nel progetto di servizi e nel progetto MVC / UI.

Per android / i la richiesta-risposta è la seguente: I parametri di richiesta vengono inviati al progetto di servizi e mappati come DTO tramite gli adattatori di progetto del servizio, questo DTO viene convertito in Entità e passato a BL, DAL, DB / MicroServices. La risposta ritorna al progetto di servizi come entità e viene mappata a un DTO tramite le classi dell'adattatore. Questo DTO viene passato come risposta ai client.

Per il sito web (mobile e desktop) la richiesta-risposta è la seguente: I parametri di richiesta vengono inviati al progetto MVC / UI e sono mappati come DTO tramite gli adattatori di progetto MVC / UI, questo DTO viene convertito in Entity e passato a BL, DAL, DB / MicroServices. La risposta ritorna al progetto MVC / UI come entità e viene mappata a un ViewModel attraverso le classi Adapter. Questo viewModel viene passato alla vista che genera l'HTML e passa HTML ai client.

La differenza principale tra DTO e ViewModel che abbiamo è che DTO sono oggetti piatti mentre ViewModel potrebbe avere anche oggetti nidificati. Inoltre, ViewModel potrebbe avere campi compositi cioè campi come FullName (combinazione di FirstName e LastName) mentre DTO avrà solo proprietà semplici come FirstName, LastName. Il motivo è che vogliamo dare flessibilità alle app, ad esempio, potrebbero voler mostrare FirstName con un font diverso rispetto a LastName.

Ci sono alcune query che abbiamo riguardo all'architettura sopra?

  1. Dovremmo avere diversi progetti per Web API e MVC / UI?
  2. Dovremmo avere ViewModel solo per applicazioni MVC e restituire un semplice DTO alle App e lasciare che costruiscano ViewModel per la loro UI?
  3. È corretto accettare solo DTO dai client e restituire loro solo DTO / HTML? È necessario convertire DTO in entità per ogni richiesta e viceversa per ciascuna risposta?
  4. Le classi dell'adattatore (per convertire DTO in entità e viceversa), dovrebbe essere in un progetto separato o nello stesso progetto?
posta maverick 01.06.2018 - 05:49
fonte

1 risposta

3

Sembra che manchi un livello di servizio tra la tua logica aziendale e i tuoi siti web.

Se si disegna in una sezione orizzontale sul diagramma per questo, è possibile vedere immediatamente che è possibile scegliere se:

  • Sposta il "Progetto servizi" esistente in quel livello e fallo consumare sia dal sito Web che dai client mobili.

  • OPPURE per creare un nuovo progetto comprendente l'orchestrazione dei tuoi oggetti aziendali che consumano due progetti WebSite / WebAPI più snelli.

Non avrei più progetti per gli adattatori, come vedrei il ruolo principale di WebSite / WebApi dopo aver spostato qualsiasi logica non vista sul livello di servizio.

Is it correct to accept only DTO from the clients and return back only DTO/HTML to them? Is it necessary to convert DTO to entity for each request and vice-versa for each response?

Non hai molta scelta. Devi serializzare l'Entità, qualunque sia la tua serializzazione su DTO o ViewModel.

La tua unica domanda è in realtà quanto il ViewModel / DTO sia simile all'entità. Solitamente ViewModel / DTO semplifica il lavoro del View / Client aggiungendo campi, appiattendo i dati ecc. Come dici tu. Ma il modo più semplice è a volte solo per serializzare l'Entità così com'è.

    
risposta data 01.06.2018 - 13:04
fonte

Leggi altre domande sui tag