Jeremy D. Miller -- The Shade Tree Developer

The Videos for NDC 2009 are online

Jeremy D. Miller — Wed, 01 Jul 2009 16:16:00 GMT

The links to the videos recorded for NDC 2009 talks are online and linked in the agenda pages here. My talks are at:

Lessons Learned from a Long Lived Codebase
Presentation Patterns for Composite Applications (I'd dearly appreciate feedback from folks on this talk)
Convention over Configuration applied to .NET
Software Design and Testability

Talking conventions with the Hanselman

Jeremy D. Miller — Sat, 27 Jun 2009 15:22:00 GMT

Scott Hanselman posted a podcast he & I recorded at NDC last week. We nominally talked about applying conventions and opinionated software to .Net, then we went off on every possible tangent that presented itself.

NDC 2009 Wrapup

Jeremy D. Miller — Wed, 24 Jun 2009 12:58:00 GMT

I’m on my way back from the Norwegian Developer’s Conference in Oslo this past week. I had a fantastic time meeting some new people, hanging out with friends, interacting with a couple heroes, and seeing a little bit of Norway. Special thanks to Anders Norås for inviting me to NDC. I had a blast with the Bergen gang: Mark Nijhof, John St Clair, and Jon Arild Tørresdal. I got to put a face to Andreas Öhlund who is developing the StructureMap integration with WCF and nServiceBus.

I think all the talks were recorded and are going to be posted to the NDC website for download. I’ll blog the links as soon as they go up. I gave 8 talks in 4 days across 2 cities. I’m not sure I want to be one of those professional speakers that do that a couple dozen times a year. I had an awesome crowd for my “Design and Testability” talk that I appreciated. I had a comparatively small crowd for my “Conventions over Configuration” talk, but I had a lot of good questions afterwards that probably made that my favorite session of the week. Most importantly, I presented some preliminary design patterns work on the “Screen Activation Lifecycle” from my book and I thought it went over pretty well (you can see a little preview of it on Ward Bell’s blog here).

I got even more book ideas from Jonas Follesø’s talk. <bias>Apparently there are some crazy people out there who think it’s not entirely insane to do “View First” navigation. I need to cover that pattern in the book and pretend it’s not a nutso thing to do.</bias>

Lastly, I gave my “Lessons Learned from StructureMap” talk one more time. I think I’m going to retire this one permanently, so I might try to blog it out over the next 2 months.

Upon reflection, I think my favorite thing about NDC was that there was a lot of more or less ALT.NET-ish content (and the older speakers from the bigger software world that we admire), but we weren’t in special camps or the “Agile gutter” track like in the DevTeach’s I went to a couple years ago. I love that the tee shirts for the conference said “Legalize Unit Testing.” I don’t ever see ALT.NET becoming completely the mainstream, but it’d be nice to stop being this strangely alternative stuff on the fringe.

I got ambushed by Hanselman and recorded for Channel 9 spouting off on 3 hours sleep about “Executable Requirements”, StoryTeller, apologizing for using angle brackets, and explaining why I’m not using Oslo/MGrammar for creating external DSL’s for testing (hint: I’m very unenthusiastic about the phrase “you just have to parse the AST”). There’s several other impromptu recordings from the speaker’s area here.

All in all, I had a great time and I’d be happy to recommend NDC next year for those of you in that part of the world.

Dogfooding

Jeremy D. Miller — Wed, 10 Jun 2009 14:57:00 GMT

For the most part, I try to dogfood all new versions and flavors of StructureMap and StoryTeller at Dovetail. Just in case my boss reads this, that's largely okay because all of StoryTeller and many StructureMap enhancements are built for Dovetail to begin with. Today I hit an issue with the brand new "Nested Container" feature in the StructureMap trunk. Here's a rundown of the basic timeline this morning:

4:55 PM Last Night: StackOverflowException

9:10 AM: I isolate the problem to StructureMap itself as a nested Container is getting disposed

9:12 AM: I think to myself that dogfooding sucks

9:15 AM: I'm very, very glad that I caught this error before users

9:55 AM: After standup, I finally look at the offending method and say to myself "I'm a f***ing idiot" because I KNEW that what I did was going to cause a StackOverflow and I forgot to write the guard clause

9:57 AM: Fixed and happy

10:04 AM: Blowing off steam by writing this blog post

10:05 AM: Playing Centipede while my checkin dance gets going

Thank you for listening, I feel better now.

A Quiet Milestone

Jeremy D. Miller — Tue, 09 Jun 2009 13:59:00 GMT

I wouldn't read too much into this, but while I was giving my talk at the Austin .Net User's Group last night I asked the crowd how many people were doing some form of Agile or just plain iterative development. Almost every hand in the room went up. I'm sure not everyone is doing it well (I'm not sure that we do it well), but the numbers were still staggering to me. Sometime in 2005 Steve Donie and I did a talk at ADNUG on Continuous Integration and as I recall, only one bunch of people in the entire room was using CI. Unscientifically, a lot of stuff has changed over the past 4-5 years. I like that we spend more time now on how to do Agile (or Lean) development better instead of the same boring discussions about whether this new Agile thing can really work.

