Hierarchical domain object creation not SOLID
-
I have a project where the data is intended to be hierarchical in nature. The obvious solution seemed to be to create a hierarchical set of domain objects: when you instantiate the root object (with its key) it goes to the database to get its properties and a list of children. It then instantiates a child object for each and maintains them in a collection. As each child object is instantiated the process repeats itself recursively. All well and good. Except it doesn’t follow the principles of SOLID: these domain objects contain data access code. What is the correct design (or design pattern) here? - Do I ignore SOLID in this case? - Have a parallel hierarchy of data access helper objects (one for each domain object)? - Do I keep all the data access code in the object that created the root domain object (ensuring it is thread-safe) and reference it from the domain objects using callbacks? - Encapsulate the data access code in a thread-safe singleton helper? - Is my basic approach flawed? - Something else? (The database hasn’t been designed yet, and the domain objects will need to be able to save changes ... more data access code. These domain objects will be accessed a number of ways including via a treeview in the UI.) Surely this is something that must have come up many times before.
-
I have a project where the data is intended to be hierarchical in nature. The obvious solution seemed to be to create a hierarchical set of domain objects: when you instantiate the root object (with its key) it goes to the database to get its properties and a list of children. It then instantiates a child object for each and maintains them in a collection. As each child object is instantiated the process repeats itself recursively. All well and good. Except it doesn’t follow the principles of SOLID: these domain objects contain data access code. What is the correct design (or design pattern) here? - Do I ignore SOLID in this case? - Have a parallel hierarchy of data access helper objects (one for each domain object)? - Do I keep all the data access code in the object that created the root domain object (ensuring it is thread-safe) and reference it from the domain objects using callbacks? - Encapsulate the data access code in a thread-safe singleton helper? - Is my basic approach flawed? - Something else? (The database hasn’t been designed yet, and the domain objects will need to be able to save changes ... more data access code. These domain objects will be accessed a number of ways including via a treeview in the UI.) Surely this is something that must have come up many times before.
If you implement the children objects as interfaces (and you should, for the D in SOLID) then you can just leave them as placeholders until they are accessed in the tree. I have also worked on a couple projects where you push an IDataAccessSomethingOrOther into a presenter or controller layer. As the view events are raised that require loading, methods on the IDataThingyIMentionedEarlier are invoked by the presenter/controller that would load those child objects up. My advice would be to keep your data out of your model objects. Cheers,
-
If you implement the children objects as interfaces (and you should, for the D in SOLID) then you can just leave them as placeholders until they are accessed in the tree. I have also worked on a couple projects where you push an IDataAccessSomethingOrOther into a presenter or controller layer. As the view events are raised that require loading, methods on the IDataThingyIMentionedEarlier are invoked by the presenter/controller that would load those child objects up. My advice would be to keep your data out of your model objects. Cheers,
-
Really? :doh: Are you seeing it wrapped across the forum page? Maybe I'm seeing it wrong, but I think I contributed to part of the answer. :confused:
-
Really? :doh: Are you seeing it wrapped across the forum page? Maybe I'm seeing it wrong, but I think I contributed to part of the answer. :confused: