A couple weeks ago Microsoft released their first public version of Oxite – a blogging engine built using ASP.NET MVC. One of the goals of Oxite is “to provide a real-world sample written using ASP.NET MVC”. When you take into consideration that ASP.NET MVC is relatively new and scarcely documented, it should come as no surprise that people are seeing this as a recommended guideline for how to build MVC websites. One would expect Microsoft to realize this and seize the opportunity to showcase above normal coding prowess and leadership. (You might also expect someone at CodeBetter to piss all over it…)
Let’s be clear: Oxite is a poorly executed application that’ll have a profoundly negative impact on the ASP.NET community at large. Developers will flock to it, praise it, and blindly accept it as gospel because it comes from Microsoft (it’s already well on its way). Sadly, any developer which adopts its spirit will be left with an unmaintainble, untestable and unreadable mess.
Before we get to the specifics, I want to pre-empt a possible justifications people will throw my way. Specifically, I expect some people to defend Oxite by saying that it’s an early release. If you really believe that, than you and I have a fundamentally different perspective on what makes good software. Good design doesn’t come at some point between alpha and beta, its constantly present and baked into the very first line of code written. Going back and fixing code days, weeks or months after a feature is “complete” just doesn’t work. Of course you’ll have aspects that are poorly written and will need to refactor them (and you can even delay this for quite some time), but Oxite is an end-to-end glut of bad design that goes far beyond refactoring compartmentalized parts.
Looking at Oxite, I’m blown away by how complicated it is. This isn’t the right type of complicated either, it isn’t rich business logic which add value to clients, instead its almost 100% infrastructure. This indicates one of two things: ASP.NET MVC isn’t the right stack for this type of application, or we’re dealing with Architecture Astronauts. Do all ASP.NET MVC applications require a base controller with 490 lines of code? Oh, Microsoft will praise this as proof of the flexibility they allow, but it’s just really poor cohesion. Why is there 50+ lines of code dedicated to localization in the base controller? What does ConvertToLocalTime have to do with a controller? Who knows. Don’t forget to check out the constructor on that class – sure we like DI, but at some point its unbelievably easier to use a DI framework.
Is this really the sort of infrastructure and code we need in order to build sites using ASP.NET MVC? If this had been my first exposure to MVC, I’d have run right back to WebForms.
That’s just the tip of the iceberg. Not too long ago, Jeremy blogged about his thoughts on the MVC framework. His views, all aimed at producing highly maintainable and testable code, are completely absent from Oxite. I didn’t expect Microsoft to adopt Jeremy’s opinions as-is, but I did expect them to naturally come to some of the same conclusions. Most notable is the magic-string abuse, first visible in the overuse of ViewData, but you’ll quickly spot it throughout the code. There’s also the tight coupling now and again to HttpContext elements (forms, cookies, etc…).
I’d be remiss not to question the use of LINQ to SQL – not only because it has a doubtful future, but because it just isn’t a very good data access solution. What a wasted opportunity. I want to say that they ought to have used a generic repository, but looking at the code that simply doesn’t seem possible/feasible with LINQ to SQL.
Yet another issue I have is the complete lack of a domain model. I’ve said it before, and I’ll say it again, this “stack” should be called ASP.NET VC. Oxite is completely data-driven. I’m not saying the domain layer sucks, I’m saying it doesn’t exist. In other words, the MVC sample site doesn’t have a M, has a mediocre V, and a downright horrible C. If this is how we’re expected to build MVC websites, Microsoft should just abandon the project and have us work in WebForms.
How did all this happen? How about a complete lack of unit tests? Many of these problems would have been evident had the team decided to test their code. Instead, the test project has more manually coded mock objects than actual tests (actually, I seriously think I’m missing a project, because there’s no way the team built all this functionality and only 51 tests – apologies if I’m missing a part of the project). Again, a missed opportunity to show excellent design and help people elevate their career. As-is, significant parts of the code aren’t testable, I’m very interested to see how they address the problem.
Finally, I want to pick on the less than stellar code style. It’s extremely inconsistent – and nothing bothers me more than that. Do private fields start with an underscore, or not? Are fields scoped with “this.” or not? Do private method names start with a lowercase or not? One class per file, or 42? Should actions be virtual or not? string.Empty or “” ? Is content localized, or not? They have methods that never get called, assignments that serve no purpose (Views/Admins/Files.aspx makes me laugh), redundant casts and unused “using” directives. Install Resharper and prepare to see more orange lines than you’ve ever seen before
If you’re in an influential position at such a pivotal point in a new technologies life, you’d be a fool to do anything but establish the utmost best practices which will serve to enable your users to build sustainable systems. It isn’t ok just because the source is publically available and therefore open to criticism. Too many developers will see it as gospel and never know the scale of the problems.