Le azioni CRUD dovrebbero essere classi Java?

In parole povere:

• Le classi dovrebbero essere modellate su entità, cose, non verbi.
• I metodi dovrebbero essere modellati dopo i verbi.

Quindi ...

La classe potrebbe essere PhoneDirectoryEntry (una cosa) che ha un metodo chiamato save() (un verbo).

Bottomline:

No, le classi non dovrebbero essere modellate dopo azioni / verbi (CRUD o altro).

Sebbene le classi di solito rappresentino entità, possono esserci eccezioni. Ad esempio, se stai implementando un modello di comando ( link ) le tue classi rappresentano azioni. Quindi non esiste una regola rigida che dica che non puoi modellare le tue azioni come classi ma dipende dal tuo fabbisogno.

Questo potrebbe essere più chiaro se pensi alle chiamate API REST.

La voce è la risorsa.

Aggiungi è modellato come una chiamata POST sulla risorsa di ingresso.

Quindi java jaxrs sarebbe qualcosa del tipo:

@Path("entry")
public class Entry {
  @POST
  public String addEntry(@FormParam("entry") String name) {
    // store csv
  }
  @GET
  public String retrieveEntryFromCSV(@Context UriInfo ui) {
    // get entry
  }
}

Ci sono (almeno) tre direzioni in cui possiamo affrontare la domanda per trovare ragioni che suggeriscono che una singola classe con più metodi è più appropriata.

Innanzitutto, una delle ragioni è che ciascuna delle singole operazioni C, R, U, D deve accedere alla stessa memoria sottostante. Se cambi il meccanismo / oggetto di archiviazione sottostante, ciò significa probabilmente cambiare tutte e 4 le classi C / R / U / D (e se ciò non significa che l'oggetto di archiviazione comune sottostante stia già fornendo un'astrazione CRUD per nascondere i suoi dettagli! ). Il requisito di archiviazione sottostante comune suggerisce una singola classe con metodi su più classi che condividono un oggetto di memorizzazione comune (una classe contro 5 classi).

In secondo luogo, un'altra ragione è che dovremmo pensare a come possiamo aggirare e / o condividere le capacità CRUD con altri codici che vogliono usarlo. Come classi separate, dovremmo passare separatamente gli oggetti C, R, U e D a vari altri utenti delle capacità. Come singola classe, passiamo semplicemente attorno all'unica entità.

La buona programmazione consiste nel fornire astrazioni che possono essere costruite da te e forse da qualcun altro. Vuoi allontanarti dalle operazioni di basso livello e fornire utili e rilevanti astrazioni. Queste astrazioni sono necessariamente gruppi di funzionalità che sono correlate l'una con l'altra, raggruppate insieme . A volte questo significa una singola classe, altre volte una gerarchia di classi e altre volte un insieme di interfacce. Una terza ragione è che siccome non stai fornendo una gerarchia di classe reale (ma piuttosto una serie piatta di classi), scegli una singola classe come pacchetto per la tua astrazione.