Repository Pattern Hell (Part 3): Enlightenment

Modern object relational mappers have come a long, long way since the dark days of writing DataTableAdapters, CRUD stored procedures, or worse inlining dynamic SQL strings. In fact, they are so good now and come packed with so many fancy features it’s almost surprising people are still hung up on using the same old generic repository pattern that abstracts it all away and aims for the lowest common denominator.

Repository Pattern Hell (Part 2): Wish List

It’s cathartic and whiny and all to bemoan the repository silliness as I have, but what about a real alternative? What is one supposed to do? Is there a better way? I’m glad you asked that!

Repository Pattern Hell (Part 1): Disillusionment

The older I get the more I dislike the oft venerated Repository Pattern — at least as it is usually implemented and suggested. In fact, I’ve gone through just about every attitude, from ignorance, indifference, mild interest, eager learner, ardent supporter, frustrated friend, disillusioned, and now to somewhere close to outright disdain. Yep, I’ve become a hater, which isn’t something I like to be about anything… but here I am.

The Developer’s Duty

Android has an file system browser app. Windows Phone and iOS do not.

Working hard versus working smart

It isn’t every day that I get one of those moments of clarity. (Actually, if you’re a recruiter/interviewer reading this, that’s just narrative hyperbole! I get epiphanies, like, hourly. Yeah. Hire me.)

I’ve been tasked lately with some rather… interesting… problems at work. Really the circumstances around them drive me nuts and will have me bald from ripping my hair out but I can’t and won’t get into that here. I’m having to generate a lot of records to be imported into this other system as a sort of systems integration thing. Due to the fundamental differences in their database structures, it involves a lot of redundancy.

It also involves a lot of Cartesian products. What we would normally implement as a pair (or more) of drop-down lists to pick from we’re having to store as related elements. Allow me to illustrate with a contrived example.

Dynamic Data: to a faster, more featureful future of releases

We’re (read: me and the sole intern) making a big push to impress internal clients (read: other employees) and my boss and her boss with some of the newer technology and features available in .NET 4.

WCF: pilot license required

Listening to this Hanselminutes yesterday, I heard some great stuff from the always sagely Glenn Block on WCF. He’s apparently moved to that team (after working on MEF) to do something called Web API.

His analogy of WCF to a Boeing 747 cockpit had me fist pumping in shared understanding. I’ve spent enough painful hours flipping switches and knobs hoping for that one combination that will make it work, half the time not really knowing fully what I’m doing. It really did feel like being sat in front of the controls to a commercial aircraft and told “Okay, make it take off.” A seemingly simple, everyday thing for a plane to do, and it probably only takes a few flips of switches and a gentle movement of the controls to do it, but knowing which out of dozens of instruments will do it… well…

The sheer cliff of a learning curve with WCF has always put a sour taste in my mouth. RIA Services is wonderful if what you really want is just a data source for, say, your Silverlight app, but for anything else it’s not so helpful.

And as soon as you need to set up service credentials/certificates and/or a security token issuer and other “advanced” stuff it really starts to hurt.

That and there’s no way to encapsulate stuff into helper assemblies since so much of it must be done in the config file and referenced assemblies can’t have their own config info.

Enforcement via necessity

At work we’re about to begin a new project. Aside from the thrill of starting something new, we’re also going to try a new (for our team at least) development methodology: agile development. With the iterations and user stories and everything.

Admittedly, it’ll just be two of us including myself but it’s a start on the path to modernizing and I’m certainly down with getting more familiar with industry proven strategies. It’s good for my career and I agree with a lot of the principles. I can’t say the same for some of the others I work with, though; in fact, the further we get along with this and the more we fold others into using it, I can foresee a few being dragged kicking and screaming. Some just want to show up at 8am and leave at exactly 4pm.

We’re going to be using the latest and greatest Team Foundation, SharePoint, Visual Studio, and Expression Studio. We’re going to use .NET 4, WPF, and MVVM. In all likelihood we’ll probably also use MEF as a simple and easy dependency injection container. I’m certainly looking forward to it.

