Dirty Checking Pattern Breakage

I first saw Billy Hollis‘ Dirty
Checker Control at VS
Live in Las Vegas about a year ago. Once in a while I run across a dead simple
tool that just makes coding simpler and this is definitely one of those controls.
I have used to on most Win Forms apps that I have built since then.

Basically, the control drops into your containing control or form and registers itself
within the IDE such that any OTHER control on the form can be monitored by the DirtyChecker
control. If something changes, the DirtyChecker.IsDirty bool is set. Drop dead simple.
This is an easy way to manage button state. Like this:

So what’s the problem? Well, so far, I have been trying to strictly adhere to an MVP
pattern, which would require me to store the dirty state in my presenter, not
my view. This would actually make my dirty state management testable via unit tests.
This would be great, but can I really live with all that extra code when just a few
lines in my view will work really well and very cheaply? Isn’t it the job of controls
to make less code for me and get my app done quicker?

I’m torn.