Oggetto modello e attributi aggiuntivi

Question

Oggetto modello e attributi aggiuntivi

#1 da (5 voti)
#2 da (1 voti)

3

Ho un modello per es. %codice%. Oltre agli attributi "naturali" di un libro, ho alcuni ID obbligatori che devo portare avanti, come Book , companyId . Sono correlati a quale unità organizzativa appartiene questo libro.

Ora, vedo questi due flag come qualcosa che non fa parte dell'interfaccia groupId . Poiché tutto il lavoro con un libro è fatto nel contesto di un'unità organizzativa. In altre parole, l'unità organizzativa è sempre nota per ogni operazione là fuori. Tuttavia, abbiamo bisogno di memorizzare questi dati nel database e averli nel modello (anche per altri moduli).

[A] dovrei inserire questi attributi in Book ? Quindi diventano flag obbligatori e devono essere impostati nel costruttore di Book . Significato, ho bisogno di impostarli ogni volta che creo un libro. Che in qualche modo non mi piace, in quanto questi campi appartengono alle unità organizzative, di cui Book non dovrebbe sapere nulla.

[B] Devo inserire questi attributi in qualche "contesto locale del thread Book Book" non può essere usato senza il thread locale, e questa dipendenza tecnica non è visibile dall'esterno.

[C] Posso memorizzarli nei campi ? Then , ma non esporli all'interfaccia Book . Tuttavia, quando invio Book ad un altro modulo, quel modulo deve essere a conoscenza di questi ID. Dovrei usare la riflessione - ma poi, devo essere sicuro che i campi abbiano lo stesso nome.

Quindi mi chiedo se sia possibile in qualche modo avere questi campi con Book ma non diventare parte dell'interfaccia Book .

architecture object-oriented-design

posta lawpert 27.10.2014 - 11:24

fonte

2 risposte

1

L'hai detto tu stesso, c'è un qualche tipo di contesto, in cui ogni libro è gestito. Questo OrganizationContext potrebbe essere una classe. E ogni volta che carichi o salvi un libro, questa classe lo sa e può fare la propria logica su quel campo. Inoltre, per rendere l'accoppiamento più flessibile potresti avere l'interfaccia HasOrganizationContext per rappresentare quegli ID e consentire a entità diverse di appartenere a questo contesto e non solo ai Libri. Quindi, altri moduli potrebbero conoscere questo contesto, ma non è necessario conoscere il libro stesso.

Inoltre, se usi C #, puoi utilizzare l'implementazione dell'interfaccia esplicita per "nascondere" i campi dalla vista, rendendoli ancora visibili a chi conosce l'interfaccia.

risposta data 27.10.2014 - 12:07

fonte

Leggi altre domande sui tag architecture object-oriented-design

Gestione delle modifiche al codice in questo ambiente di codifica Come tenere traccia del codice sicuro del thread in una base di codice C ++ Rich Legacy per lo più thread non sicura

score 5 · Accepted Answer

I testi introduttivi sulla progettazione orientata agli oggetti si concentrano sempre su questi oggetti "naturali" che sono modellati dal codice. Questo, penso, di solito è un errore e provoca molta confusione quando si tenta di implementare un'architettura, dal momento che si sta tentando di modellare la cosa sbagliata.

Un'architettura orientata agli oggetti si occupa di tipi e classi nel dominio problematico della soluzione . Se stai costruendo un'applicazione per il monitoraggio dei libri, potresti non essere interessato a molte qualità "naturali" di un libro, come il carattere tipografico in cui è stampato o le condizioni della colonna vertebrale, ma piuttosto quelle qualità che sono rilevanti per la tua applicazione - il suo nome e autore, certamente, ma forse anche il suo proprietario e la posizione corrente, entrambi rilevanti per l'entità Book nel contesto del tuo dominio, anche se non fanno parte di un ideale platonico di un libro.

Quindi, dico, vai avanti e aggiungi proprietà come CompanyId al tuo modello Book , se è l'entità pertinente che stai cercando di modellare. Se questo sembra stonare, smetti di chiamarlo Book - chiamalo ManagedBook o TrackedBook , e improvvisamente vedi che quelle proprietà hanno senso.