Starting with an Entity Framework Model that is a facade in front of a recursive, self referencing parent/child SQL Server table ...
I've built a data access function that generates a single hierarchy/result set that is -- for example -- tree of locations Country / State / Region / Destination / Neighborhood for one app...
C# data access layer then scrubs that hierarchy to generate an XML tree that can be retrieved via WCF.
This eliminates the need for the conventional CSLA multi-result set approach for "hydrating" parent/child business objects.
I've taken a break from developing CSLA BO's, but am coming back now to get up to speed with using the framework for .Net 3.5 and Silverlight for this application.
Now that I can get the whole tree back in hierarchical order with one call .. and do not have to write queries to retrieve each level of the tree ... I want to be able to create a parent/child/grandchild/nChild business object .... essentially a tree at runtime without having to code named business obects for each Node/Branch.
Am I breaking new ground here or is there a known approach for creating a set of "deep-data" business objects where the graph of the hierarchy is not known at design time ?
A CSLA pattern that follows the functionality of a composite pattern or the type of functionality that I am using to create the tree using XElement objects ??
Are you planning to somehow dynamically inject business, validation and authorization rules into these objects as they are defined/created? I'll assume not.
In that case, why woud you want to use CSLA at all? CSLA is all about creating a rich business layer defined by behavior. If you want an entity model defined by the shape of your data there are other frameworks that at least do that statically, and perhaps at runtime.
all nodes at every level have the same attributes [GUID_id, Guid_Parent, Description, HierarchyLevelID (foreign key) ] in the database / EF model ... (And XML Element names of "Hirearchy Level Label" ie <Country> and <State> below:
then there are the tree definition properties that are generated by the CTE that "manufactures" the tree ...
Even with this common interface for each node, no hooks in the framework for a factory to create a n-level tree at runtime ??
There will certainly be a need to validate that a each node has a parent appropriate for it's level in the tree for create/edit ... but, again ... the "behavior" for each node is common.
And I certainly want to render the tree in a Silverlight UI from A BO that -- preferably could have a runtime determined number of n-childs --
Go Saints !!!
Copyright (c) Marimer LLC