Le interfacce di business dovrebbero far parte del livello Model?

0

In un'applicazione enterprise orientata ai servizi, non è un antipasto collegare le API dei servizi (contenenti l'interfaccia da cui dipendono gli utenti esterni) con gli oggetti Model (entità, oggetti personalizzati, ecc ...)?

Secondo me, i servizi dovrebbero dipendere solo dal livello del modello, ma non devono mai essere combinati con esso.

In effetti, il mio collega mi ha detto che non ha senso separarlo dal momento che il cliente ha bisogno di entrambi. (modello e interfacce di servizio)

Ma noto che ogni volta che un client richiede alcune modifiche, ad esempio l'aggiunta di un nuovo metodo in alcune interfacce (indica un nuovo servizio), il livello del modello deve essere anche consegnato ...

Quindi, il cliente che non è interessato a questa "aggiunta" è costretto a preoccuparsi di questo aggiornamento del Modello ... e in una grande applicazione aziendale, questo tipo di consegna è noto per essere molto a rischio ...

Qual è la migliore pratica? Separare i servizi (solo le interfacce in modo tale) e modellare gli oggetti o mescolarli?

    
posta Mik378 23.03.2012 - 16:06
fonte

2 risposte

1

Dipende dal fatto che il client stia utilizzando esattamente lo stesso modello di dominio del server / servizio. In genere non lo fa, quindi dovrebbero essere tenuti separati IMO.

    
risposta data 23.03.2012 - 16:22
fonte
1

Sembra che ti riferisci a modelli di dati, non a modelli di business, e per me i modelli di dati sono solo stupidi oggetti di dati. Il loro unico scopo nella vita è di conservare i dati e non eseguono alcuna logica o funzionalità aziendale. Non dovrebbero esserci problemi nel mantenerli completamente separati dal resto del codice dell'applicazione.

In genere, i miei modelli di dati risiedono nella loro libreria, a cui i livelli aziendali possono fare riferimento, mentre i modelli aziendali di solito fanno parte del livello aziendale.

    
risposta data 23.03.2012 - 17:33
fonte

Leggi altre domande sui tag