I've just completed an architectural and code review of the Oxite code base. Brandon Kelly gave me the heads up on my previous post that there has been some controversy over the code and Microsoft's positioning on it's free release. I have to say it's definitely not the worst code I've seen in a production application, but my overall impression after the review is: Small skilled team with a "Git R Done" attitude.
Here are the negatives and positives my review:
- Not a good MVC reference example for learning - Some architectural decisions were made to move the controllers and models into a separate project from the views. This was done on purpose, but would make it difficult for someone new the ASP.NET MVC framework to dig in and understand as there are a couple of levels of indirection in the wiring.
- Improper Layering - Code base is not layered using Domain Driven Design (DDD) principles and namespaces are not clean and intuitive. It seems to be layered more along technical concerns instead of the problem domain. It's difficult to identify the separation between domain entities, services, and MVC plumbing. Any time I see "helper" and "wrapper" classes, it means there were decisions made in haste without regard for layering or naming. There are a couple of classes in the wrong places - leaky abstractions that lead to tight coupling are the cause in almost all cases. The underlying domain model is fairly simple as evidenced by the database table schema. It's just hard to grok it from the application business layer code.
- Light on Test Driven Development (TDD) - There are some tests included in the project as well as some mock objects but on the whole, the tests are not as comprehensive as they could be.
- Lack of Comments - Other than a few //HACK: and //INFO: notes, there are NO comments. IMHO, self-documenting code is a pipe dream. I have yet to see an application with a domain space of any complexity that could be understood by a new team member without comments. It's the Curse of Knowledge - if you wrote it, it's difficult for you to imagine what it's like not to know it. (Note: I do believe in self-documenting architecture. See my link to Rob Connery's screenshot at the end of this post. It doesn't get much cleaner than that!)
- Free Code - It's debugged, production code that's currently running on a high traffic site so it runs right out of the box. If you like it and it works for you - go for it!
- Web 2.0 Feed Handling Code Examples - There is a plethora of code for handling feeds, searching, and other web 2.0 communications channels. This code is clean and easy to understand and could be lifted easily.
- Background Worker Service Architecture - There's a good framework included for handling background worker tasks (see the Oxite.BackgroundServices project) from within the web application using timers. Services are driven from the web.config file. Could be very useful for light batch processing. LIGHT, being the keyword - you don't want to kill your web server with heavy duty batch processing that should be done on another set of dedicated back office batch servers.
This is definitely not the best project for learning MVC but I do not believe it was the Oxite team's intention to build a reference MVC application. My advice is to look at the positives I highlighted above for some good techniques. I thought about working up a proposed alternative architecture but Rob Conery has already taken on the task and is working with the Oxite team to refactor Oxite using DDD and TDD approaches. Based on the screenshot of his solution layout, he's doing a great job of layering the application to be much more logical and readable. Rob also has a series of articles that walk through a reference MVC application called MVC Storefront. I recommend looking there for your first hands on deep dive into the MVC Framework.