Convention over Configuration at ADNUG on Monday the 8th

Jeremy D. Miller — Wed, 03 Jun 2009 16:45:00 GMT

For all of you in Austin or thereabouts, I'll be speaking this coming Monday at Adnug on "Conventions over Configuration." I hope to see you there (and at Rudy's afterwards).

Yes, I'm going to finish "Build Your Own CAB" (sorta)

Jeremy D. Miller — Mon, 01 Jun 2009 20:29:00 GMT

Over the past couple years I've received quite a bit of positive feedback on my "Build Your Own CAB" series on design patterns for building desktop applications. Unfortunately, a lot of the feedback is "it'd be really nice if you'd get around to finishing the series." After all, I didn't really publish anything that actually related to building composite applications. I am wrapping up this series plus quite a bit more (+ incorporating the work that Martin Fowler already did on these topics but didn't publish), but as part of a book for Addison Wesley tentatively entitled "Presentation Patterns." I'll try to blog a lot more about the book next month as I shift to working on it a lot more. I'm strictly focusing on design patterns rather than any particular technology. At a guess, I'd say that half of the samples will be C#/WPF and the rest will be Java, WinForms, and even a couple JavaScript samples.

Here's the rough outline at the moment. If there's something you'd particularly like to see more or less of, feel free to comment on this (please).

What’s so hard about building a User Interface?
1. Look at everything that’s going on here
2. How do I test this?
3. How do I connect all this together?
Separated Presentation
1. The travails of using Active View
2. The Humble Dialog Box (narrative)
3. Separated Presentation (narrative)
4. GUI Architectures (pattern)
5. Passive View (pattern)
6. Supervising Controller (pattern)
7. Presentation Model (Model-View-ViewModel) (pattern)
8. Communication between the View and Presenter (narrative)

i. By events

ii. Direct communication

1. What’s the Model? (long narrative)
2. Model Based Validation with the Notification Pattern
The Mechanics of the View
1. Managing Screen State (narrative)
2. Flow Synchronization (pattern)
3. Observer Synchronization (pattern)
4. Flattener (pattern)
5. MicroControllers (pattern)
6. Embedded Controller (pattern)
7. Screen State (pattern)
Complex Screens
1. Composite Controller (pattern)
2. Layout (pattern)
The Application Shell
1. Coordination between Screens (narrative)
2. Screen Activation Lifecycle (narrative)
3. Presenter First (narrative)
4. Application Shell
5. Application Controller
6. Screen Collection
7. Screen Subject
8. Layer SuperType
Event Coordination
1. Coordination between Screens
2. Latch (pattern)
3. Event Aggregator (pattern)
4. Command (pattern)
Crafting a Domain Specific Language (not well defined yet, but could be a great chapter)
Modularity
1. Using an Inversion of Control Tool
2. Bootstrapper (pattern)
3. Registry (pattern)
4. Presentation Chooser (pattern)
Communicating with the Server
1. Message Bus
2. Command Executor (pattern)
Automated Testing
1. Unit testing the Presenter layer
2. Unit testing the View
3. Subcutaneous Testing
4. Strategies for User Interface Testing
5. Screen Driver (pattern)

Oh, and my take on "is M-V-VM the same thing as Presentation Model?" I say yes. I think it's the exact same pattern just described differently by Fowler and the Microsoft guys. Think Leipzig and Sir Isaac Newton discovering Calculus at the same time.

Persistence Patterns: Cascading Updates

Jeremy D. Miller — Sat, 30 May 2009 21:34:00 GMT

This content was cut from my most recent MSDN article on Persistence Patterns for length and possibly quality. What the heck, it's an important topic that throws some people off and it's also something that many people who are new to ORM's frequently don't understand. I'm also misusing the term "reachability" a bit here, so substitute "cascading save" wherever that term pops in.

Normal 0 false false false EN-US X-NONE X-NONE

Many persistence tools support cascading updates and deletes through an object graph. This is both a powerful tool for improved productivity and a source of confusion and errors.

To explain this concept, let’s imagine that we’re building a new invoicing system that has an Invoice class like this one:

// The Invoice class is purposely simplified

// for this example

public class Invoice

{

public IList<InvoiceLine> Lines { get; set; }

public Customer Customer { get; set; }

}

The Invoice class has a list of InvoiceLine objects and a “many-to-one” reference to a Customer object. When our new invoicing system receives a message directing it to enter a new Invoice, our system creates a new Invoice object, all the related InvoiceLine objects, and assigns the proper existing Customer object to our new Invoice. That process is shown in the CreateInvoice() method of the InvoiceService class shown below:

public class InvoiceService

{

private readonly IUnitOfWork _unitOfWork;

public InvoiceService(IUnitOfWork unitOfWork)

{

_unitOfWork = unitOfWork;

}

public NewInvoiceConfirmation CreateInvoice(NewInvoiceMessage message)

{

// Read in the NewInvoiceMessage object, create

// the children InvoiceLine objects,

// and attach an existing Customer object

Invoice invoice = buildInvoiceHeader(message);

invoice.Lines = buildInvoiceLines(message);

invoice.Customer = lookupExistingCustomer(message);

// Persist the new invoice

_unitOfWork.MarkNew(invoice);

// Commit the transaction

_unitOfWork.Commit();

return buildConfirmation(invoice);

}

In order to finish the new Invoice transaction, we need to save the header information for the Invoice object, the reference from the new Invoice to the existing Customer, and each of the individual InvoiceLine objects. However, in the code above for the InvoiceService.CreateInvoice() method we only marked the top Invoice object as a new object in our Unit of Work. That’s because we’re depending on our persistence tool to use a cascading update policy to walk the Invoice structure and save all the new InvoiceLine objects at the same time.

In my last article I talked about using Object Relational Mapping to create a persistence solution by configuring a mapping between the object model and the database structure. For the Invoice class in our new invoicing system, I would configure the mapping from Invoice like this (using Fluent NHibernate):

public class InvoiceMap : ClassMap<Invoice>

{

public InvoiceMap()

{

// The Cascade.All() directive forces NHibernate

// to save the InvoiceLine children of an Invoice

// object whenever the Invoice object is saved

HasMany<InvoiceLine>(x => x.Lines).Cascade.All();

// The Cascade.None() directive tells NHibernate

// NOT to save the Customer object when

// the Invoice is saved.

// The link from Invoice to Customer will be persisted

References(x => x.Customer).Cascade.None();

}

In this example, we’ve made the InvoiceLine children of an Invoice object “reachable” when a new Invoice object is saved. In the case of our new invoicing system, I’m assuming that new Invoices can only be created for existing Customer objects. Because the Customer object isn’t modified by creating a new Invoice, we certainly don’t want the Customer object saved (or even checked by our persistence tool for possible modifications) when a new Invoice object is saved.

Because of the potential for errors due to incorrect assumptions about how cascading updates are configured, my strong advice is to use a battery of integration tests against your service layer to ensure that data is persisted correctly. Tightening up the rules and policies for cascading inserts, saves, and deletes is a common way to optimize the performance of a system that uses Object Relational Mapping for persistence. Again, this optimization process will be much safer if it is supported by automated tests that can catch regression errors caused by changing “reachability” rules.

Lastly, almost every business application of any size that we build will contain hierarchical information. Reachability is another great example of how an ORM persistence tool can save development time versus old fashioned “hand-rolled” data access code. In this case, NHibernate is dealing with running the insert, update, or delete statements in the correct order and dealing with moving the new autonumber Id's from the parent to the children records. Believe it or not, I do know how to write that ADO.Net code from scratch and even how to write sproc's to do the data access, but call me lazy and shiftless 'cause I'd rather just go _unitOfWork.Save( myNewInvoice ) or _unitOfWork.Delete( myOldInvoice ) and get on with the next feature.

More Persistence Patterns in MSDN

Jeremy D. Miller — Fri, 29 May 2009 15:01:00 GMT

EDIT: I missed something the first time around. If some persistence tool makes it so that I can only put business logic in my domain models using a partial class, that's an automatic FAIL!

My latest article in the Patterns in Practice column is in the June edition of MSDN Magazine. This time around I continued the discussion about persistence patterns with the Unit of Work Pattern and some (very watered down) discussion about Persistence Ignorance. Granted, this isn't my favorite article I've ever written, but these are important topics that I think everyone needs to consider as part of their persistence strategy. For you folks out there that say "bah, humbug, I don't need no POCO," I think you need to at least consider the issues before you blow it off.

To summarize, *I* think Persistence Ignorance is important for these reasons in descending order of importance (you can argue whether 3, 4, or 5 is more important):

Can I exercise my business logic and user interface without having to drag in the database? This is crucial for efficient unit testing. With the way the Entity Framework v1 did lazy loading, the answer is no. With NHibernate and maybe EF v4, the answer is yes.
Can I design my object structure and database model independently? In other words, don't make the database model dictate the shape of the object model. As the complexity of the system grows beyond dirt simple, codegen'ing the object model from the database tables is teh suck.
How easy is it to make small incremental or evolutionary changes to my domain model? Again, I think code generation schemes that start from a complete database model and generate the object model are optimized for BDUF and become unwieldy in the face of small changes. Solutions that require change tracking to be coded directly into the domain model make incremental changes harder because of the extra weight of changing or adding new properties to the model.
What strictures does my persistence tooling place on my object model? Marking properties as virtual just to enable lazy loading is annoying. Having to expose public properties of inner collections like Lists or Sets destroys encapsulation and is completely unacceptable to me. My persistence tool shouldn't force me to compromise encapsulation. I really don't want to have to inherit from a base class in the framework. It's very valuable to use my own Layer Supertype for my domain model rather than blowing my one superclass on infrastructure goo.
Lastly, I don't want persistence methods cluttering up the public interface of my domain model classes. Interface Segregation Principal baby!

For the record, it does look like from a shallow reading that the new EF v4 looks much better than EF v1 did -- but still falls well short of NHibernate. It all depends on how much you really care about this stuff. *I* care deeply about the ability to design continuously and incrementally, clean separation of concerns, and test driven development. To me, the object model is the main player in the application and the database is nothing but a persistence mechanism. If you don't care about those things, or are just simply too engrained in data centric orthodoxy to change, then you can happily ignore that list.

Go ahead and argue away I suppose. I'm offline for the next 3-4 days, so you automatically get the last word in;)

The Joys and Pains of a Long Lived Codebase -- The Video

Jeremy D. Miller — Thu, 28 May 2009 13:57:00 GMT

InfoQ just posted the video from my talk at QCon San Francisco 2008. In this talk I went over some of the harsh lessons I learned from 5+ years of working with the StructureMap code, including:

How classic "Big Noun" classes grew out of control and how moving to more role-centered abstractions has made the code easier to extend
How badly expressed unit tests impaired progress and why I finally believe in BDD
Creating an API that serves the end user instead of the internal model of the framework
How our expectations for using a framework have changed very dramatically in the last 5 years
The coding and design flaws that made the code harder to change

I'll be giving an updated version of this talk at NDC 2009 in a couple weeks as well.

Looking at 6 month old code...

Jeremy D. Miller — Wed, 13 May 2009 19:36:00 GMT

...and I'm not horrified (much) at what I'm seeing. Is it:

A.) That the code is really okay

B.) I haven't learned anything new in the past 6 months

C.) I just haven't looked hard enough

