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:
2. Preferably it is not possible to create a
Column object unless you use a method on the Table object (eg
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.
Column must know of the
Table object it belongs to.
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.
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
Columnobject. 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
What would you say is the best solution here?