Service layer con DTO

Question

Service layer con DTO

#1 da (2 voti)

1

Sto refactoring il mio desiderio di utilizzare un livello di servizio - tuttavia sono confuso su come si passerà gli argomenti, quando è solo permesso di aggiornare determinati campi dell'entità. Ad esempio, ho alcuni campi che possono essere impostati solo alla creazione (metadati). Ma ogni esempio che vedo sul livello di servizio assume l'entità come argomento, ad es. aggiornamento (Entità entità), in cui tutti i valori potrebbero essere stati modificati. Se voglio solo rendere possibile aggiungere ordini (e non modificare qualcos'altro per il cliente). Questo potrebbe essere fatto da:

customer.add(new Order())
service.update(customer)

che sembra molto bello, tuttavia potrei cambiare altri campi nel cliente senza che questo venga notato dal servizio. La mia alternativa sarebbe qualcosa di simile:

service.addOrder(customer, new Order())

Questo sembra ragionevole. Tuttavia, questo potrebbe creare metodi con elenchi di parametri molto lunghi (non validi) e anche caricare la stessa entità due volte (sia in modalità Servicelayer che in quella in cui è stata utilizzata in precedenza). Sarebbe meglio semplicemente creare DTO e metodi per ogni aggiornamento parziale dell'entità? Ciò richiederebbe anche al livello di servizio o al repository di caricare l'entità (eventualmente) già caricata dal database.

java architecture repository orm entity

posta Anders 09.10.2017 - 23:01

fonte

1 risposta

Leggi altre domande sui tag java architecture repository orm entity

Vota l'architettura del database Progetto .NET tracciato con git - mantenendo il Framework 4.0 e 4.5.2 di destinazione in parallelo

score 2 · Answer 1

Sebbene tu possa fare in modo che entrambi funzionino allo stesso modo, non suggeriscono la stessa cosa.

Il primo suggerisce che aggiungere un ordine è qualcosa che faccio al cliente. Sto passando un oggetto Order all'oggetto Customer e mi aspetto che faccia qualcosa con esso. Potrebbe essere semplicemente creare un riferimento o ci potrebbe essere una tonnellata di business logic che lo accompagna. In entrambi i casi, l'oggetto cliente sa cosa fare con l'oggetto ordine. Quindi, trasferisco il cliente al servizio per salvare i dati. Tutto ciò che il servizio fa è prendere il cliente e lo salva. Non potrebbe importare di meno dell'aggiunta dell'ordine.

Il secondo suggerisce qualcosa di molto diverso. La seconda parte presuppone che il servizio sia il luogo in cui va tutta la logica aziendale perché viene passato a questi due oggetti che non sanno nulla l'uno dell'altro e che è previsto che sappiano cosa fare con loro.

Il che è giusto dipende dalle circostanze, ma la mia ipotesi è la prima. Il secondo rende l'interazione dei due oggetti dipendente dal servizio e ciò mi sembra molto limitante. Ma forse c'è qualche ragione nell'applicazione che vuoi.