UPDATE: As we learned in school from our experiences with standardized testing, the answer is always "C!"

And finally, I wonder how much more blogging there's going to be today 'cause Twitter is down?

Sneek Peek at StoryTeller (i.e. my FitNesse killer for .Net)

Jeremy D. Miller — Mon, 11 May 2009 19:20:00 GMT

I've gotten pinged 4-5 times in the past week about just where I'm at with StoryTeller development. I think I'm finally closing in on something that I could release at least as a preview. Just to prove that I'm still working on it, here's a sneek preview of the tool. I'm tentatively doing another Elegant Code Cast with David Starr on StoryTeller soon, so just pile on with any questions.

Quick History

I've had a love/hate relationship with NFit and/or FitNesse for quite some time. In many ways, I still believe that "Executable Specifications" are the "Holy Grail" of Agile/Lean software development and that belief naturally led me to using first NFit and then FitNesse. However, I increasingly found FitNesse rather painful to use and impossible to transition to client teams. My frustration with FitNesse eventially led me to start a new OSS project called StoryTeller as a replacement for the test editing and management functionality of FitNesse, but keeping the underlying Fit engine. I coded on that for about 2 years with no more than middling enthusiasm and minimal success before I finally threw my hands up in the air over the FitNesse testing engine and junked the whole StoryTeller project.

The New StoryTeller

Late last year I started a complete ground up rewrite of StoryTeller with a totally different testing engine that we're using to write acceptance tests and integration tests at Dovetail. I haven't made an official release yet, but as of right now StoryTeller has:

A testing engine that is a superset of the basic FitNesse Fixture types (ColumnFixture, RowFixture, DoFixture, ArrayFixture, etc.). The engine supports a mix of flow-based and table-based testing.
Customizable type coercion
A command line runner for use in an automated build
A way to tag tests as either "Acceptance" or "Regression" for testing lifecycle (Regression test failures cause a build failure, Acceptance test failures are simply reported)
A User Interface tool that acts as a runner and an interactive tool for test editing

How does this relate to other tools?

NUnit/MbUnit/xUnit.Net -- There is some overlap, but an xUnit test will never be terribly readable to non coders, and that's what StoryTeller is striving for. I see xUnit tools being used for unit tests, StoryTeller for acceptance testing, and integration testing being a gray area where you might go either way on a case by case basis.
FitNesse -- I obviously think StoryTeller is a far superior tool to FitNesse, or I'd just be using that as is. FitNesse is the closest analogue to StoryTeller.
Machine.Spec or Cucumber or RSpec -- Kind of solves the same problems in very different ways, but StoryTeller is more geared towards integrated acceptance testing. I wouldn't care to use StoryTeller for straight up TDD at the low level. I guess the short answer on this comparison is "I don't know."
Oslo -- One of the frequent examples of Oslo I've seen is a DSL over the top of WatiN for web testing -- and that's great, but how about being able to quickly churn out little one off testing DSL's?. In many ways StoryTeller is a tool for creating External DSL's for testing your application code. That's a direct overlap with Oslo (depending on which Oslo team member is speaking and to what audience), but at this time I feel like Oslo would require far more effort than StoryTeller in order to build a behavioral, runtime DSL to do testing. StoryTeller grammars allow you to quickly bridge the gap between how you want to express your test specifications and the system under test. Oslo would require you to parse and interpret those nasty, nasty AST's to perform the actual functionality.

