Sto provando a progettare un'applicazione web e, dopo aver letto molto sui pattern di progettazione REST +, non riesco a gestire le mie esigenze. Penso che potrei rimanere intrappolato in tutti gli schemi di progettazione, ma allo stesso tempo voglio produrre un design ben progettato dall'architetto.
Ho 2 oggetti business principali, Customer e Order , con una relazione Has Many . Al momento, non ho un livello di servizio e l'API REST si trova nel BL:
GET Customers GET Orders
GET Customers/id GET Orders/id
POST Customers POST Orders
PUT Customers/id PUT Orders/id
DELETE Customers/id DELETE Orders/id
Ma le cose diventano difficili da progettare quando devo progettare strumenti legacy per l'immissione di dati da parte degli utenti, e anche per il futuro:
-
Ora: gli utenti caricano un file Excel .xlsx contenente informazioni su Cliente, ordine, che analizzo, estrai, creo
Customer/Orderbusiness-objects per ed esegui convalide. Per avere una piacevole esperienza utente, non salvo questi oggetti immediatamente, li restituisco all'utente (insieme a eventuali errori dalle verifiche) in modo che possano apportare le modifiche necessarie prima di inviarli definitivamente. (questa sottomissione in 2 passaggi pubblicizza semplicemente l'esigenza di correggere le fonti di eventuali errori di convalida direttamente nel file Excel). - Futuro: i dati relativi al cliente / ordine verranno gestiti e caricati tramite un servizio / piattaforma web.
Non so come gestire questi requisiti con garbo e in modo intelligente. È questo il caso in cui ho bisogno di esporre un Service Layer che pubblica un'interfaccia per il prossimo caricamento di Excel, oltre a un'interfaccia per il servizio web?
Qualsiasi aiuto alla progettazione sarebbe apprezzato, dato che sono piuttosto nuovo a questo tipo di sviluppo e piuttosto non fare un errore architettonico importante che tornerà a mordermi più tardi ..
Grazie in anticipo.
modificato come suggerito dai commenti