So, I’ve just hit a snag. It’s not a big snag, but it’s somewhat fundamental. I was happily going about my business. I’d gotten the Browse module up and running that was going great. I was about to start in on the Add or Voting module. In order to do this one, I’m going to actually need an implementation of the IGameService to exist. I hadn’t forgotten it, but I didn’t want to get mired in it until I had Browse up and running, since Browse didn’t really need it.
When I went to implement IGameService, I came to two conclusions very quickly.
The first was that a lot of the infrastructure for HollywoodService really is the same as the Game Service. For the Entity Framework implementation of those two services, they’ve very tightly linked. This lead me to rename the HollywoodService to be the CombinationService (I could have named it the EntityFrameworkImplementation) and had that single class implement both interfaces. This allows me to do the actual initialization work once and share a context between the two different implementations easily.
The second (and less happy) conclusion was that I had an identity crisis. As I was looking how to implement methods like Guess() where the database requires IDs, I was doing a lookup for each parameter to look up the entity by name to get its ID to insert into the database. I considered for a moment adding an ID field to the business classes, but that really puts a burr in my saddle (I live in Denver, we’re required to use a Western idiom once a week). The addition of an ID is really an implementation concern and shouldn’t be exposed out through the interface, however, it’s darn convenient to have it there. After 5 minutes of biting my lip, I fell back on an idea that a co-worker had come up with about a year ago. We have a conceptual data model at work and objects to represent the conceptual data types (classes representing columns, tables, etc.). There were pieces of information he wanted to store that he needed to know, but didn’t want expose out as part of the interface. For a couple of weeks we explored re-inheriting the types off of DependencyObject so that he could use attached properties to store the data. Not part of the interface, stored wtih the object, GREAT! We had backed out of that path because of some of the threading issues around DOs on in an MTA, but in a rich-client application, this should work well.
So I’ve rebuild the business objects to be full-fledged DOs, this will also help with data updates in binding situations, so it’s a double-benefit.
As a side-note, I find that every once in a while, I trip over something that’s just … wrong. Today, it’s that I can’t seem to find the WPF snippets in my installation of 2008. The workflow definition is the there, but that means that I’ve got to use the snippet and then change it every time and that’s just WAY too much effort. So, I salute Dr. WPF and his repository of snippets for making my life a pleasure again.
At this point, I tripped on a small design flaw. It seems that LINQ to Entities has problems understanding attached properties. I tripped into this based off of how I was reconnecting objects in the business tier after having gotten them out of the database in the services. In several cases I had two real entities that had a join table between them (occasionally with some data hanging off of it). My loading order was to load and objectify the entire entity system (it’s really small) and then tie the business objects representing those entities together. So, my approach was to iterate one of the entities to be tied, look it up in the join table and then get the equivalent entries from the other entity. This required direct pulling of the attached property of the first entity and several cases and just became unworkable. What does work, is to iterate the join table and then do lookups from the business objects based off of the attached IDs.
With a fair amount of giggling, mostly around getting the “double down” feature to work, I now have voting working. Two down, one to go before styling starts.