The Main Screen:

Woohoo! You can see all of the tests, you've got a status bar to show you what's running, what's queued up, and when the StoryTeller UI picked up the binaries (it does use a FileSystemWatcher like NUnit to watch for the system under test binary getting updated).

At the top, you have options to filter the tests shown in the test tree on the left:

Uh, and if that looks a lot like the ReSharper unit test runner, let's say that imitation is the sincerest form of flattery.

You can also control the testing runtime like so:

I'm particularly proud of these features. Sometimes (most always), an integrated test can be slow to execute or Selenium can hang or who knows what can happen. StoryTeller will allow you to specify that tests should be aborted the first time they encounter an exception or a test failure instead of running the entire test as it normally does. You can also change the test timeout on the fly.

StoryTeller can show you the tests that are queued up to execute:

Yes, that screen is butt ugly so far, but it gives you the ability to track progress, clear tests out of the queue if you change your mind about running them, and abort the executing test.

Lastly, how about an actual test? Here's the preview mode:

and the Results mode:

Like I said, this is just a sneak peek. I'll have much more information out soon as I feel it's becoming usable.

And no, I don't think my problems with FitNesse are a team structure or a communication problem. Please don't insult my intelligence (again) by changing the subject. The problem with FitNesse is mechanical.

Revitalizing a Technical Career

