Tipi di restituzione dalle interfacce di servizio in Service Layer: necessario il mapping per gli oggetti del livello UI?

4

Sto progettando un sistema basato su componenti che utilizza JSF2 sopra il contenitore IoC di Spring.

Si tratta di utilizzare un livello di servizio tra un controller e il dominio / livello aziendale (prevedo che il controller non sia altro che il binding JSF Servlet nel file web.xml).

La logica del livello di servizio (conforme a un'interfaccia per ciascun servizio) è quella di consentire la modifica dei servizi.

Mi è venuto in mente che i tipi di ritorno degli oggetti dagli oggetti del livello di servizio sono probabilmente oggetti business dal livello aziendale, che verrebbero quindi utilizzati nei bean di supporto per la vista JSF per popolare i componenti dell'interfaccia utente le pagine.

Idee:

  • È accettabile come pratica standard per questi livelli aziendali,
    dire che un oggetto Customer () torna da FindCustomerService, a
    essere passato di nuovo a un bean di supporto di Presentation Layer? Il Presentation Layer può conoscere i Business Objects o questi non fanno parte del Servizio / definiti per l'uso nell'interfaccia del servizio e quindi parte del contratto per l'implementazione di un servizio?

  • In alternativa, dovrei pensare a rappresentare i componenti su
    l'interfaccia utente che utilizza un insieme generico di classi di interfaccia utente all'interno dei bean di supporto, che vengono quindi mappate ai tipi di ritorno che tornano dal livello di servizio in un altro livello tra il Controller e il livello di servizio? (Ciò richiederebbe probabilmente una riprogettazione se un servizio è stato modificato?)

  • Forse è una pratica standard restituire utilizzando scalari di linguaggio standard e tempi di ritorno dell'oggetto dal livello di servizio per evitare la necessità di un livello di traduzione?

Primo progetto SOA. Immagino che questa sarebbe una bella domanda per l'archiviazione e che i collegamenti a modelli appropriati sarebbero molto apprezzati.

    
posta 8bitjunkie 01.02.2012 - 01:36
fonte

1 risposta

4

Le tue ipotesi sono solide e sono molto simili alle mie nei progetti a cui sto lavorando attualmente.

Ecco approssimativamente in che modo percepisco l'architettura componentizzata:

 JSF Page (.jsf, .xhtml, etc..) View

 Managed Bean - Controller, Presentation Logic

 Business Logic Layer

 Data Access Layer (Database DAO's, Web Service DAO's)

 Database, Web Service, File store persistence, etc...

Per fornire alcune informazioni su alcuni dei tuoi punti:

Si presume che i servizi Web in questione restituiranno oggetti Java? Forse sono oggetti dati Java ordinari serializzati come XML, forse non lo sono. Se sono veramente esterni da una terza parte, allora non puoi fare questo tipo di ipotesi. Idealmente nel tuo esempio, tuttavia, il servizio web restituisce un oggetto Customer , dovresti definire e controllare la classe Customer nel tuo progetto. In caso contrario e si passa semplicemente questo oggetto al livello Presentazione, la propria applicazione è esposta al rischio che il servizio Web esterno possa modificare questo oggetto in futuro e questo sarebbe un punto di errore a tutti i livelli.

Non vorrei passare un oggetto Java come quello in cui non controllo la sorgente. In questo caso, dovrebbe verificarsi un'operazione di conversione sui dati restituiti dal servizio Web nel livello di accesso ai dati, che farà presupposizioni sui dati restituiti dal servizio web e tradurli in bean Java che controlli e che fanno parte del tuo progetto. In questo modo dal livello Business Logic in su, supponendo che la classe Customer rimanga invariata, questi livelli non saranno interessati da una modifica nel servizio web esterno. L'unico livello interessato sarà il livello di traduzione. Questo è in genere il modo in cui le cose vengono fatte con i servizi Web in SOA.

    
risposta data 01.02.2012 - 16:21
fonte

Leggi altre domande sui tag