Oxite – Oh Dear Lord Why?!

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.

It isn’t just the base controller that seems burdened. You have controller actions that are over 100 lines of code and some which load 10 or more items within the ViewData. Views which are more ASPX code than HTML (Views/Admin/ViewPost.aspx or Views/Search/Index.aspx *shudder*), two JavaScript frameworks, at least 15 configuration classes and 10 repository classes.

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.

73 Responses to Oxite – Oh Dear Lord Why?!

Appreciate all the feedback, but I’m going to close this thread to further comments. I think we’ve moved away from the main topic onto a completely different one. We don’t have to agree about anything, but I’m glad everyone was willing to debate it. Apologies to anyone who feels that I cut them off from making their views knows.

Actually it is your argument that is silly. neither I or Karl or anybody has to write any open code in order to criticize oxite or any other project. And contrary to what you think, it is constructive and important to criticize loudly and harshly projects like oxite because of its association with Microsoft will likely grant it publicity unlike hundreds of well coded open source projects found source forge or codeplex like Arch# (have you heard of it? i bet not).

The fact it’s an open source project is what makes it open to criticism and not vise versa because if it was a closed source there would be nothing to criticize.

lastly, DDD, DI, SRP, etc are not buzzwords as you like to describe them. They are important scientific terms in the field called software engineering if you haven’t heard of it and understanding them is crucial to anybody working in this field which I’m sure you’re not a part of. Judging by what you wrote, you’re somebody who doesn’t write code for a living and thus doesn’t have the passion to defend quality code, so just go away or i’ll write some code to kick your you know what.

@DaRage:
I hope you can read this with your head so far up Karl’s you know what.

Open Source code teaches you something regardless of whether it is good or bad. (Of course there is always something good amid the not so good for any nontrivial project) If you have something better maybe you should release it to the world so we can critique it.

To sit there with zero contribution and fire shots at a team who is trying to contribute something is counter productive and adds zero value. Thats been my point all along.

Why has is it under Mix Labs?
Because they thought it would be cool to show what they are running their site on. Full stop.

To think anything from any source is gospel always is well rediculious. This is what your friend Karl has been using as a the main point of his diatribe. Microsoft should of course release the magic bullet using all the lastest glitzy buzzwords and in a timely fashion. Anything else is well unacceptable because it will confuse the new people… Don’t you think this thesis is a bit well silly.

I bet all those who criticized Karl (Josh et all) are not coders or used to be coders some time when a code implementation like oxite was something.

Don’t worry about your language and tone karl. such code needs to be criticized loud and clear because before you know it hundred enterprise applications will be build using oxite as an example just like hundreds were build using the asp.net storefront which used horrible design techniques that took me years to recover from.

Did you read http://visitmix.com/Lab/Oxite ? Especially the part about ‘built for testability and hence most likely to be voted “hottest in class” by TDD fans’ ?

You know, we shouldn’t complain. There’s a lot of money to be made by good developers in fixing bad developers’ code.

Don’t believe me? Raise your hand if you were handed a project with 0% code coverage, where core business logic was implemented in a private method of a System.Web.UI.Page and were told to implement new functionality. That’s how you rack up those billable hours!

@Conker
Check the history on the page, I believe they changed the page to have that bit about it not being best-practice (probably as a result of feedback). So the fact that message is now what it is shows the positive power that the community can have.

I think that you need to take a look at the way you write and accept some of the responsibility for the tone of your responses. When your lead paragraph closes with this sentence:

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…)

YOU have made it personal. Pissing on something is not a gift, it’s an insult and you made it clear at the beginning of the piece that you were out to get them. Using adjectives like “horrible”, “mediocre”, etc, is not an attempt to add value to a conversation, it’s an attempt to be a movie critic.

And saying that the MVC group should have adopted the recommendations of your friends is more than a bit arrogant.

You have done a good job of identifying problems, that a good place to start. Now you have to help fix them or you should keep your opinions to yourself (or do a better job at voicing them politely).

I would say that the release of Oxite to the world is akin to a programmer saying, “well, it compiled”, or, “it works on my computer”, etc., and saying to everyone else, “it’s good to go!” Opening Oxite’s code as open-source basically revealed it to the ultimate code review session. The heading on their website, especially with the proclamations “we’re using it in production”, implied certain things about the code that maybe aren’t so true…

Karl pointed out some of the issues, both wtih the initial (naive?) branding of it, how some programmers will look at it down the road and the implications of that, as well as actual technical issues. It was a criticism, and he’s not necessarily required to point out alternatives.

Rob Conery addresses many of the technical issues on his blog (not sure which came first, Rob’s post or Karl’s, or if they’re ships passing in the night), and hopefully they’ll be fixed soon.

The Oxite web page needs to be modified, however, to indicate that the code is a work in progress and that we’re ALL learning from it, both the downloaders and the developers. Whether it’s being used “in production” or not is simply a red herring.

I know I d/l’d it to look at (along with Kigg and MVC Storefront apps), to see how/if the developers obfuscate the database access layer, and integrate it with L2S. From the cricicisms about it, I’m not going to be looking at it further.

So where is the problem exactly ?
All they need to do is to clean up and refactor their code with some automatic tool of their choice , but its hardly a problem.
LINQ to SQL is a part of the framework and i dont see how it have “questionable” future any more than any other class inside Framework. LINQ is particularly good for exactly those kind of projects .

The truth is: “developer will flock and consider Oxite as the Hooly Grail”

That is usually the cause and that is why MSFT Only developers for the most part develop bad software.

I started up as a Unix developer (C/C++), then Java before .NET. I followed only the principles from good software development. However, in an attempt to make stuff [super] easy, MSFT always generates a culture of “BAD” developers by labeling certain “OPEN” projects as the perfect example of “best practices”.

Not to be all “Anti MSFT” but, they have the responsibility of “NOT MISLEADING” the community with horrible software. The Unity application blocks are good but they don’t promote them, instead we get CRAP like this as the “BEST” CMS ASP.NET MVC package.

One thing I like about C/J2EE projects is: They might have a learning curve and horrible IDEs, but they filter out a lot of phony developers

In addition to the core blogging features you’d expect, Oxite is a full working example of ASP.NET MVC in action!

And it’s from the real world: Oxite powers the MIX Online site. Oxite was a greenfield (built from scratch) project but the dev team borrowed functionality, code, and lessons learned from the Channel 9 codebase.

Oxite is an open source, standards compliant, and highly extensible content management platform that can run anything from blogs to big web sites. We know this because it runs MIX Online.

This isn’t a best-practices example of ASP.NET MVC design guidelines. For that, check out Rob Conery’s MVC Storefront application (there are others, start here). We are working to make it a better example of these guidelines, but it is most definitely a work-in-progress.
This isn’t a finished product. It has no install, it has no documentation. It is our code, exactly as we are using it. If you’d like something that is farther along and has all the support, documentation and handy installation features you’d expect from a finished product, then you might want to check out BlogEngine.NET, SubText or dasBlog … we are fans of all of these blogging engines… none of which use MVC at the moment but are far more ‘finished’.
This isn’t for non-developers. This follows somewhat from the previous point, but to be clear… if you aren’t familar with a web.config and with some database poking, then this isn’t the project for you. You might have more luck with the other blog engines mentioned in the previous point, but for a non-dev I’d probably suggest you check out Graffiti.

I don’t really understand the “Hey, at least they put something out there” train of thought. This is obviously a quite flawed piece of software put out there with a label stating that it’s a Best Practice.

Putting something out there just for the sake of putting something out there, even it if it’s of horrible quality is not a good approach to take. In this case, it actually causes more harm than good.

@Frank – yesss! Conery likes to fling mud when he wants to, and act like the voice of reason when it suits him. Anyone that reads his crap carefully will see this. Self-serving and two-faced. -1 CodeBetter for having him cross post here.

@Manitra:
I’ve blogged about unit testing, demoed it and presented it extensively. So while I didn’t necessarily add suggestions directly in this post, I think my views are easy enough to find.

I realize you can’t test everything (I like to think of myself as a pragmatic guy). But for a system with this much code, I would have expected to see 10-15 times more unit tests. Sure that’s a lot of work…if you wait until now to start. Its trivial to do as you go along.

My best suggestion was to unit test as you go, and most of these problems would have ironed themselves out. They never would have gotten the 100+ line controller actions under test, and would have had to address the problem upfront.

I did offer a lot of other suggestions in my post:
– Use consistent coding style
– Don’t use LINQ to SQL (can’t be tested, can’t use generic repository, questionable future, not portable)
– Use more generic base classes
– Refactor out Localization and Date functions from the base controller (I didn’t even look at HOW they did localization, I can just tell you that its obviously in the wrong place, so is all the Rsd and Feed stuff probably).
– I’ve blogged/demoed/showcased extensively on how to write effective unit tests, so I feel that’s covered as well.
– Simplify your views so they aren’t loaded with ASPX
– Check out Jeremy’s Opinionated Blog post (and by extension my own sample implementation of a small feature)
– Don’t use magic strings
– Don’t overuse the ViewData (the alternative to both, which I didn’t mention here but has been mentioned before is to use the Model and IModelBinder)
– Use a DI framework
– Use a single javascript framework

I know the tone was aggressive. But the code really is _that_ bad. And I hope you can agree that within my angst there really were a number of suggestions. Yes, they are top level suggestions (for the most part) but they are all backed up by frequently discussed approach and design topics (not only here on CodeBetter or on my blog either).

I hope you’ll agree that all of these are reasonable suggestions and enough to give the team some things to consider.

Karl, of course you are right in pointing out the problems and yes you are right in your views on what the problems are but somehow still this post just seems wrong?
I feel the urge to critise you for something but of course you are right–maybe thats what is bugging me, or maybe it’s your photo…really man you should be carefull ‘what you put out for everyone to see’

Good lord, those guys just wanted to release something….Instead of applauding them for having the courage to go hey look at this, instead of maybe contacting them and offering to help (Big props to Rob for that) you harpoon them and by extension used it to bash MS. That’s pretty harsh and doesn’t help anybody, and that’s especially disappointing considering the effort that you’ve gone to make the community a smarter place.

the problem with people is that they think of Microsoft as 1 entity… they are a bunch of groups that get funding depending on if thier project will make money or not. all thier best guys are probably working on Azure and .NET services or whatever other stuff is coming and some MVC evangalist guy hired a couple programmers to quickly do this… they did the best they could given the constraints… if you were such a hot shot why arent you developing world class software…. no youd rather be here on your soapbox pointing fingers.. show us your code so they can hit you back.. that would be a really hot post!

(disclamer; I’m the founder of Umbraco, an open source asp.net web cms and this comment is not to focus on code quality (i’m clueless on mvc) but on why ms is getting bashed)

The major flaw in the oxite release was the attitude in which it was releases. It wasn’t released with a big this is wip codebase and a very limited (not to say almost none existing) functional demo of what a mvc based blogging tool could end up being. Instead it was both in terms of functionality and code quality marketed as an ace project with a pretty cocky attitude, which is cool if you live up to the hype, but backlashes of you don’t. And it didn’t.

I say pull the project or call and market it as a work in progress barebone blogging engine – that’s what it is.

Funny, how all the horrible coding practices went mostly uncommented and the resharper along it’s coding standards ended up as the main weak point of Karl’s post to chew on among commentators…

I agree, samples by MS get way too easily evangelized to release such crap and produce million brain-dead copies of this approach just because it is done by people from or close to MS. On the other hand, why should MS teach people how to write good code? Clearly, they are struggling themself and code thrown out to the public is most probably 99% done by the guys who spend better part of the day selling themself not their code…

@Scott:
I read Code Better feed on a regulair basis. I fully understand before my first comment what Karl does and does not deliver. (I also read the authors)

I rather see a solution rather than someone being able to poke holes in how someone else has decided to implement it.

With that said I do not put as much stock in buzz words as you do. If I said we should be using SRP, DI and DDD for this feature. Any person on my team would blink and say can you speak english.

Being able to say project X should be using DDD because I love DDD is not saying much of anything. Except that maybe the author should just move past not liking X.

Give developers a little credit. Before I would touch Oxite I would first look at the code and see if it was useful for my situation. Very few programmers would say oooh shiney Microsoft source code it must be gospel. (real do we care about those who would

“Install Resharper and prepare to see more orange lines than you’ve ever seen before…”

“I hope you’re not suggesting that developers just code explicitly to ReSharpers suggestions? I take them as just that, suggestions.”

That is what the definition of a suggestion is.

On another note though, ReSharper would clean up a TON of that stuff. Also why is Microsoft Development staff not using the greatest and latest of tools to develop? They should all have ReSharper anyway…

…but I must digress, I haven’t even looked at the code. Regardless of how well it is written, any code can be used to learn from.

So I’m not trying to bash anyone – just saying Microsoft should shell out some $$ for ReSharper among the development staff.

They probably should have used the MVC Storefront if they really wanted a flag-ship ASP.NET MVC open source product. The community watched as Rob shared with us his ideas and he really incorporated some of the feedback from the community while building this application.

Oxite, on the other hand, was just realeased to the public without anyone having any input that could have improved the overall application. So, if you ask me, I don’t think you can call Oxite an “Open Source” product.

not only that, the trunk is broken. no routes are installed. there’s also no history (at least using svn bridge) to go back to a time when they worked. after looking at the code though, i decided it was best that i not run it.

@Karl:
Of course I question your motives. Its easy to throw rocks at a glass house. It different altogether to help build one.

I think the point of Oxite is/was great way to start a dialogue. I like to see you carry past this sucks into this is how I would do controller xyz different. I think afterall that is their goal.

Attitude: Re: Having to ship code.

I haven’t been on a project where the end goal was anything but meeting the expectations of the business. Zero business people or project managers care if you use domain driven design or the lastest buzz word. Instead they want it to create value for their scenario, which usually involves adhereing to a schedule and making priorities.

That’s a horribly wrong attitude. Ya know, writing good code might help them ship code more efficiently. The pieces of the Oxite codebase that Karl is complaining about probably added time to the development effort in extra debugging and testing time.

Karl, I think it would be helpful (because I keep seeing comments about it) if you distinguished between Oxite failing as a “best practices real-world ASP.NET MVC project” and its success (minus the security issues) running the MIX Online site.

I don’t think this article was about how they’re “bad,” people. I think it’s about how Microsoft is looked at to set good examples and all you do is lead your followers down a path of death and destruction. How can you expect your products to be used for good when you, yourself cannot even produce something worthy of the platform you provide.

I love it when people attribute code quality to the entity instead of the people who create it. Obviously Microsoft doesn’t have any quality gates it had to go through before being released. Most projects I have worked on Management just cares does it meet the requirements. Perfection is usually expensive and hard to manage.

I would say it looks very much like any project I have worked on. Its nice to have all these ideals. But at the end of the day they had to ship it sometime.

If you have a better idea on how to do it let see a code fork from you. Otherwise your just a zealot who has no time to live to his ideals.

Its nice that you believe you know how it should be. Its completely different to offer something of value.

Why is it MS guys always think an code criticism is a personal attack? Bullocks! It’s garbage and it should be called out as such. Make it better, or, if not, pull it off the shelves. I don’t sell more product b/c I am a “nice guy” I sell product because it is a superior product. If it’s not superior and it’s got the MS sticker on it, then it’s still garbage.

I don’t understand how people can say that Microsoft doesn’t really have to care about the code they release. It has their name on it, so its a reflection of them. No matter how Microsoft release code, the code is going to be taken as gospel. Microsoft built the framework, so they are going to know how best to leverage it.

I agree that there are few ASP.NET MVC examples out there, but how useful is a badly code example. Anti-patterns have their place, but common on.

Beyond starting from scratch. I don’t see how the project could be saved. Good code doesn’t happen by accident it starts at the foundation and works upwards.

@Scott
I don’t think we should blindly follow all R# suggestions, but some of the rules absolutely should. I iterated my worst-case offenders above, but unused methods, unneeded casts, messy “usings” should all be cleaned up. R# makes it easy to spot those and easy to fix.

I just don’t think this is the sort of thing that gets cleaned up after the fact. In my experience these are things that only get worse with time and thus requires diligence and care from the get-go.

I agree that there are some things wrong with Oxite, but the actual idea is not bad. Just the execution of the idea fell short. I’m sure they will address those issues and the product will be better in later iterations.

@dgi:
Not only did you miss the point, but I can hardly be accused of not wearing my code on my sleeve. I’m a pretty code-heavy blogger, and with that has come fair criticism/suggestions/attacks. Its made me a better programmer, and individuals have benefited from the corrections others have made to my code.

@Rob, @Kent, @Robert
The fundamental problem, which I tried to get across and others have commented out, is that this will be taken as gospel on how to build applications. It shows reckless judgement, and looking at the Oxite site I don’t see a big warning or retraction or ANYTHING that might help provide some guidance to the poor 15000 people who have downloaded this app. I know the app has serious flaws, the team recognizes some mistakes, but the thing is still up, being downloaded, and advertising itself as a real-world sample of how to do things.

@robconery
I agree its great its open, superb. However because it’s open people are going to be looking at this code right now. If you do a google search you’ll realize there’s a lot of talk about and I think it’s great that people like Karl/Chad and others are prepared to stand out say that this open source code should not be used as an example of how to use MVC.

However I don’t think anyone has said that the team are not awesome guys, and definitely not that they are bad people. No one is slighting them directly and from what I’ve seen the dicussion has quite rightly focussed on the product not the people. Even if we were though, surely releasing open source software at MS requires a somewhat thick skin?

In any case whether they are nice or not is somewhat irrelevant to this post and in addition I assume that most people at MS are nice guys, but I think we should still be able to comment on the content they release.

I’ll admit I was a little surprised opening up the code, since I thought I’d see manna from heaven but instead didn’t/don’t really grok the overall intent. Still, it would be very cool to see more sample apps, even from MS, rather than fewer, as I’d like to see a variety of styles to choose among and learn from rather than wait for The One Best Way blessed from on high.

What would be really great is to see the project redesigned/refactored to a really high level so we can see a process of improvement and evolved mastery to learn from, rather than only the end-product of the iterations and secret advice. If blogs like this give really specific examples of better approaches, cool.

I tend to agree with Rob here. The bulk of the effort right now (both internal and external) should be on “this is how we make it better” not “lrn2k0d n00bs”. The code was released to help, not to be the uber sample. It’s sad that some people have taken it that way (it was inevitable as soon as Da Boyz put “Microsoft” in the description field), but treat it as any sample application that is posted online. Suggest and help, don’t burn to the ground.

I’d like to really try and focus on the positive if we can. I’m working with the team, they’re awesome guys, and yes they realize some different choices should have been made. I won’t speak for them – but at the same time I will go to the mat for their intention of being open and transparent, releasing what they thought is good code.

You can help me by holding off a bit on the venom – these are not bad people.