Jeremy D. Miller — Tue, 05 May 2009 15:21:00 GMT

A good friend of mine recently asked my how he might go about revitalizing his career. I'm putting some words in his mouth here, but I'm pretty sure that he's interested in getting back into hands on development and moving away from a strictly managerial role. In his case, he is/was a very strong developer who really just needs to scrape off the rust. The problem is that I think he needs to go get some knowledge and experience to position him for a different role that he probably can't get in his current role.

Here's my thoughts on the subject. I (and my friend) would appreciate some feedback and better ideas:

Pursue the MCP/MCSD certification. I would definitely take certification into account when hiring very junior developers, but it's not something that I would pay a lot of attention to for mid level or senior developers. I think the certification effort could be helpful for experienced developers moving into a new platform where you just need to map Java names/syntax to C# names/syntax or vice versa, but the question is my mind is whether or not another effort would be better.
Follow some of the leading blogs just to see what people are doing, thinking, and writing about. For the cutting edge in .Net practice, I like Los Techies, Elegant Code, and CodeBetter (of course). For development in general, my favorite online source now is InfoQ.com.
I think podcasts can do a much better job of explaining/discussing subjects because of the more interactive nature. My favorites are Herding Code and the Elegant Code cast. DotNetRocks is by far the most popular, but I don't think they cover their topics sometimes as well as some of the others. Hanselminutes has some gems here and there. The ALT.NET podcast just isn't regular enough, but it's good as long as it isn't a meta-ALT.NET podcast (like the one I did last time).
Go to user group meetings. The talks themselves aren't usually very good, but the conversations afterwards are worth it. I prefer discussion groups like the NYC eXtreme Tuesday club and Austin's ATX lunch group over eyes forward ***NUG meetings. If you ever get a chance to attend an open spaces event, jump on it.
You gotta get some experience with the newer things and concepts. My strongest recommendation to bump up your coding skills is to find a way to participate in an OSS project of some sort. That recommendation goes double if you're in some sort of non-Agile shop and you want to get some hands on experience with things like TDD and test automation. Plus, OSS work is usually more interesting and much more challenging than the day to day programming (my experience anyway).
Build a side project of some sort. This is based on the theory that hands on experience is better than just reading. Use different tools and techniques than your day job.
Personally, when we're hiring, I'm far more interested in a person's understanding of concepts and principles rather than in specific technologies. I would strongly recommend focusing much more on design principles and even practices as opposed to purely technical subjects. If you study and build an understanding of the SOLID principles, you'll be able to apply that knowledge to any enterprise software project. Reading a book on WPF is useless for working on a web developement project. I'm not saying to completely ignore technologies, just to put them at a lower priority.
I honestly can't think of a single book to read that is going to make a huge difference. I like the Pragmatic Programmer book, all of Fowler's books, and the Feathers book, but I see books as a good supplement and not the main thing.
Find a different job. Maybe this isn't a good recommendation during a deep recession, but your ability to grow in your career sometimes is only as good as your company. I see a depressing number of people trying to rise above the riff raff at very mediocre development shops. Sometimes you can make a big difference where you're at, but other times you're just stunting your growth.

What I Did

I've written about this subject before, but a bit of a recap can't hurt. In 2002 I was moved into a non-coding architect role and I hated it. At the time I only had experience with DNA technologies and Oracle when the enterprise development world was quickly being divided up into J2EE and .Net camps. I felt like my career was circling the drains with every powerpoint I delivered and every bureaucratic meeting I attended. I slowly started working on what became StructureMap off to the side to get some demonstrable experience with .Net and some new concepts (TDD, OOP). In '03 I made the big leap out of the stultified big corporate IT world into ThoughtWorks right as Agile/XP was getting off the ground. I spent a lot of time around stronger developers who were passionate about the craft of software development and learned a lot about software engineering (which I hadn't in a CMMI wannabe shop because that was someone else's job). I can't say that my experience there was roses every day, but I would credit that move with salvaging my career and putting me on a better path.

