I ran into a curious situation today.  The database I’m working with primarily has lots of big, horizontal entities, which is fairly common for any schema that’s been around for several years.  It’s main consumer is a series of WinForms applications that rely heavily on grids for displaying data.  Since most of the grids don’t need to show every column of every entity they are displaying, there are several versions of entity projection classes in different namespaces of the existing framework.  I’ve found these frustrating, since they often don’t have everything that I need for the behavior I’m attempting to produce.  Yet these classes exist in the data access layer, along with the actual entity objects.

I was working on a set of forms for searching and displaying information on various entities, and when I started a new form, I realized that the initial search display was exactly the same as a form I had just created.  Obviously (much to my chagrin, more on that another time), it was time for a user control.  I grafted the controls into my new user control, started working on refactoring the code, and then sat back, stumped. 

In my opinion, a user control should really only be created if it is going to be re-used by different containers that require the same behavior for part of their purpose.  This particular control had a DataGridView in it that worked with an entity projection class.  The entity projection itself was in a separate namespace in the same project, since, at the time I created it, I believed that it’s sole purpose was going to be for use on the original form.  Now that I was looking at a user control, the projection became theoretically necessary on a larger scope than the original assembly, along with the control itself. 

Hence my stumpage.  Where do I put the projection and the corresponding query?  Hell if I want to be the guy violating DRY.

I considered the data access layer, but only for a few minutes.  The query for the entity along with the projection itself, though they might be re-used at some point, were behavior driven elements; part of the business logic. 

Then, I thought about creating a business logic assembly that would house both the user control and the logic.  This was more appealing, at first, because it seemed to keep things that should be separate separated.  But then I remembered the existing framework, and how these entity projection classes and the stored procedures used to load them kept getting changed, massaged, and bloated to represent 42 different things.  Not at all what I wanted. 

The truth of the matter is that the user control has a single responsibility: to search for an entity in a certain way and present the results in a certain way.  Might other applications down the road need to do this same thing?  I don’t know right now, and right now it doesn’t matter.  What matters is that the code that is required for this control doesn’t belong anywhere else.

So, I’m moving the projected entity class, the compiled query that projects it, and all of the calling code into the user control itself, which will then simply need a data context to work with.  Did I do the right thing in the long run?  Maybe not.  But even if this control needs to be used by another application in the future, it will be a simple, wholesale move to a separate project, rather than another application architecture decision. 

Projections are business logic.  Attempting to maintain several sets of projections for use by different projects is a no-win proposition.  The entities themselves change over time, hence the use of projections in the first place.  Maybe two applications will need very similar entity projections, but attempting to predict this leads to over-abstraction and accidental complexity. 

No, it’s not because I’m trying to win a Windows Phone 7.  Well, maybe it’s partly because I’m trying to win a WP7.  Most everyone knows that I tend to drink the Microsoft Kool-Aid, but today, along with word of the WP7 lineup from AT&T, I have had an experience that made up my mind.  When I can afford it, I’m getting away from Apple all-together.

Waaaay back in the day, I had a POS Motorola phone with Windows Mobile 5.1.  I didn’t really mind the phone all that much, but there were some basic things about it, and the operating system, that made me mad.  I switched to BlackBerry, and as much as I loved my Curve, the sexiness of the iPhone finally won me over.  This past January, the family all got iPhones, and aside from some basic compatibility problems with Google that ironed themselves out (except for the Voice app, which I wouldn’t use anyway), we’ve all been pretty happy with it.

Until today.

I play guitar.  My instructor gave me a great drill for learning different scale positions for different notes.  It involved a bunch of flash cards in two or three different “hats,” and based on which cards are drawn, you do different things on the guitar.  I love this kind of stuff.  After fumbling around with pieces of paper and beat-up golf hats for a while, I realized that this drill would be a simple program to write.  So I wrote it in WPF, which took me all of about half an hour (not counting image creation), and it works great.  But lugging my laptop around with me whenever I want to practice guitar is, well, a PITA, so the obvious thing to do would be to write a phone app. 

After contacting my Mac-Whore (we all have one), I figured out that the SDK is not only not free ($99), but it won’t run on anything except a Mac.  My MacBook bought the farm last year and I never really liked it enough to buy another one, so I am Mac-less.  So now if I want to build an app, I would have to “Hackintosh” my laptop with another partition for OS-X, which I would use only to write a single iPhone app that I really don’t care if anyone else uses except myself.  And there’s another problem: if/when I actually develop the app, I wouldn’t be able to put it on my own goddamn phone.  It would have to go through the craptacular App Store approval process.  In summary, I would have to:

1. Pay $100 bucks for an SDK I’d probably only use once.
2. Buy a Mac –or- possibly break the law hacking my computer so it could run OS-X.
3. Buy OS-X.
4. Spend the time getting the Hackintosh set up.
5. Learn Objective-C.
6. Write the app and submit it to the App Store Approval Process.
7. Wait for them to tell me it’s OK to install it on my phone.

Now, to be fair, I don’t know Java either, but I’ve messed with Eclipse before, and from all accounts I’ve heard, Android is quite easy to work with.  Easier still, WP7.  I remember coding a Windows Mobile app and throwing it on my crappy Motorola in about 15 minutes once.  No big deal, because it’s my phone, and if I want to write a program for it, I should be able to. 

So I’m throwing in with Windows Phone 7, and I hope I win one with the little image above.  If not, and if it lasts longer than Kin, I’ll be deciding between WP7 and Droid for my next phone.  Apple the evil empire has lost what little support I still gave it.

Note: I just realized that you have to pay $99/year to submit apps to the WP7 Marketplace (unless I'm wrong), so I guess it ain't so bad to pay $99 for iPhone App development.  Wait...except you can't even get the SDK from Apple unless you pay the $99, whereas I just got the WP7 SDK for free.  Either way, full disclosure, apparently we could create the awesomest thing ever, and in order for either Microsoft or Apple to distribute it, we'd have to pay them.