Quale convenzione di denominazione utilizzate per il livello di servizio in un'applicazione Spring MVC?

Question

Sono bloccato a trovare una buona convenzione di denominazione per il livello di servizio in un'applicazione di primavera. Per ogni classe nel livello di servizio prima scrivo l'interfaccia che dovrebbe implementare e quindi la classe effettiva. Così, per esempio, ho il seguente interfaccia:

public interface UserAccountManager{ 
    public void registerUser(UserAccount newUserAccount); 
    public void resetPassword(UserAccount userAccount); 
... 
} 

E poi la classe di implementazione ...

Che bug me qui è UserAccountManager è un buon nome per la classe di implementazione così sono costretto a dare esso un nome stupido come SimpleUserAccountManager o UserAccountDbManager. Quali sono alcune delle convenzioni che hai utilizzato fino ad ora? È una buona idea mettere le classi di implementazione in un pacchetto diverso e dare loro gli stessi nomi delle interfacce? Quali sono i tuoi pensieri sull'uso di nomi che terminano con Manager sui nomi che terminano con Service?

Answer 1

Spring stessa fornisce nomi generici di interfacce e quindi nomina le classi in base ai dettagli dell'implementazione. Questo è un esempio che viene in mente:

interface: Controller 
abstract classes: AbstractController, AbstractCommandController, 
        SimpleFormController, MultiActionController 

Non credo che nomi come SimpleUserAccountManager o UserAccountDbManager sono stupidi, dal momento che essi trasmettono alcune informazioni riguardanti l'attuazione del manager/servizio.

Quello che trovo stupido è la convenzione comune per aggiungere il suffisso "Impl" presso le classi di implementazione:

my/package/UserAccountManager 
my/package/impl/UserAccountManagerImpl 

Alcune persone preferiscono questo però.

Answer 2

sento che il Servizio vs. Direttore suffisso denominazione è puramente una preferenza. L'unica volta in cui "Service" ha mai causato confusione per noi è quando abbiamo anche i servizi Web che si trovano in cima al nostro livello di servizio. In alcuni progetti, ci siamo semplicemente rivolti alle classi di servizi Web come broker, poiché tutto ciò che facevano era di tradurre o mediare la chiamata di servizio Web in una chiamata al nostro livello di servizio.

Sono d'accordo con kgiannakakis che il suffisso delle implementazioni con "Impl" non è un buon approccio. Ho anche incontrato le migliori pratiche di codifica che menzionano di non farlo. Denominare l'interfaccia dopo l'astrazione è la best practice generalmente accettata. Denominare la classe di implementazione dopo l'interfaccia con qualche indicatore del suo scopo o tipo, come suggerito da kgiannakakis, sembra essere l'approccio generalmente accettato.

Quando abbiamo DAO basati su servizi Web e DAO basati su ORM, utilizziamo sia i pacchetti che i nomi di classi per differenziare le classi di implementazione dalle loro interfacce e l'una dall'altra. Penso che mettere le implementazioni in pacchetti diversi dipenda dal numero di classi che hai nel pacchetto, da quanto sono implementate in modo diverso e da quanto desideri dividere le cose.

Answer 3

Per l'esempio che si dà, vorrei utilizzare i nomi di implementazione che riflettono come classe esegue le operazioni, come HibernateUserAccountManager, o JPAUserAccountManager o JDBCUserAccountManager, ecc, o forse solo UserAccountManagerDAO.

Answer 4

È anche possibile denominare l'interfaccia IUserAccountManager (questa convenzione viene utilizzata in Eclipse RCP, ad esempio) e quindi utilizzare UserAccountManager per l'implementazione predefinita.

Answer 5

Ecco ciò che usiamo:

