First let me start by saying that I am just getting started with OOP
and Domain driven design so please take it easy on me.
I am designing a domain model that consists of PROJECT objects that can
contain ISSUE objects that can contain other objects like NOTES and
ATTACHMENTS. There will be times in which my application will need to
populate each PROJECT object along with all related child objects.
However, sometimes I just need to get a list of PROJECTS to fill a
dropdown or list UI control. In this case I just need some basic
PROJECT properties like name and ID. I think it would be too much
overhead if I populated all child objects just to fill a list
(especially if there are many PROJECTs).
Shoud I create 2 separate PROJECT objects for this or is there any
design patterns that I can inject into the PROJECT object to tell it
not to load child objects Hopefully I'm explaining myself correctly.
I know this is a "Newbie" question but I am reading many books and just
cant find some solid guidance or examples of this.
Thanks!
eric
Objects with many child object relations - Need design help!
dczraptor
Basically, the class has a flag, and it uses that to read the properties from the data layer, when you attempt to access them for the first time.
Ryan Garaygay
Thanks Diego,
You are the first person to reccommend an XML approach to solving this problem. I will review the links you sent.
KADIYALA
Eric,
the possibility I will tell you is a little tricky to understand in the beginning, but then is pretty easy to apply
.NET 2.0 allows you to serialize object graphs as XML documents (streamed representation of the object graph). In your case, PROJECT would be the root node of the graph (and the XML)
The API that does this is System.Xml.Serialization and it’s for free: If your object has a property called Xyz, the PROJECT node in the XML will have an attribute with the same name (eventually, it could be a child node if you like)
The same API is able to deserialize XML representations in a graph of objects. Again, straightforward
The fact is that current databases admits XML as input and/or output parameters in stored procedures. In the particular case of SQL Server 2005, you can extract the different child nodes from the XML (ISSUE, NOTES and ATTACHMENTS) in order to update the respective tables. What allows you to make queries straight from XML streams is SELECT ... FROM OPENXML command
In a similar manner, you can retrieve data from the database back to the application in XML format (in order to apply then deserialization, getting the object graph back). The command is SELECT ... FOR XML PATH. Because ISSUE, NOTES and ATTACHMENT are child elements, you can nest SELECT commands accordingly
Now, your question was about having two definition of PROJECT class, one with children, the other one without. My suggestion is "not". Just have one definition, but in those use cases that will need the whole graph, call a stored procedure in the way I depicted. In the remaining use cases you don't need the children, call another stored procedure that doesn't nest children subselects: the application will receive the XML with just the root element (PROJECT). When deserialization is applied, it's just that missing nodes aren't deserialized, so child objects won't be available
In certain way you are solving with XML support in the database and serialization capabilities in the CLR the impedance mismatch. Object/Relational mappers like NHibernate act in that manner but are not so easy to configure. For instance, if you declare in NHibernate that ISSUE should be lazzy loaded, then when you need an eager loading of ISSUE you have to apply alternate mechanisms
Also, O/R mappers usually don't support stored procedures, so they act at a record level, issuing a round trip to the database to store every ISSUE, every ATTACHMENT, every NOTE... That could derivate in poor performance
The mechanism I suggested, based in XML interchange, solves every PROJECT+children retrieval / storage in one round trip (the DBA will love you, I promise)
Hope it helps
Octai
Thanks, it would be great to know your opinions after reviewing
I apply such solution and it works fantastic in my case. I want to know if I'm not considering special scenarios
Jason D. Camp
So basically the Project object should have some property to help the persistence layer determine how to load its data Or should the persistence layer take in a parameter to help make this decision
ProjectCollection = ProjectFactory.GetProjects(False) 'this would be like LoadChildren=False
JPShaver
Some useful links
Introducing XML Serialization with Examples
http://msdn.microsoft.com/architecture/default.aspx pull=/library/en-us/cpguide/html/cpconintroducingxmlserialization.asp
http://msdn.microsoft.com/architecture/default.aspx pull=/library/en-us/cpguide/html/cpconanexampleofxmlserializationwithxmlserializer.asp
About retrieving XML data from SQL Server 2005
http://msdn2.microsoft.com/en-us/library/ms189885.aspx
Extracting info in SQL Server 2005 from XML (OPENXML)
http://msdn2.microsoft.com/en-us/library/ms175160.aspx
http://msdn2.microsoft.com/en-us/library/ms186918.aspx
Eric Lee
Make your project object lazy initialise itself, and have two db calls, one for the core info, and one for the extra info. Then when you create a project object, it won't bother to find out the information that you never ask for.