I started my career as a “real” engineer and got into software development writing automation tooling for my engineering group. This being the late 90’s, it was easy to transition into the early project automation groups where I got to be part of several initiatives to automate large construction project workflows. I was able to turn that experience into a real programming job at a Fortune 500 company. After a couple years of slogging through old style waterfall development, I discovered Agile Software Development and have mostly stayed in that world ever since.
I was at the forefront of early Agile usage in .Net and for better or worse was one of the main folks behind the short-lived ALT.Net movement. I’ve also been very active in .Net OSS development starting with the old StructureMap library and on to many other projects since. I’m currently the lead developer on the Marten project.
Since then I’ve swung between product shops and consulting companies before starting with MedeAnalytics this year heading up their new software architecture team.
My name is Jeremy Miller and I am a Developer and Software Architect in Austin, TX.
The Shade Tree Developer 
Jeremy,
Thanks for StructureMap. It is a great product.
I have been using it for some time very succesfully with a config file where the pluginTypes and pluggedTypes are nicely organized. Of course, the assemblies that contain the concrete types are NOT referenced in the calling assembly.
I am trying to use the concept of Registry DSL instead but there is something that I don’t seem to comprehend when using the For.Use(). In order for this to work, the concrete types MUST be in a referenced assembly but …. this really kills the purpose of IoC as far as I am concerned because the calling assemlby should NOT have any knowledge of the concrete assy, just the interfaces.
I tried to use the Scan with Assembly and AddAllTypesOf. This resolve my problem but it does not allow passing any constructor parms like the For.Use does and so I cannot pursue this avenue.
Am I missing the obvious? Should the Registry be in its own assembly that references both the interfaces assy and the concrete types assy?
Thanks, Yves
@Yves,
Let me get a blog post together for you by the end of the weekend.
“Should the Registry be in its own assembly that references both the interfaces assy and the concrete types assy?”
Yes, that’s one way to go about it. The Scan() business can be used (don’t have the code open, so the call might not be exactly right) like so:
Scan(x => {
// specify how you wanna suck in all the other assemblies
x.LookForRegistries(); // this will make it use any Registry classes it finds in the other assemblies
});
No xml necessary.
Wow, thanks for your quick reply, I appreciate it. I’ll be looking for your blog but I thought I would mention that I did try to put a Registry in the assy that contains the concrete types (which I don’t like to do because I then needed a reference to StructureMap) and use LookForRegistries() but it didn’t work for me:
Scan(cfg =>
{
cfg.Assembly(dal);
cfg.LookForRegistries();
});
whereas this works:
Scan(cfg =>
{
cfg.Assembly(dal); cfg.AddAllTypesOf();
});
dal is const with assy name. No need to reply here if you’re going to do a blog as I have already cluttered your BIO page enough ;).
Really enjoyed your article on design patterns for object persistence, it supported the approach I have been advocating for many years with respect to persistence being decoupled from the business objects.
Just wondered how you reconciled implementing the patterns when using TDD to deliver specific features, we have a similar dilemma at the moment as we are building an application which allows our users to send emergency messages to recipients but the simplest thing to do is to build the vertical slice which simply has a client communicate directly to our message service via a rest api…but I know in the back of my head that using a Message Q to decouple the client from the service will make a lot of sense but I am holding off implementing one until/if we start to see performance/scalability issues, appreciate your thoughts on this
Kevin
Spent most of the morning reading everything you’ve ever posted about TDD so I can come up with training for my company. It shouldn’t matter, but finding out you’re a fan of the WoT series and the KC Chiefs has made you more of an expert in my mind.
Not sure what being a Chiefs fan this year says about my sanity…
Hi Jeremy,
Not meaning to be contrarian here, but when you write “If I hear, ‘In the white book, Kent Beck says …’ one more time, I’m going to puke,” that’s the very same reaction I get with anything related to Martin Fowler worship. I think there’s a reason Fowler hasn’t updated his brain droppings on GUI patterns since 2006, and that’s because it’s all a steaming kettle of horse doo-doo. Frankly if I ever bother to start a blog, the first (and perhaps only) entry will be Martin Fowler Must Die. I have to wonder how many other people have caused developers to waste so much time trying to measure their private parts against what self-annointed thought leaders like Fowler come up with. Honestly, if you need to write a test to show that three buttons on your Winforms UI get disabled when you do something, maybe you should be in finance instead of software. It doesn’t take a lot of mental juggling to verify that and move on to things worth doing automated testing on. Just sayin’.
There is no perfect one-size-fits-all pattern, and the use of any pattern puts you in the red and must somewhere put you further in the black than you would have been without it to justify its cost. I haven’t seen a single study that actually quantifies and justifies any of this jumping through your a** to get “fewer UI bugs” compared to just testing what is easily testable. Some things are worth mocking and some things simply aren’t, and there is an optimization curve in terms of getting a project done and done well. When you spend huge amounts of time trying to separate every possible bit of UI, then you are no longer at the peak of the curve and are simply a can’t-see-the-forest-for-the-trees follower of one of many cult leaders in the industry.
I’m approving the comment ’cause it’s not crime to be contrarian, but I disagree with everything you wrote besides the meaningless “There is no perfect one-size-fits-all pattern.” As with all design patterns, you have to pay attention to the “why and when is this applicable” and not just blindly follow the mechanics. My experience with the design patterns you’re poo-poo’ing has been positive. Testing trivial code still pays off from the specification and regression test angle. And besides, I’ve seen far too much pain caused by crappy monolithic code in the UI or otherwise to have too much sympathy for the “get r’ done” mentality.
And for the sake of transparency, I was going to take over the book on Martin’s UI patterns with my own “build your own CAB” writing before I wussed out just to have a life;)
Hi Jeremy,
I respect the fact that you approved the comment. 😉 I do want to clarify though that I’m not endorsing a monolithic UI or a “get ‘er done” hacking mentality. I see people on StackOverflow agonizing over what Fowlerism to crowbar into their project and beating their heads against a wall, and while your CAB articles are a really good explication of the concepts, I think devs are in effect browbeaten that these things are “the right way” and that they suck as developers if they can’t wax philosophic on these patterns. We have enough to do to keep up on technology without chasing the thought gurus. If you need trivial UI tests to document your specs, there’s something wrong with your spec process. It might be a nice form of extra documentation, but the real question is how much extra time did it take you to get there, how much extra time does it take to modify something simple in the UI, etc. The real cost tradeoffs are never actually quantified. There is a point of diminishing returns with this stuff, and while guys like Jeff Atwood mention it here and there, it just doesn’t get said enough, and it can come across as yet another coding religious viewpoint. There is a balance in all things, in other words.
I’m still disagreeing with you Dan. If we throw out anything as invalid that we’ve seen used badly by the “other guys,” there’d be absolutely nothing left in our toolboxes with which to write software. After having worked with so many developers that don’t think about what they’re doing, I’d rather have the guys who err a bit on the side of agonizing over how to do things. As to your feelings about the testing, I simply disagree. My experience is that all those “Fowler-isms” have led to clean code and fewer bugs.
“If you need trivial UI tests to document your specs, there’s something wrong with your spec process.”
That’s a bit near sighted in my opinion. I’d far rather have executable specs than a useless Word document on any given day.
And it’s a moot point, the second that you use the word “religious” (or dogmatic or cargo cult or whatever) in a technical debate, you automatically lose the argument.
Well, hang on here. You used the phraseology of puking if you hear about the white book any more, but I can’t have the same feeling about Fowler? You called yourself a “Fowlbot” in your CAB series, and I automatically “lose” by observing such deference? 😉
I agree with you that people *should* think about these things, and it’s a strawman to suggest otherwise. I obviously do, or I wouldn’t be reading your CAB articles and the like. I also take you at your word that these practices have lead to “fewer bugs”…but at what cost in time and effort? How long did it take, and what was the opportunity cost of spending that time on more inherently testable parts of the codebase? I’m sure you liked the result, but if you have any links to actual studies, I’m all ears. All I can find are studies where people “like” MVC, and the only balancing comments are the observation that it might not be worth the additional startup complexity for smaller projects — and that’s talking about web projects, where it makes a lot more sense. I can find absolutely nothing that is remotely quantitative in terms of hours spent, number of bugs, time to patch, etc. Anecdotal reports of people who get excited about patterns really doesn’t cut it in terms of the bottom line to the business.
Now, I deal with horrible legacy code routinely, where it seems half the app is in the code behind for a button click. I’m not remotely suggesting that’s OK, and I have a big refactoring job ahead. The current project uses a third-party Winforms calendar control that likes to be databound to a dataset or POCO collection. So Supervising Controller sounds like a likely fit, yes? A new requirement is that you can click on an appointment, and up pops a complex chart (another 3rd-party databound control) with various data from the database, and if you click on an element in *that* chart, then you get another drill-down chart with different graphical information from related data in the database.
Using dependency injection I can test that fake data produces the chart *series* I want, but am I seriously going to create individual views and presenters for those drill-down charts? And even if I did, I risk the customer deciding they want a different chart type with different behavior, and then a good chunk of my “investment” in clean separation is wasted. The bottom line is I suspect that for any real-world Winforms app of any complexity, it simply costs more time and effort than it will ultimately save. Since many of these decisions as to the degree of separation are arbitrary, any new developers on the project have to spend a lot of time ramping up on my pet way of doing what I consider clean and beautiful as opposed to applying a KISS standard that tries to find the best mix of minimizing complexity while maximizing testability.
So I agree with you in the sense that these are tools, and it’s up to the wielder to judge the right tool for the job…I just am of the opinion that going whole-hog with MVC-type patterns for Winforms in general is trying to cram the elegant theory of the square peg into the reality of the round hole.
Hi Jeremy,
I remember bookmarking different articles for you in 2010 on msdn. However, I can’t get hold of that article anymore. Do you have any link to your old articles? The one I’m interested in was had the title: “Patterns in Practice: The Open Closed Principle” and its link was msdn.microsoft.com/en-us/magazine/cc546578.aspx
Thanks
Saleh.
Somewhere in the MSDN magazine web page you can access PDF copies of old issues. To the best of my knowledge, they no longer have those old articles up anywhere other than that.
– Jeremy