Come prevenire più classi per lo stesso oggetto business?

Question

Molte volte avrò un oggetto Business che ha una proprietà per un indice utente o un insieme di indici per alcuni dati. Quando visualizzo questo oggetto in un modulo o in un'altra vista, ho bisogno del nome completo dell'utente o di alcune delle altre proprietà dei dati. Di solito creo un'altra classe myObjectView o qualcosa di simile. Qual è il modo migliore per gestire questo caso?

Per chiarire ulteriormente: Se avessi una classe un tracker di problemi e la mia classe per un problema avesse IxCreatedByUser come proprietà e una raccolta di valori IxAttachment (indici per i record degli allegati). Quando lo visualizzo su una pagina Web, voglio mostrare John Doe invece di IxCreatedByUser e voglio mostrare un collegamento all'Allegato e il nome del file sulla pagina. Quindi di solito creo una nuova classe con una raccolta di oggetti Attachment e una proprietà CreatedByUserFullName o qualcosa del genere. È semplicemente sbagliato creare questa seconda classe per visualizzare i dati su una pagina. Forse mi sbaglio?

Answer 1

Il motivo della facciata.

Penso che il tuo approccio, creare un modello di facciata per astrarre le complessità con più origini dati sia spesso appropriato, e renderà il tuo codice facile da capire.

Bisogna fare attenzione a creare troppi strati di astrazioni, perché il livello di indiretta rovinerà il tentativo iniziale di rendere più facile la lettura del codice. Soprattutto, se senti di scrivere solo lezioni per abbinare ciò che hai fatto in altri posti. Ad esempio se hai un myLoanView, non devi necessariamente creare un myView per ogni singolo dialogo nel sistema. Fai 10 passi indietro rispetto al codice e magari crea una facciata che è un'astrazione riutilizzabile e intuitiva, che puoi utilizzare in diversi punti.

Sentiti libero di elaborare l'esatta natura della tua sfida.

Answer 2

Un principio chiave è che ciascuna delle tue classi dovrebbe avere uno scopo definito. Se lo scopo del tuo "oggetto business" La classe deve esporre i dati rilevanti relativi all'oggetto business, può essere del tutto ragionevole creare una proprietà sulla classe che delega la richiesta per la descrizione della ricerca alla classe correlata responsabile di tali informazioni. Qualsiasi formattazione specifica per la tua classe verrebbe eseguita nella proprietà.

Answer 3

Ecco alcune linee guida per aiutarti a decidere come gestire questo modello (abbastanza comune, IMO):

1. Se tutto ciò che serve è un collegamento rapido a una tabella di ricerca che non cambia spesso (ad esempio una tabella di indirizzi che si collega a una tabella di stati e / o paesi), è possibile mantenere un caricamento lento , copia statica della tabella di ricerca.

2. Se hai una classe davvero grande che richiederebbe un sacco di join o sottoquery per il caricamento solo a scopo di visualizzazione, probabilmente vorrai creare una "visualizzazione" o " info " classe per scopi di visualizzazione come hai descritto sopra. Assicurati solo che la classe XInfo (per la visualizzazione) si carichi molto più velocemente della classe X (per la modifica). Questa è una situazione in cui l'utilizzo di una vista sul lato del database può essere un'ottima idea.