• XxxDAO (Data Access Object) - Responsabile per interagire direttamente con l'EntityManager, JDBC DataSource, file system, ecc Dovrebbe contenere solo la logica di persistenza, come ad esempio SQL o JPA-QL, ma non (o il meno possibile) logica aziendale. Dovrebbe essere accessibile solo dai gestori.
• XxxManager - Gestisce le entrate a livello aziendale, di solito esegue operazioni CRUD, ma aggiunge la logica aziendale richiesta.
• XxxService - Il livello in cui si trova la business logic. Dovrebbe "parlare" in oggetti semplici - Archi, intarsi, ecc. - il più possibile.
• XxxController - Il livello di interazione dell'interfaccia utente. Dovrebbe parlare solo con i Servizi.
• XxxUtilities/XxxUtils - I metodi statici di supporto, non devono dipendere da alcun servizio nel sistema. Se hai bisogno di tale dipendenza, converti la classe di utilità in un servizio o aggiungi il risultato del servizio come parametro.

Per l'attuazione si aggiunge l'Impl suffisso (XxxServiceImpl), ad esso distinta dall'interfaccia, e se ci sono diverse implementazioni o vogliamo aggiungere ulteriori informazioni aggiungiamo come prefisso (JdbcXxxDaoImpl, GoogleMapsGeocodingServiceImpl, etc.). I nomi delle classi diventano un po 'lunghi in questo modo, ma sono molto descrittivi e autodocumentanti.

Answer 6

Ovviamente non è importante di per sé se i nomi delle classi terminano in Manager o Servizio. Ciò che è importante, in generale, è che i nomi trasmettono esattamente ciò che viene modellato. E questo è il punto cruciale del problema: "Servizi" o "Gestori" non sono oggetti del mondo reale che cerchiamo di modellare nei nostri oggetti software. Piuttosto, sono luoghi in cui raccogliamo una serie di metodi che fanno cose che semplicemente non si adattano alle responsabilità di nessuno degli oggetti che abbiamo do o che vuoi modellare.

Personalmente preferisco il "servizio", ma solo perché "manager" sembra qualcosa che si potrebbe effettivamente modellare, cioè ci potrebbero essere manager del mondo reale che rappresentano i nostri oggetti "-manager". Ma il punto è interamente accademico e ammetto immediatamente che non fa praticamente nessuna differenza.

Ciò che conta davvero è di gran lunga più basilare di questi punti: avere un modello che sia ben compreso da tutti coloro che sono coinvolti nello sviluppo. Se la mia esperienza è qualcosa da fare, è raro che sia così. Il mio suggerimento per chi chiede se "manager" o "servizio" è la metafora giusta è quindi: lancia una moneta, assicurati che tutti conoscano la convenzione e dedica il tuo tempo a riflettere e discutere su questioni importanti!

Answer 7

Per me una classe di servizio riguarda l'implementazione di un caso d'uso, quindi lo chiamo in base al tipo di utente che il servizio sta agendo per conto di. Quindi, se ho un'applicazione con ruoli diversi, ad esempio clienti, persone di Fullfillment di ordini, persone di data entry e amministratori, probabilmente avrò un CustomerService, un OrderFulfillmentService, un DataEntryService e un AdminService. Penso che nominare un servizio in base al tipo di dati che vengono recuperati o twittati sia un anti-pattern. Quindi, supponendo che la manipolazione di UserAccount sarebbe il dominio di un amministratore, probabilmente lo chiamerei "AdminService".

Answer 8

Supponendo che si tratti di servizi REST, ritengo che la convenzione di denominazione URI sia più importante del nome dei servizi di implementazione sottostanti, poiché quest'ultimo sarà in gran parte invisibile ai client. Certo, vuoi un nome coerente internamente, ma non è così cruciale.

Alcune linee guida resto lo hanno usato: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (il mio blog)

Answer 9

correlati alla differenza tra manager e servizi: direi uso uno strato per la logica di business (livello di servizio o lo strato manager) per tutto il tempo il più possibile

Non appena tale livello diventa complicato (si presuma che i servizi utilizzati) è possibile aggiungere gestori con la responsabilità di delegare a un servizio o un altro, ma mantenere la logica di business all'interno dei servizi.

Quindi vorrei mantenere i servizi semplici, utilizzare i gestori per gestire i servizi e mantenere la logica aziendale all'interno dei servizi.

Concordo anche con l'evitare il suffisso Impl per le implementazioni ed evitare il suffisso I per le interfacce. Ad esempio, nominare l'interfaccia "Controller" e nominare l'implementazione "SimpleController" o "UserController" suona meglio per me.