modello per condividere oggetti tra API e applicazione

Sto avendo seri dubbi sulla progettazione della mia applicazione Web.

Volevo separare la logica aziendale dall'interfaccia, quindi ho creato un'API Web che gestisce tutte le richieste al database.

È un'API Web ASP.NET con framework Entity e un'unità di lavoro e un modello di repository generico. Finora è andato tutto bene.

PROBLEMA

Dove ho bisogno di aiuto è non riesco a capire un modo efficiente di condividere oggetti tra l'API e l'applicazione.

Non voglio serializzare direttamente l'oggetto entità, ho pensato che sarebbe stata una cattiva pratica perché se il modello di entità cambia, potrei finire con la serializzazione di oggetti di grandi dimensioni senza motivo.

Come è implementato ora

Poiché la mia interfaccia è l'applicazione Web ASP.NET in C # e la mia API è in C #, ho creato una libreria comune con la definizione di tutte le mie classi che voglio condividere tra di loro.

So che la soluzione non funzionerà quando svilupperò un'app Android, dovrò creare di nuovo le mie lezioni in Java, ma questo non è il mio problema più grande.

Il problema è che mi sento come se stessi convertendo sempre i miei oggetti.

ESEMPIO

Ecco un esempio del mio flusso di lavoro:

Comincio con un modello con tutti gli oggetti e le annotazioni dei dati per il mio modulo, quindi l'utente POST quel modello su un controller.

Nel controller devo convertire questo modello in una classe nella mia libreria comune quindi inviare quell'oggetto alla mia API.

Quindi un controller nella mia API cattura la chiamata e converte quell'oggetto in un oggetto entità per aggiornare il database.

Quindi ho 3 lezioni

1. Il modello per la vista con tutte le annotazioni dei dati per la convalida (client)
2. Le classi di librerie comuni per condividere gli oggetti (DLL)
3. Le classi di entità (API)

Ho la sensazione di fare qualcosa di veramente sbagliato. C'è qualcosa di più elegante? Vorrei assicurarmi di avere una buona soluzione a questo problema prima che il progetto diventi troppo grande.

So che sembra che tu stia convertendo oggetti avanti e indietro continuamente tra i tuoi oggetti di database, i tuoi oggetti di trasferimento dati, i tuoi oggetti client con logica di validazione e così via, ma direi che no, non stai facendo nulla di male .

Ognuno di questi oggetti può rappresentare la stessa unità di informazione, ma hanno responsabilità molto diverse. L'oggetto database è la tua interfaccia di comunicazione con il database e deve essere mantenuto a livello di database poiché potrebbe contenere o meno annotazioni di metadati del database e / o dettagli non necessari sull'implementazione del database in esso.

Il tuo oggetto di trasferimento dati è l'interfaccia di comunicazione con i tuoi consumatori API. Questi dovrebbero essere il più puliti possibile per facilitare il consumo da diverse lingue / piattaforme. Ciò potrebbe imporre alcune restrizioni sull'aspetto e sul comportamento di questi in base ai consumatori API che desideri supportare.

I tuoi oggetti client con la logica di validazione non fanno davvero parte del tuo progetto API, fanno parte del tuo progetto consumer. Questi non possono essere gli stessi degli oggetti di trasferimento dei dati in questo caso poiché si stanno aggiungendo ulteriori logiche specifiche del client (in questo caso gli attributi di convalida) su cui il server non sa nulla (e non si dovrebbe sapere nulla!) contare questi oggetti come parte dell'API, perché in realtà non lo sono. Sono altamente specifici per le applicazioni consumer e alcune applicazioni che consumano la tua API potrebbero non aver nemmeno bisogno di creare questi oggetti e potrebbero sopravvivere solo sui tuoi oggetti di trasferimento dati. Ad esempio, se non avessi alcuna necessità di convalida non avresti bisogno di un ulteriore livello di oggetti completamente identici ai tuoi oggetti di trasferimento dati.

Per me, sembra che ciascuno dei tre tipi di oggetto sia associato molto bene a una singola responsabilità che è la codifica pulita e la buona pratica. Purtroppo, codice pulito e buone pratiche a volte significano che stai scrivendo un sacco di codice extra e saltando attraverso cerchi extra "solo perché". E durante la codifica, potrebbe essere difficile apprezzare il valore che questo ti sta dando, ma non appena rilasci l'applicazione e inizi a supportarla o aggiungendo nuove funzionalità per la prossima versione, probabilmente inizierai ad apprezzare che hai impiegato del tempo per separare queste preoccupazioni correttamente in primo luogo. (Per non parlare del fatto che tu '

Odio anche scrivere codice di conversione tra diversi tipi di oggetti come questo, ma la mia soluzione è in genere una delle seguenti:

• Usa una libreria che fa la maggior parte della conversione di oggetti pesante per te - per esempio, se usi C # puoi usare la fantastica libreria di AutoMapper ( http://automapper.org/ ). Credo che ci siano un paio di altre librerie come questa, ma AutoMapper è la più potente che abbia mai visto finora.
• Se non riesci a trovare una libreria che ti aiuti nelle conversioni di oggetti, scrivi una serie di metodi di utilità per la conversione tra di loro. Questo potrebbe far schifo, ma a lungo andare ne vale la pena, scrivi il metodo di conversione la prima volta che devi convertire qualcosa - non aspettare.