Domain Objects and/or DataSets
I've been thinking recently about how I might approach the development of a completely new version of Comicster.
Right now, Comicster uses an in-memory typed DataSet to store your collection, and when you save, it streams the DataSet (using WriteXml) to a compressed file on disk. That system works really well, but ideally I'd like to move away from DataSets internally and come up with an object model, making use of .NET 2.0's (and WPF's) object binding.
So I've thought about all the various classes this hypothetical new program might have: Folder, Title, Issue, Character, Creator etc. No problems there. But then I started thinking ... each issue has a cast of characters. Likewise, each "team" (eg X-Men) also has a list of characters. How many times would I want the same character (eg Wolverine) instanced in memory? Ideally only once. That means that I either have to have object references all pointing back to the same instance of Character, or I have to use a field like CharID and look the character up in a global list of characters.
The latter approach, however, is exactly what my typed DataSet does - it stores a bunch of in-memory 'tables', and each 'row' has foreign-key references to other 'rows'.
So I'm kind of back to square one. Unless ...
What if I used a typed DataSet as an internal storage mechanism, but only ever surfaced objects to the UI? Like, have some sort of Collection object with methods that enumerate titles or characters, returning them as instances of my domain objects, but internally it's constructing these objects from the same tables that I've always used?
I wonder if that could work. I wonder if there's any benefit to doing it that way. Certainly the idea of wrapping all of that up into its own satellite assembly and having the UI know nothing about DataSets sounds intriguing.
What do you think? How do you represent your domain objects in memory?
Comments
# Paul Stovell
18/10/2006 1:14 AM
Hi Matt, I was just catching up on your blog tonight and noticed this post. I actually just posted something on this very topic - "DataSets versus Objects" - http://www.paulstovell.net/Posts/Post.aspx?postId=6ba6fe72-dbeb-488a-9416-a31c68942656
In Trial Balance I take a very Domain Object approach. The UI is bound to the Domain Objects, and the Domain Objects are populated via data providers.
Seperating your logic from your UI has huge advantages. Don't feel as though DataSets are your only option.
# mabster
18/10/2006 6:51 AM
Thanks for that, Paul.
A question, though: Does Trial Balance use some sort of back-end database to store its data? Like Sql Express or Sql Everywhere?
I ask because Comicster doesn't. The only persistence layer is when the user clicks File|Save and the whole in-memory collection is serialized to disk. That's why I'm concerned that an object-based approach might not work - I'd either end up with multiple copies of the same data in memory, or I'd get circular reference errors trying to serialize, like this:
http://www.madprops.org/cs/blogs/mabster/archive/2006/09/18/Circular-References-During-Serialization.aspx
What do you think?