MVC3

[Darren Cauthon]

Someone on Codeplex asked what it was going to take to get MVC Turbine
updated for MVC3 and what the plans were (http://
mvcturbine.codeplex.com/Thread/View.aspx?ThreadId=230325). I had some
free time today, so I branched off to see the changes that would be
necessary.

Like I say below, what I have is a start. I got to the point where I
had a working MVC3 site with MVC Turbine, but more changes will still
need to happen to Turbine. I think most of those changes will
actually be code removals, but I wouldn't feel comfortable with that
process until the source code for MVC3 Beta is released (still waiting
as of 10/10).

Any questions or thoughts so far?

---

Hello,

Javier's the guy to talk to when it comes to any time estimates or
plans. However, since the codebase is on Github, I took it upon
myself to see what it would take to make MVC Turbine compatible with
the newly released MVC3, and I think I've reached it. My changes may
or may not be what make the final cut, but it can at least be an early
spike to see what it will take to update Turbine for MVC3.

My MVC3 branch can be found on Github at the address below. By the
time I was done I was able to successfully plug MVC Turbine into the
default MVC3 site. I didn't put the test site through its paces,
though. It's only a start.

http://github.com/darrencauthon/mvcturbine/tree/mvc3

Here are my initial thoughts after having gone through this:

1.) As can be expected, MVC3 is going to let a lot of custom
resolution code to be removed from Turbine. Since the MVC3 framework
can now handle the resolution of the base MVC types through an IoC
container, there's no need for Turbine to do the same thing.

2.) I created a TurbineDependencyResolver class that implements
MVC3's new IDependencyResolver interface. The
TurbineDependencyResolver is just a wrapper around the
IServiceLocator, with one exception: If the requested type cannot be
resolved, it has to return null. This isn't my idea, it's a
requirement for the framework (http://bradwilson.typepad.com/blog/
2010/10/service-location-pt5-idependencyresolver.html).

3.) I create a core Turbine blade that registers the
TurbineDependencyResolver with the MVC3 framework. This means that
the resolution of many, if not all, of the core MVC bits will be
resolved out of the IServiceLocator. See (1) above.

4.) I added a ResolveServices(Type type) method to IServiceLocator to
make it compatible with the "IEnumerable<object> GetServices(Type
type)" method on IDependencyResolver. I implemented the new method
through all of the IoC containers except Autofac, which didn't have
the method for me to do it already.

5.) I had to upgrade all of the assemblies to .Net 4.

6.) I noticed that if an implementation of IControllerFactory is
registered in the IoC container *AND* one is set through the static
ControllerBuilder class, MVC3 will throw an exception telling you to
pick one or the other.



That's all I have right now. Hope it helps!



Darren

[Javier Lozano]

Yes most of the things we'll run into is code removals :) -- I've been
in communication with the MVC team through the entire process so our
switch will be pretty straight forward. I've cloned your branch into
my fork so I'll take a look at it and let you know when I've made
changes to it.