È una cattiva pratica avere FooObject e FooObjectSummary?

Come per tutte le cose, dipende.

Il principio di segregazione dell'interfaccia indica che probabilmente dovresti avere le due viste nei dati in modo da non rompere i consumatori se una delle proprietà non vitali viene cambiata.

In generale, non devi condividere l'interfaccia che usi per accedere al database con i consumatori. Cosa succede quando si desidera modificare la modalità di memorizzazione dei dati, mantenendo l'interfaccia utente allo stesso modo? Anche se non è ovvio, l'essenza del principio di responsabilità unica si applica anche qui.

Tutto ciò detto, se quell'interfaccia sarà realmente la stessa (se cambi l'interfaccia utente o l'interfaccia SQL entrambi dovranno cambiare indipendentemente [il tuo servizio è solo un pass-through]) e i dati extra veramente non sono grandi o importanti, quindi risparmiano tempo e la complessità potrebbe essere la migliore.

Dovrai pesare il tempo risparmiato contro la probabilità che la violazione dei due principi ti morderà più tardi nel culo.

Posso capire perché hai percorso il percorso che hai e capisci le tue ragioni per farlo. Dopo tutto, perché andare e avere dodici proprietà quando ne userai solo tre. Perché inviare un oggetto con dodici proprietà quando si visualizzano solo tre. È semplicemente più ordinato farlo nel modo che hai.

Non dirò che hai ragione o torto. Tutto quello che direi è che se vengono aggiunte sempre più proprietà a FooObjectSummary, allora inizia a sembrare una duplicazione inutile. In questo momento, direi che è qualcosa di cui essere consapevole, ma sono sicuro che hai altri problemi più urgenti.

Sarà interessante sapere cosa pensano gli altri.

Non confondere le interfacce server con le interfacce interne

Il client interagisce con il server e scambia i dati in base all'interfaccia pubblicata per quel server. Ciò che il server fa per creare quei dati non ha importanza per il client e il server non deve inviare dati indesiderati o inutili che riguardano solo il server.

Mentre il server gestisce un oggetto interno chiamato FooObject e invia FooObjectSummary . I due in realtà non sono la stessa cosa. Uno è un modello di dati interno correlato all'archiviazione del database e l'altro è una risposta di comunicazione da inviare al client.

Se modifichi i nomi delle classi, le cose iniziano a diventare più chiare. FooObject è rinominato in FooModel e FooObjectSummary è rinominato in FooResponse . Ora centralizzi il codice in modo che solo FooModel venga utilizzato per creare un FooResponse .

 class FooModel
 {
      public FooResponse getResponse() {....}
 }

Ora puoi documentare che il server invierà solo oggetti di risposta per richiedere dati.