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.