Architecture

Multiple Blog Data

So I have a working LINQ to SQL provider for BlogEngine.Net. Now what? Given a little spare time, how about I see if I can’t use it to support running multiple blogs from the same installation? More importantly, see if I can use it to support running multiple blogs from the same database? Doing just that turns out not to be all that difficult. Scheming The current architecture for BlogEngine.Net’s data already has a bit more cohesion than it technically needs. All the objects have their own individual Ids and those Ids are used to relate...

posted @ Friday, March 27, 2009 5:00 PM | Feedback (0)

Professional Development

Many of the interesting .Net bloggers are part of the Alt.Net crowd; evangelizing Dependency Injection, Design for Testability, Test Driven Development, SOLID design and other development practices that they find useful in their work. It doesn’t take long reading these blogs to pick up on what looks like an unforgiving attitude towards those who don’t use the latest acronyms in their software development. This acrimony is unfortunate because most often what is at the heart of those who question the standard Alt.Net toolset isn’t so much principle as it is context. A Fundamental Assumption Unfortunately, discussing...

posted @ Wednesday, January 14, 2009 6:21 PM | Feedback (26)

Testability in .Net

Your environment can have a profound effect on how you develop software. The details of what I discuss here have zero practical meaning outside of the .Net world (though you can probably find parallels in other environments). That’s because .Net developers have access to tools that invalidate rules of software design that are fundamentally important elsewhere (before you question whether an environment can effect what is good design, consider the difference between good design in C and, say, Prolog). For .Net, the free availability of a tool like Typemock makes a major design consideration simply disappear—namely, testability. Typemock literally...

posted @ Friday, August 15, 2008 3:58 PM | Feedback (21)

Putting Dependency Injection in its Place

You might say that I’ve had issues with Dependency Injection in the past. Well, with all the things I’ve learned not to do, I thought I’d go into a case where I’m considering dependency injection because it looks like it might be a good fit. Project Background Like many (most?) developers, I’ve been involved for many years in a particular vertical market. Like most, my involvement in that vertical market includes acquiring a substantial amount of very specific domain knowledge. I’m sometimes reluctant to admit it, but I spent a good decade and more of my career...

posted @ Thursday, June 12, 2008 6:25 PM | Feedback (3)

TDD Considered Harmful?

Man, I'm going to catch it for that title. Okay, let me get this out up front: this post is a hypothesis that I consider probable. That's why there's a question mark in the inflammatory title. Okay, asbestos underwear in place, let's continue. The Hypothesis Here's the logic flow for my hypothesis. Unit testing (and its bosom buddy automated testing) provides substantial benefits when used regularly. These benefits are well-understood. Ensuring or regularizing unit testing is the primary value proposition of Test-driven Development (TDD). A majority of vocal unit testing...

posted @ Friday, February 22, 2008 9:27 PM | Feedback (20)

TDD or POUT

Because Unit Testing is the plain-Jane progenitor of Test Driven Development, it's kind of unfair that it doesn't have an acronym of its own. After all, it's hard to get programmer types to pay attention if they don't have some obscure jargon to bandy about. UT is too awkward, besides being a state abbreviation in the U.S., so for this post (and, if it catches on, future posts as well) I'll borrow from the telco folks and call unit testing Plain Old Unit Testing. The Best of all Possible Worlds Part of my problem with TDD has been that it claims...

posted @ Thursday, January 31, 2008 7:39 PM | Feedback (14)

Get Down With My Bad Self

I thought I'd take a shot at introducing myself here as suggested by Jay and maybe dispel any pretense at being a thinker, heady or no. Frankly, it's probably long past time that I put together some kind of background post about myself if only to give those who disagree with me a way to discount my arguments out of hand. I suspect this'll be long as I do go on sometimes. You can skip to a recent, similar post if you only want the heart of my current situation. Street Cred I've been playing with computers in one way or another...

posted @ Thursday, January 10, 2008 7:00 PM | Feedback (2)

My DI Failure

A couple of months ago, I mentioned a project I had coming up that might benefit from using Dependency Injection. The use-case on this is simple enough. We receive all of our EDI text files to a specific directory. Those files need to be processed into standard, internal temporary tables. Since each of our vendors uses the EDIFACT X12 fields differently, we need to customize parsing the files according to vendor. This is actually one of the larger projects I undertake at our small in-house development shop so it needs more up-front architecture than most and it seemed like a...

posted @ Monday, December 31, 2007 11:10 PM | Feedback (0)

Dependency Injection House Call

