I'm working on a small application where I need to model tables and columns from a relational DB.
I've been reading some material on nested classes, which is recommended to be used sparsely. However I'm thinking that this might be such a scenario.
I wish to implement these objects as follow:
1. Table
contains List<Column>
2. Preferably it is not possible to create a Column
object unless you use a method on the Table object (eg Table.addColumn()
).
3. Existing columns should be available outside the Table object in such a way that you may reference the column and it's public methods and properties from anywhere in your code.
4. Column
must know of the Table
object it belongs to.
5. Both Column
and Table
implements IEquatable and maybe IEnumerable.
The options I see are:
1. Use nested classes where Column
is enclosed in Table
, protecting the constructor of Column
from being called by external code.
2. Implement Column
and Table
as regular classes, injecting the Table
object into the constructor of Column
. This could be handled by a method in the Table
object taking care of the "injection" and returning the resulting Column
object. This does however, expose the constructor of Column
to the rest of the implementation.
3. Create a separate DLL combined with the Internal access modifier to protect the Column
constructor.
What would you say is the best solution here?
Cheers