I am attempting to create an application that will allow me model a set of relative objects in memory and then drill in to the model from various dimensional starting points. Logically, I have a root object that has a number of collections of other objects, sort of a container for all the objects. Many of the child objects also have relationships to one another.
I get that CSLA is not and ORM, and what I am looking to create is a sort of specialized ORM. One of the things that sets this apart from a standard ORM is that I need to select data from two different models but only write to one. I am trying to create an app that will consume and document the data from another app. Users should be able to query the various collections of data, see the relationships, compare them to one another and then save information they have gathered.
So...
I don't want advice on creating an orm. I want design advice on whether this sounds like a proper candidate for CSLA objects.
I need a root object that contains multiple collections.
The items in each collection may themselves have/be collections.
Items in one collection may relate to items in another collection.
I don’t want to populate the entire hierarchy of objects at application startup. I would prefer to lazy load items in the hierarchy as needed.
I want to save entire collections or individual items in a collection as needed.
I want to be able to compare collections to one another.
Would these needs be well served by using CSLA objects to define the hierarchy of collections? Should I consider a POCO implementation instead?
If you do think this is a good fit for CSLA objects, how would you go about designing an object with a list of other objects that might in turn contain lists and for which you might sometimes wish to save in batches and other times just save information about single nodes?
I apologize in advance for the rather abstract nature of this question. I am struggling rather mightily with this design decision. I appreciate any comments folks migh wish to share.
From your description it sounds like the data is read-only - for analysis?
If so, then you can probably use the read-only object and list stereotypes.
This multiple-reference-to-objects scenario only gets complex if the objects are editable, because the various data binding and edit level implementations start to conflict - BB and BLB make certain assumptions about objects having exactly one parent.
But read-only objects aren't undoable and don't support all the edit-related data binding constructs, so they aren't subject to the same limitations in this regard.
The source data is read only, but then I want to be able to persist some fields from the source into a second database with a schema of relative tables created for my app, and then I want the ability to keep aspects of the the two in sync based on the results of analysis.
All the objects do have one real parent each, but they can also be represented in relation to other objects in ways that make them look like a child. Similar to the database concept of a referential integrity constraint. Tables have columns, but a constraint can also "have" some of the same columns or a view can make use of those columns. These other objects also have a parent relationship to those columns, owning them as children. Truely the columns really belong to the table, taking up data page space within the extent reserved for that table, but other objects still can be represented as the parent of column.
These are similar to my situation.
I'll try to move forward with CSLA objects since I have moved a fair way down that road already. But i'll have to think hard about which stereotypes to use and where. Thanks for your reply. It wasnt really a fair question in the first place since you have no clue what i am really trying to build.
Copyright (c) Marimer LLC