Reading the beginning of Joel’s second section of his talk at Yale clarified one reason I find myself so at odds with much of the hard-core Dependency Injection crowd (has Joel really achieved the level of fame that we can dispense with using his last name as Phil Haack suggests? Did you know who I meant right off?). Anyway, I am an in-house developer in a small company and that has a huge effect on my architectural decisions. In-house Development I described it a couple of months ago as simply "small company development", but Joel’s right that the more significant aspect...

posted @ Thursday, December 13, 2007 10:55 PM | Feedback (1)

Dependency Injection Objection

I’ve been putting off a follow-up on Dependency Injection for a couple of months now. The amount of heat I anticipate receiving is so disproportional to the probable light gained that it makes me hesitate. This weekend, I picked up on a stream of referrals from a post at InfoQ that mentions my Dependency Injection post (though not the follow-ups). It does a reasonable job of spelling out the conversation that happened, though I was feeling picked on until it brought in Eli Lopian’s contribution to the discussion. In whole, it’s a good summary. The real pile-on happens in...

posted @ Monday, December 10, 2007 10:46 PM | Feedback (9)

Deciding When to Use DI

I’ve been musing about software architecture lately and trying to come up with a framework to help choose when to go with more as opposed to less—something that’ll help me feel less arbitrary in my choices. I mean, software design is something of a dark art, but how much of that is inherent and how much is simply being too lazy to formulate good internal guidelines? My latest ruminations have revolved specifically around Inversion of Control in general and Dependency Injection in specific. Here’s the thing: for the development I do right now at a small reading glasses company, I’m reluctant...

posted @ Tuesday, September 18, 2007 8:58 PM | Feedback (5)

Small Company Development

I typically work with small companies who need to customize software to fit their business practices. A lot of companies have critical competitive advantages embedded in the way that they do things and need to ensure that their software doesn’t get in their way. That typically means that I deal with specific vertical markets (either at the vendor or client level) and dance with 500lb. gorillas to make things work the way companies expect them to. It’s business programming in the trenches and can be nasty, brutish, and, well, not short so much as constrained. The Typical Battlefield This is the...

posted @ Thursday, September 06, 2007 9:54 PM | Feedback (2)

Crazy Bob is my Hero

Bob Lee, creator of Google’s Guice project (the Dependency Injection framework for Java) has twice left comments here urging me to check out his talk introducing Guice. I resisted this because a) I don’t do Java and b) I figured I’d had enough with a later video recommended by Nate. This afternoon, I broke down and watched it and I’m glad that I did. It turns out that the things that grated on me from the first Guice video I viewed came mainly from Kevin Bourillion—mostly unfair comparisons to alternatives and boosterism. Bob is very personable, open and seems honestly intent...

posted @ Tuesday, August 21, 2007 10:43 PM | Feedback (7)

Poking Bears

I can’t believe the potent response I’ve gotten on my posts about Dependency Injection. Ayende Rahien responded individually to each of my posts himself, which is more than a little bit intimidating all on its own and a couple of development heavyweights left comments directly. Nate describes Ayende’s posts as the cavalry arriving and links to a couple of other responses. All of these posts disagree with me, though a post by Aaron Jensen indicates that he’s at least willing to consider the possibilities. All of this should have been foreseeable, really, as soon as I decided to publicly post...

posted @ Monday, August 20, 2007 11:10 PM | Feedback (7)

Tilting at Windmills

I’ve been giving poor Nate Kohari a hard time over at Discord & Rhyme. He has been very patient in Defending Dependency Injection. His attitude stands in sharp contrast to Ayende Rahien's post today about testing Linq for SQL. Ayende’s snide "(Best Practices, anyone?)" is exactly the attitude I lamented in my original post on Dependency Injection when I said I do wish that people would admit that DI doesn’t have compelling applicability outside of Unit Testing, however. I’m reading articles and discussions lately that seem to take the superiority of DI for granted. And I’ve read mock object examples that...

posted @ Thursday, August 16, 2007 10:59 PM | Feedback (8)

Dependency Injection

Dependency Injection is a design pattern used to abstract a provider from the class using it. Specifically, the calling class assumes responsibility for managing the provider instead of the class being called. Data access is a classic example of a provider that can be injected into classes that use it. If you decide to implement the DI pattern in a data access project, the most common method of doing so is to add an interface parameter on the constructor of each class that needs data access. A C# Example A class that accesses data might look like this (if it were programmed...

posted @ Tuesday, August 07, 2007 11:08 PM | Feedback (6)