In my last blog I criticized the team that released Oxite recently.  My concern was that they were promoting Oxite as a “real-world sample using ASP.NET MVC”, but as many others have said it is a poor example.

Since my earlier blog there have been a few more blogs on the topic.

Casey Charlton -  Oxite - An Example of How Not To Write MVC Applications

Rob Conery - Oxite Refactor, Take 1

Scott Hansleman - ASP.NET MVC Samples, Oxite, and Community

Oren Eini - Oxite: Open eXchangable Informative Troubled Engine

While Rob and Scott take a more conciliatory take – they are now of course Microsoft employees - the comment that for me “hits the nail on the head” is from Glenn Block, who is also an MS employee.

He has a refreshingly honest comment.

There is no excuse for this. There are tons of folks both internal to Microsoft or external that can help people who want to learn good practices for developing software. The fact that the MVC team was not even consulted by the Oxite guys is literally stunning.

It is pretty clear now that releasing this was a marketing blunder.  As I mentioned in my earlier blog, I hope the development team can provide some better examples of how they believe this new “tool” can and should be used.

Last week the team responsible for the MIXOnline site, released on Codeplex a new “Open Source” Blog Engine/CMS called Oxite.  One of its two main goals is stated as follows - “To provide a real-world sample written using ASP.NET MVC”.

Since the release of this sample application, there has been a lot of chatter in the twittersphere and blogosphere about this application.  The general consensus seems to be that, as a sample ASP.NET MVC application, it is a poor example. (See Karl Seguin’s blog and Scott Koon’s blog for more on the issues.)

I haven’t had a chance to do a code-review myself yet, but as an MVC newbie I might not notice anything wrong – and there’s the problem.  If this is being touted by a Microsoft Team as a “real-world sample written using ASP.NET MVC”, then surely it should use best practices for using this new (for ASP.NET developers) pattern.

Some have argued that the Oxite development team seem to be open about accepting contributions and working with the community to fix the many problems, but while this is commendable, I am still of the opinion that this should never have been touted as a “real-world sample” of “ASP.NET MVC”.

I know this wasn’t written by the development team, but anything released from Microsoft carries the perception of a stamp of approval.  I hope that when the 1.0 RTW version of the ASP.NET MVC Framework is released that there will be some “Best Practices” examples included to help us MVC newbies in the right direction.

With the imminent release of version 1.0 of the ASP.NET MVC Framework, does this mean we should now all be learning MVC as the “old” Web Forms model will be replaced?

The answer is a resounding NO.

The Web is a stateless platform.  With the introduction of ASP.NET over 5 years ago, Microsoft provided a “stateful” programming model, so that developers who were familiar with “stateful” systems likes Windows Forms would feel comfortable, and wouldn’t have to learn something completely different to work on Web Applications.

This model has proven to be very successful as demonstrated by the number of ASP.NET sites and by the number of companies providing ASP.NET Controls which are built on Web Forms.

Enter ASP.NET MVC.

Now we have a new paradigm for Web development, one that does not attempt to build a “stateful” wrapper around a stateless platform.  However, it does solve other issues.

There are two big issues with the WebForms approach.  First is that it is not very easy to Unit Test as the model is tightly bound to a Web context.  Second, designers have little control over the rendered HTML from the controls used.

ASP.NET MVC addresses both of these needs.  It is much more testable, and designers have much more control over the HTML that is rendered.

So now we have two ways of building Web Applications, the more “traditional” Web Forms approach and the newer “MVC” approach.  If you like the older Web Forms approach – stick with it – as the ASP.NET team is adding many improvements for  ASP.NET 4.0, but if you are more comfortable with a more testable approach and you want more control over the rendered HTML, now you have a Framework designed for you – MVC.

DotNetNuke is firmly planted in the Web Forms camp.  While there may be new approaches, that we can consider, and lessons that we can learn, it is not likely that we will convert the DNN platform to be built using the new MVC Framework.  At least not anytime soon.

In the original Star Wars movie there is a classic scene where Obi-Wan and Luke enter the Tatooine Space-port.

Storm trooper: Let me see your identification.
Obi-Wan: [with a small wave of his hand] You don't need to see his identification.
Storm trooper: We don't need to see his identification.
Obi-Wan: These aren't the droids you're looking for.
Storm trooper: These aren't the droids we're looking for.
Obi-Wan: He can go about his business.
Storm trooper: You can go about your business.
Obi-Wan: Move along.
Storm trooper: Move along... move along.

Obi-Wan uses the “Jedi Mind Trick” on the Storm trooper to “suggest” what he should do.

Sometimes we need to do the same thing in .NET.

Consider the scenario where you have developed a class – MyClass - in a Library that you distribute - MyLibrary.  You want to reorganize your libraries and create a new – MyNewLibrary - and move MyClass to the new asembly.  The problem is that all your existing applications expect MyClass to be in MyLibrary not MyNewLibrary.

In .NET 2.0 a new assembly level attribute was added – TypeForwardedTo(typeof(MyClass)). This can be applied to the “old” version of the Library, and your applications will not break.

The procedure is as follows:

1. Move the MyClass code from MyLibrary to MyNewLibrary .
2. Put TypeForwardedTo(typeof(MyClass)). in MyLibrary for the MyClass type.
3. Compile the newly created MyNewLibrary .
4. Add a reference of MyNewLibrary into MyLibrary .
5. Recompile MyLibrary (because MyClass used to be located in that).

When your application attempts to get a reference to MyClass from MyLibrary  – it will be redirected to the correct MyNewLibrary.

Or as Obi-Wan would say - “This is not the assembly you’re looking for.”

There is one corollary to this.  In .NET 2.0 MyLibrary cannot be a VB.NET assembly – this has been fixed in .NET 3.5 (VB9).

I am currently investigating whether this could be an approach to the “Breaking Changes” issue, as we move forward with DotNetNuke development.

Over the last weekend Scott Guthrie announced that Microsoft would be providing full support for the jQuery javascript library, including full PSS support.

This is quite a momentous announcement.  jQuery is an Open Source project, with a similar license to DotNetNuke (it uses a modified MIT license).  Microsoft are not absorbing jQuery and writing their own version.  Scott Guthrie stated that they intend to include the library “as-is”, and if they want changes they will submit them to the jQuery team for review in the same way as any other developer.

So, where does this leave DotNetNuke. 

It certainly makes it easier for us to provide jQuery support.  As it will be part of the core ASP.NET distributions, it will likely be included in most hosting provider solutions.  Enterprises will feel more comfortable with jQuery as Microsoft will provide PSS support for the library.

I am sure that over the next few weeks there will be many discussions within the core team on where we go from here – and we will keep you posted on any decisions moving forward.

If you want to know more about jQuery then check out these links:

• jQuery site
• Scott Hanselman  has a jQuery example on his blog
• Hanselminutes – Scott Hanselman interviews John Resig – creator of jQuery on a recent Hanselminutes podcast