I haven’t seen it in practice yet (since we haven’t started just yet), but it seems to me that a nice bonus of using inversion of control, dependency injection, and the model view viewmodel patterns is that they almost fit in perfectly with agile. Breaking things up into tasks (based on user stories) and iterations fits great with an application built incrementally. Using interfaces and injecting dependencies means we can have a lot of “ghost” services that seem to exist but have no substance. We can then write a lot of the application parts discretely and as a team without too much stepping-on-of-toes, and just plug in the missing parts as we fulfill tasks.

Not surprisingly, one of the best ways to enforce something is to make it a necessity. By choosing these patterns it seems like it will help a lot as far as keeping us true to the agile method, mostly by reducing the friction between the development method and the design methods. It’ll be like choosing to park in the furthest spot from the office everyday to necessitate a bit of daily walking exercise.

Switching to a new development approach can be a big upset for teams, even if they’re enthusiastic about trying it (as I am). Even going into it positively, I’m still going to face a lot of “getting used to” things and learning as I go. That’s not hard in of itself but it’s an overhead cost when your real goal is to develop software since the learning curve will eat into your coding time and efficiency. Still, I think it’ll be worth it.

I’m endeavoring to write more on agile, design patterns, and the technologies as we use them.

When underwhelming is a good thing

I'm always a bit astonished at my unastonishment upon finally trying out some new Microsoft three-letter acronym*. I suppose I should be used to it by now, but the experience never fails to be peculiar.

These new-fangled technologies, patterns, or what have you always start out as these nebulous and ethereal things tossed around in typical techno-babble jargon fashion. "I suggest using an MVVM pattern with IoC and one of the popular DIFs in WPF. Also, have you considered trying out MEF or MAF?" Any normal person would be justifiably dumbfounded by the preceding statement. (Is it any wonder IT folk are rarely invited to parties?)

I don't mean to diminish any interest in said technologies, as they very often end up being pretty cool and useful. My unastonishment upon using them is probably more related to relief at them not being as terrifyingly complex as I always for some reason assume them to be. Perhaps I've been scarred too much in the past learning about horrifying CS theories, NP Hard problems, and complicated algorithms by long-dead fellows (Dijkstra, you are the bane of CS sophomores).

At any rate, I'm once again in the position, this time with regards to MEF. I finally took a stab at it in a little side project I've been doing at work with the free time I've had lately between major projects. It's pretty neat, allows for a lot of customizability if you want to sub-class stuff, and isn't as bad as I was dreading. As far as DIFs go, it works fairly well, though as most people will point out its main goal isn't specifically IoC and as such it doesn't put emphasis on being the best and most usable IoC out there, but it can be used as one provided your needs aren't too complicated.

Omake Bonus: At first, I thought people were typoing when they said MAF…

* Interestingly, this phrase can be represented as exactly what it describes: TLA

The modern programmer

Abstractions. Specialization. Outsourcing.

The further I get into my career and the more skill and knowledge I collect, the more I begin to see patterns in life as a whole. It may sound odd to say that being a .NET developer and learning C# has taught me a lot about how societies and civilizations work, but it has.

As computers get more and more complicated, we programmers have to be increasingly specialized, which has the alternate effect of fragmenting and compartmentalizing us. Once upon a time, there was just the “computer guy.” Now you need a “network guy”, a “systems guy”, a “software guy”, a “database guy”, and so on. Even just focusing on my area of software, you need dudes who know kernel kung-fu, shell scripters, user experience gurus, graphic designers, architecture analysts, web guys, Windows guys, Apple guys, various Phone/Mobile guys, and so on. What happened to just being a “programmer”?

Set sail for EF and WIF

Lately I’ve been submerged in studying a sea of new technologies (I know, I know — wasn't I supposed to be studying for a test?). I’ve been spending a lot of time at work (and at home sometimes) reading two books in particular, in addition to all of the videos and other online resources. All for the purposes of starting a brand new and ambitious project for work, which I’m quite pleased in the long term to be doing as it will be quite a boon for my career. In the short term, however, I feel like I’m drowning in unknowns.

My burgeoning tool belt

I’ve had a surprisingly lengthy lull amidst projects at work lately. Instead of sitting around and watching dust collect on my desktop* I’ve decided to take the opportunity and time to study, study, study. And get paid for it, too!