The best single thing I've ever done for myself was to start blogging and writing.

My Quick Oversimplified ASP.Net MVC Pros and Cons

Jeremy D. Miller — Sat, 25 Apr 2009 00:03:00 GMT

There's been a lot bouncing back and forth about whether the ASP.Net MVC (and the MVC manner of building web apps in general) is a good thing or not. I'd propose summing it up in two bullet points:

CON: The ASP.Net MVC framework *is* half baked. It isn't usefully opinionated in the slightest other than it more or less promotes the MVC/Model 2 pattern, it encourages way too much sloppy "magic string" antipattern violations, it doesn't have squat out of the box in terms of the "M" or helpful conventions on par with Rails, nothing like Capistrano (that might be changing soon though), and the Html helper libraries out of the box are just plain weak (I don't like their approach for the MVC Futures either. It'll make the MVC more friendly to WebForms folks, but has the exact same problems as the current helpers). In my opinion, the MVC framework is not efficient unless you're willing to roll up your sleeves and build your own project specific infrastructure to fill in the "M", achieve some better testability, easier screen synchronization, and more productive Html helpers like what Jimmy Bogard describes here. If the thought of rolling your own NHibernate or "validation framework of your choice" integration with the MVC framework fills you with dread, then I don't think you're gonna want to use the MVC -- and that isn't something to be ashamed about.
PRO: It's pretty easy and straightforward to take the MVC framework by the horns and customize it for your benefit. Granted, I felt like we hit a wall with the MVC framework at Dovetail and moved on to the FubuMVC efforts, but many of the things we've done that have enabled the most productivity for us are perfectly applicable to the MVC framework out of the box.* I think that a lightweight application framework that's specific to the application being built will almost always be more productive than a big, giant heavyweight "one size fits all" generic framework.

To sum it up, I think the MVC (and any MVC framework for that matter) framework is a tool that maximizes the effectiveness of development teams that are willing and able to use creative solutions, but at this time doesn't do much to help average teams who only code with what comes out of the box. I'd also say that the "To MVC or not to MVC" argument is a classic example of the "Safety versus Power" argument. I stand behind the assertion that the ASP.Net MVC framework is a better way in the end to build web apps than an "abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand," but at this point it's probably a tool strictly for early adopter type folks.

Oh, and I don't really want Microsoft to be the ones creating the more robust, opinionated stacks on top of the MVC framework anyway. I'd much rather see the community build the specific integrations and application stacks because we have more freedom to choose tooling than an internal Microsoft effort, and some level of diversity is a good thing. Microsoft putting out the official, comprehensive MVC solution could easily be a disaster that completely chokes off any further innovation.

* I think we hit the wall with the MVC out of the box mostly because of the Thunderdome Principle and a convention based presentation chooser model for alternative browsers (we swap views and sometimes the presenter and view if the browser is on a mobile device). We also tie the controller registration directly to the route configuration to eliminate errors (another shortcoming of the MVC framework IMHO). At that point we found that the MVC controller lifecycle was simply too limiting for what we were trying to do and frankly wasn't that hard to completely replace.

See you at NDC 2009 in Oslo

Jeremy D. Miller — Thu, 23 Apr 2009 14:23:00 GMT

For those of you in that part of the world, I'll be speaking at the Norwegian Developers Conference in Oslo, Norway on June 17-19, 2009. It's an incredible lineup taken straight from the author names on my programming bookshelf with a pretty decent ALT.NET lineup as well. For my part, I'm speaking on:

Lessons Learned from a Long Lived Codebase -- What I've learned from 5+ years of building and rebuilding StructureMap to do new things and old things better
Presentation Patterns for Composite Applications -- Advanced patterns. Event aggregation, controlling the screen activation lifecycle, extensibility through using an IoC tool, creating application specific DSL's for wiring the screens together
Convention over Configuration applied to .NET -- Not just for the Ruby on Rails guys. What tricks can we do inside .Net architectures to go faster?
Software Design and Testability

I'm not sure about the exact timing or topic yet, but I'm also planning on speaking at the Bergen .Net Users Group as well earlier that week (and doing some tourist-ey sightseeing).

See you there!