I've been asked a lot lately about why one would choose MVC over Web Forms. I'm not so sure about when one should, but I know my default choice is always going to be MVC.
Here are a couple of reasons why
Closer to the metal
With the lack of server controls and postback model, I find myself writing more raw HTML. I like that. Some people won't and that's fine by me. I do.
Forcing developers closer to the metal is forcing developers to realize what is actually happening. That has to be a good thing.
Forces a more user friendly design
You know how in web forms you can build an entire workflow in a single page using the postbacks? You know, selected index change event on a dropdown, lookup buttons, sorts, filters, wizard controls, tab controls, etc. All these things causing postbacks and firing events and the URL never changing. It's all happening in place due to the magic of web forms and viewstate.
Well, I find that doing anything like that in MVC is hard. And I love that! The result for me is that I end up rethinking my view. I find my putting myself in the shoes of the end user and concentrating more on how to allow them to accomplish the goal as simply as humanly possible. If I really do need richness or dynamic data to accomplish the task, I'm going to do it in an AJAXy way because that's easier than posting back and forth. For the end user, that's a very good thing!
In a nutshell, I tend to focus more on accomplishing goals and less on editing data when I build with MVC.
All the other goodness
Google MVC vs. Web Forms and you'll find a ton of other opinions. I agree with just about every reason you find that favors MVC :). They're all good and whatnot, but the above two are my favorites.
Check out http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-really-mean for some good discussion about branching strategy.
This is in reply to a question about our branching strategy on my current project at work.
- Main - similar to "trunk". Contains the latest and greatest code and is always ready to deploy to production.
- Dev - similar to "branches". Any feature that will take more than one check-in to finish should be done in a branch. This is to facilitate the most important part of main – always ready to deploy. And of course, we check-in frequently as a good practice so branching is pretty important.
- Prod - similar to "tags". Contains the code that is currently in production. If it's a web app, you only really need one branch in here unless you think you might actually roll back to a previous version. This branch is useful when you need to immediately fix a bug in production but aren't quite ready for main to be deployed. Just because main can technically be deployed, doesn't mean the business is ready for it. The reason you see so many versions in our prod folder is pure laziness. It needs to be cleaned up big time.
And for the other two questions:
When you branch, you need to remember to check in the code you just branched. The icon mentioned is TFS's way of telling you that you haven't checked in the branched code yet.
We get the version number from the version of our core library. Many projects will use a shared settings file or something to ensure all the libraries within a solution have the exact same version - much cooler than the way we do it :)
Hope that helps!
These extension methods are becoming a staple in every project of mine. I just wanted to archive them and put them in a place I could easily point to.
public static IEnumerable<T> Each<T>(this IEnumerable<T> source, Action<T> action)
source = source.ToArray();
foreach (var item in source) action(item);
public static IEnumerable<T> TryEach<T>(this IEnumerable<T> source, Action<T> action, Action<Exception, T> onError)
return source.Each(item => item.Try(action, onError));
public static void Try<T>(this T item, Action<T> action, Action<Exception, T> onError)
catch (Exception ex)
if (onError != null) onError(ex, item);
public static T As<T>(this object source)
public static T FindById<T>(this Control control, string id) where T : Control
public static string F(this string source, object arg0)
return string.Format(source, arg0);
public static string F(this string source, object arg0, object arg1)
return string.Format(source, arg0, arg1);
public static string F(this string source, object arg0, object arg1, object arg2)
return string.Format(source, arg0, arg1, arg2);
public static string F(this string source, params object args)
return string.Format(source, args);
I was poking around in my data the other day doing a bit of housekeeping and ran across the recoding of Paul Clements' final presentation to devloop before leaving the company. I hated to see it hidden away on my HDD so I decided to chop it up and post it for all to enjoy!
Wise words from a wise man: Paul's Final Iteration
For those that haven't heard or don't remember, DEVLOOP stands for Developing Excellence Via Leveraging Object Oriented Principles. It's basically an internal user group started by Paul Clements and myself back around late 2006 or early '07 (I believe Jay Smith was heavily involved early on too). The acronym was coined by Paul himself if memory serves. Since we're OOP and pattern zealots, the name fit perfect!
For me personally, devloop has been invaluable in my career and I can't think of a single thing that has done more for me.