Sto lavorando su una piccola applicazione in cui ho bisogno di modellare tabelle e colonne da un DB relazionale.
Ho letto materiale su classi annidate, che si raccomanda di usare scarsamente. Comunque sto pensando che questo potrebbe essere uno scenario del genere.
Desidero implementare questi oggetti come segue:
1. Table contiene List<Column>
2. Preferibilmente non è possibile creare un oggetto Column a meno che non si utilizzi un metodo sull'oggetto Tabella (ad esempio Table.addColumn() ).
3. Le colonne esistenti dovrebbero essere disponibili al di fuori dell'oggetto Table in modo tale che sia possibile fare riferimento alla colonna e ai suoi metodi e proprietà pubblici da qualsiasi punto del codice.
4. Column deve conoscere l'oggetto Table a cui appartiene.
5. Sia Column che Table implementa IEquatable e forse IEnumerable.
Le opzioni che vedo sono:
1. Utilizza classi nidificate in cui Column è racchiuso in Table , proteggendo il costruttore di Column dall'essere richiamato da un codice esterno.
2. Implementa Column e Table come classi regolari, inserendo l'oggetto Table nel costruttore di Column . Questo può essere gestito da un metodo nell'oggetto Table che si prende cura dell'iniezione e restituisce l'oggetto Column risultante. Ciò tuttavia, esporre il costruttore di Column al resto dell'implementazione.
3. Creare una DLL separata combinata con il modificatore di accesso interno per proteggere il costruttore di Column .
Che cosa diresti sia la soluzione migliore qui?
Saluti