Utilità, classe di servizio e livello di persistenza

1

Ho un metodo nel gestore API che esegue la convalida dell'API, esegue la logica aziendale e quindi effettua una chiamata a db. È una buona idea spostare la logica di business nella classe di utilità o classe di servizio?

IMO la logica di business dovrebbe essere spostata sul servizio in quanto si suppone che le classi di utilità abbiano metodi che possono essere condivisi tra le applicazioni. Se sposto la business logic in una classe di utilità, causerà una dipendenza tra accessor e utility che renderà anche difficile il test dell'unità.

Pls fammi sapere se il mio ragionamento è corretto.

    
posta Yug Singh 20.12.2018 - 11:33
fonte

1 risposta

0

No, non è una buona idea spostare la logica aziendale su utilità e servizi se si desidera un sistema orientato agli oggetti.

Le classi "Utility", Servizi e in generale la separazione della logica aziendale dai dati su cui opera sono l'antitesi della programmazione orientata agli oggetti.

Tuttavia ci sono altri progetti non orientati agli oggetti in Java che possono adattarsi a ciò che si vuole fare. Il modello di programmazione "basato su componenti" di Java Enterprise (con JPA "Beans" ed EJB / CDI Beans / Services), alcune interpretazioni di Domain-Driven Design lo fanno anche.

E sì, qualsiasi logica dipenderà dai dati su cui opera. Questo è esattamente il motivo per cui nell'orientamento agli oggetti non li separiamo, vogliamo avere un oggetto coesivo che sia meno accoppiato ad altri.

    
risposta data 20.12.2018 - 14:24
fonte

Leggi altre domande sui tag