Creazione di un database lato client per memorizzare i servizi Web consumati?

Accade anche negli sviluppi del web. Così spesso. Il modello di dati del servizio Web non deve essere condizionato dall'interfaccia utente. Lo rende davvero non flessibile e difficile da scalare.

In termini di sviluppo web, in modello MVC, C (Controller) è la facciata incaricata di trasformare qualsiasi modello di dati aziendali in un DTO. Tali DTO non sono progettati per l'interfaccia utente. Sono un riassunto dei dati reali. Sbagliato dalle sessioni del database.

Tuttavia stai lavorando su V (view) facade, quindi probabilmente avrai bisogno del tuo modello di dati. Orientato all'interfaccia utente. È in qualche modo un involucro o un modello composito. Questo modello dovrebbe essere quello che si mantiene nel database. Non memorizzerei datamodel webservice perché in questo modo si vincola strongmente l'App a quel Webservice e alla sua versione corrente. Nelle versioni successive dell'API, il modello potrebbe cambiare e sarà necessario ridefinire nuovamente il modello APP. Troppa sovrapposizione.

Nel tuo caso preferisco piuttosto implementare Transformers che traducono le risposte dei servizi web nel mio Datamodel dell'interfaccia utente e persistono quest'ultimo (se necessario).

Se qualsiasi entità di datamodel webservices è valida per l'interfaccia utente senza traduzione, anch'io lo farei anch'io. Così com'è. Ad esempio, dati anagrafici.

Adatta le informazioni alle tue esigenze, non legarti a un modello che può cambiare gli straordinari e ti costringerà a comprendere tali cambiamenti in profondità. Un buon piano di traduzione ti impedirà di modificare i modelli di dati e ti renderà più facile gestire queste modifiche. Inoltre, può impedire l'arresto anomalo dell'app perché questo modello di dati cambia.

Summaraizing

Should we be creating the database schema first and then use same database schema for client and server and design our DTOs accordingly?

Secondo me, non farlo.

2 applicazioni 2 modelli di dati traduttori 1-N

Modifica :

Il design finale sarebbe qualcosa di simile

sul lato server : Back-end: ERM Strato persistente: ORM Livello aziendale: entità ORM

Webservices: - Controllori: consumano le entità ORM e le trasformano in DTO. Le DTO sono come il modello di dati del servizio web.

sul lato client :

• Client Webservices: consuma DTO
• Livello driver: trasforma DTO nel modello dati dell'App.
• Livello aziendale dell'app: modello dati app
• Interfaccia utente dell'app: utilizza il modello dati dell'app tramite il livello aziendale dell'app

Se la tua app utilizza direttamente DTO Webservices, sei obbligato a farlo per il bene o per il male. Se progetti il pensiero di DTO sul lato client, sarà difficile riutilizzarlo per un altro client.

Come diciamo qui: Consenti all'app di cooke dei dati e di trasformarli in qualsiasi altra cosa . Lasciare da solo il server.

Tuttavia, se sei sicuro che non ci sarà nessun altro cliente che consuma i tuoi servizi web, l'app client potrà semplicemente utilizzare gli DTO.

Infine, le dead line, il budget e le risorse hanno l'ultima parola ;-). La mia proposta è lo scenario ideale.

Sei vicino al tuo primo punto, ma penso che un approccio migliore sia:

• Progetta il tuo modello di dati (non lo schema del database) con l'input di tutte le fonti disparate che il tuo progetto può finanziare. Avete bisogno delle opinioni di sviluppatori, architetti, tester, utenti e analisti di business. Potresti usare uno strumento UML, ma molti progetti usano solo post-it su un grande foglio di carta. Il tempo trascorso in questa fase del progetto sarà facilmente recuperato dalla mancanza di rielaborazione più avanti nel progetto.
• Dal modello dati, progettare lo schema del database, le operazioni di servizio richieste e le schermate dell'interfaccia utente. In questa fase puoi assegnare una piccola squadra a ciascuna attività.
• Inizia la codifica.

Poiché tutti gli sviluppatori hanno ora la stessa comprensione del dominio aziendale, tutti i pezzi dovrebbero integrarsi senza problemi.

Non temere l'apparente complessità del modello di dati, ma assicurati che rifletta accuratamente la realtà. La complessità del codice è facile da gestire se hai il modello corretto.