Un metodo di aggiornamento nella classe Repository CRUD dovrebbe sempre restituire qualcosa?

Dovresti restituire i valori perché non ne hai bisogno perché rende più facile il test. Detto questo, è più importante sapere se l'operazione ha avuto successo dal momento che sai già cosa verrà aggiornato. Se qualcosa va storto puoi usare le eccezioni per comunicarlo ai livelli superiori. Inoltre, non penso che restituire un valore che rappresenti il numero di record interessati possa fornire molto valore dal momento che probabilmente aggiornerai gli aggregati che hanno figli aggiornati.

Direi di restituire la nuova entità. Il mio ragionamento deve fare particolarmente con REST, ma penso che sia ragionevole progettare un livello di archiviazione in modo che possa essere facilmente utilizzato in un servizio RESTful.

10.2.1 200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

RFC 2616 - Codici di risposta Http - Enfasi di enfasi

Poiché ci si aspetta che le richieste POST restituiscano una descrizione della transazione o l'entità risultante effettiva, sembra molto ragionevole assicurarsi che il livello di archiviazione lo renda disponibile.

Separazione di preoccupazione. Al momento dell'aggiornamento / salvataggio, ciò che è cambiato è già noto poiché è necessario aggiornarlo. Tutta la logica deve essere fatta nella parte aziendale, la parte io non dovrebbe nemmeno essere a conoscenza di ciò con cui tratta.