BarelyMVC now LucidMVC

So, finally decided to rename the project. However, I decided against ClearMVC as being a bit too plain. So, a close synonym to Clear is Lucid, hence LucidMVC. There is some small MVC PHP framework that was last updated last year that goes by the name of "lucid-php", but I bet I can beat his google page rank :)

Anyway, so there you have it. Update your repository URLs and such to use

Also, the BarelyMVC bitbucket repo still exists, but I had to create it from new. So, now it just has a single commit saying "this has been renamed"

Posted: 3/3/2013 6:40:21 PM

BarelyMVC meet ClearMVC

So, I think BarelyMVC isn't just a tiny minimalistic framework anymore. It's goals have changed. It's scope has changed. So, it's getting rebranded to ClearMVC. Hopefully, this will better reflect the primary goal of "no magical black box"

Posted: 2/19/2013 4:40:50 AM

Breaking Changes For Everyone!

So, remember how I said there would be no more breaking changes to the router of BarelyMVC? Well, part of the whole "making it testable" meant that the current API as it was sucked major balls. We need some way to simple get an IServerContext into the created HttpHandler. It's not really possible without magic with the current way the API is... So, it's changing.

The Proof Of Concept for a tiny taste of the new API is here. Highlights:

  • Fluent API blog.Handles("/blog/new").With((c)=> c.New()).RequiresAuthentication()
  • Worry less about getting data from routes/forms into your HttpHandler methods
  • Treat handlers more like controllers
  • Make it so no more reliance on static class elements like HttpContext.Current
  • Will reduce code duplication for adding similar routes on the same "controller"
  • STILL no reflection or manual casting required! Not even an explicit generic parameter!

With the way I foresee this working, I can honestly say it looks significantly better than ASP.Net MVC's way of routing. I mean, we're talking FLUENT API cool. I'd dare to say it's also better than OpenRasta's form of routing.

In case you were too lazy to look at that gist. Here is an example:

var blog=router.Controller(() => new BlogController());
blog.Handles("/foo/bar").With((c) => c.View());

Can it read anymore like plain English? I don't believe so. And still, no magic, no reflection, no casting. Just good ol' fashion generic delegates and some neat compiler support for implicit generic parameters.

So, yes, it's a huge breaking change, but your code will suck less after migrating. Trust me, I have about 50 lines of code just for routing for this blog. I don't take breaking changes to routing lightly.

Posted: 2/14/2013 7:17:37 AM

BarelyMVC Roadmap

So, I've been working on BarelyMVC recently and established that there isn't a formal roadmap. I think that's a bit of a disgrace and wish to change that. So, here is the road map target for version 1.0(in order sorta)

  1. Rework to use IServerContext so the entire framework is easily mocked and unit testable(and as a result, the application built on top of it) (note, API should be fairly stable throughout this conversion)
  2. Strive for better unit test coverage(Don't plan on measuring it, but a lot better than right now)
  3. Get session support built into FSCAuth
  4. Integrate CacheGen into BarelyMVC
  5. Documentation and a tutorial or two
  6. Visual Studio and/or MonoDevelop project templates
  7. Compare and contrast document between ASP.Net MVC and BarelyMVC
  8. Setup a CI and/or nightly build server
Posted: 1/20/2013 7:50:03 PM

ASP.Net MVC and BarelyMVC performance comparison

So, I was very curious as to how ASP.Net MVC and BarelyMVC stacked up against each other performance wise. So, I did some benchmarking! I believe these numbers are fairly accurate, but I didn't build a dedicated machine for it, so they should be taken with a small grain of salt.

First off, the two test projects can be downloaded here. It's just two bare-bone projects. It's the ASP.Net MVC "welcome to MVC" type template site, and my recreation of that in BarelyMVC using the standard BarelyMVC style.


  • Arch Linux 64-bit (kernel 3.x)
  • 8G of RAM
  • 2 500G harddrives stuck together with RAID-1
  • Mono 2.10.8
  • AMD Pheneom II X-6 (6 cores)
  • Release mode builds with debugging disabled in the web.config
  • Served using Mono's xsp
  • Barebones sample. No database or other I/O
  • Each test was "warmed up" (I loaded a page before beginning the test, to let things compile where needed)
  • ab -n 10000 -c <concurrency> was the command used

And, here are the fancy charts I made:

Requests/second performance measurement

Time/request performance measurement

As you can tell, BarelyMVC blows ASP.Net MVC out of the water! Big things to note are that BarelyMVC can serve a request in just over 1ms in the best case. ASP.Net MVC needs at least 7ms. Also, an interesting thing to note is BarelyMVC's performance with very high concurrency actually stays kinda sane. A 100ms request is bearable. A 300ms is approaching noticeably slow. I also had the concurrency level of 1000 results done, but they made the graph harder to read. Hint: ASP.Net MVC didn't get better (although BarelyMVC started getting a bit insane as well).

Requests per second is known as a fairly useless metric, but I still think it has some use to show how much load a server can handle in massive concurrent usage.

Anyway, if you're considering making something that has to stand a lot of load and you're open to alternative(ie, non-Microsoft) frameworks, you should definitely take a look at BarelyMVC. It's API is fairly stable now and it's quickly approaching beta status. It's raw and to the metal with as little magic as possible.. but thanks to T4 and lamdas, it's still easy to read, write, and debug. (Also BSD licensed! :) )

Posted: 1/18/2013 4:30:51 AM

The pros and cons of developing a framework

So, as most of you know, I have an ASP.Net MVC framework: BarelyMVC. What some of you may not realize is that the big way I "test" both the design and actual implementation of BarelMVC though is by upgrading this blog to use the latest version. Recently, BarelyMVC has seen some very drastic breaking changes that are finally starting to calm down. Technically, I could keep my blog working how it is as most changes aren't truly breaking. However, the changes I've made have been to make things infinitely easier. To migrate this blog over to use the new way though is nearly a rewrite excluding the data-model.

So, what's so awesome about creating my own framework and using it in my blog in semi-real-time?

  • Something inconvenient comes along. Instead of googling for workarounds, you can fix the core problem then and there
  • See an example of unexpected behavior. See above
  • My blog is basically a live example of the features of BarelyMVC and how to write code with it idiomatically

Now what sucks of course:

  • Breaking changes are common in pre-1.0 releases. Sometimes it can be as drastic as requiring major rewriting of my blog (such as the recent changes)
  • You have no support forum. You are your support
  • Performance can be fun. You have no one to blame but yourself if your site is slow
  • Managing constantly changing binaries in source control sucks

All that said, I'm finally to the point with BarelyMVC that it's actually getting close to v1.0 status. The API has come from "hey use bare ASP.Net stuff for most stuff" to "heres a one line function to do that WITH static typing". Big improvements since I've decided my blog will nearly have to be rewritten are these:

  • Route and POST Form models. Fill in classes from route parameters and form values to access them in a statically typed manner
  • The view engine now includes unit tests and is much less "shakey" (along with a few features and bug fixes)
  • FSCAuth got a "ProbablyLoggedIn" property for use in views. For instance, I'll use it here to display things such as delete links for comments. This prevents having to round-trip to the database for stuff that is only aesthetic and not really a secret
  • Individual methods possible now for each route(rather than one big Get). (note: still no attribute magic and still statically typed)
  • Simplistic constraints on SimplePattern's route parameters (such as must be alphanumeric)

So basically, in the end, my blog's code quality will improve by approximately 20000%. Some examples that have already happened:

  • Significantly less code duplication
  • I can use ONE model for both MongoDB's database and the Form values posted from the edit page. No more Form["Text"] crap

So in essence, it's taking much longer than I expected to make it all happen, but when it's done it'll be awesome.

Posted: 11/25/2012 6:22:04 AM

BarelyMVC -- Awesomeness on a framework

So, I've recently been putting in some really really awesome improvements to BarelyMVC. So much so, that I'm beginning to think it should be renamed because it's not longer "barely" an MVC framework. It still goes by the principal of minimalism, but my second principal now though is as little magic as possible. And also as few "magic strings" as possible in a web framework.

Magic strings I think are quite horrible. Magic strings can take a few different forms. All of them are equally evil in my opinion. Examples:

  • Using Dictionary<string, object> instead of a strictly typed class
  • Specifying method or property names of a strictly typed class as a string for the purposes of reflection and it "magically" working
  • other strings which semantically mean something and can't be changed at whim (ie routing strings)
  • Anonymous classes in some cases are really just magic strings in disguise. Particularly throughout ASP.Net MVC.

Now of course, not all magic strings are avoidable... and of course some magic strings are avoidable, but it'd be a super huge pain to do by static typing. This should be the exception, not the rule.

So, instead of using anonymous methods and magic strings that point to methods, in BarelyMVC I make everything very explicit and statically typed. The only thing close to magic strings are:

  • Route URLs... I actually have a plan to eradicate that problem even
  • Mappings of HTTP POST and route parameters to static classes. It isn't really possible to do this without sorta magic strings.. at least not and your code be easy to read

So, instead of relying on reflection that no one can intuitively figure out, and referencing filenames and methods as strings to keep code as small and "concise" as possible, I make you type a bit more. But, in exchange for typing a bit more, it's blisteringly easy to figure out why things work like they do... and when you decide to refactor and change your method names in your controller to something else, you're not left wondering why it no longer works because if you do that with BarelyMVC, it will give you a good ol' fashion compiler error.

Also, have I mentioned statically compiled and typed views. VIEWS.

Of course, BarelyMVC is definitely still going through a huge metamorphosis to become something really cool to use. It's API is breaking each day right now, but these changes are beginning to get wrapped up(I don't even have this website using the latest version anymore).. However, when it finally hits 1.0, you're going to wonder why someone didn't make such a thing earlier!

Posted: 10/28/2012 1:19:49 AM

Nifty snipplet to fill data into a dynamic type

So I'm trying to put together a fairly major update to BarelyMVC so that I no longer have to resolve strings to their actual types.

I realized that this is an extremely common thing that must be done. Any ORM worth it's weight in salt does this, as well as many other things. So, I'll go ahead and give everyone who hasn't done this a nice starting point. As you can tel, my code is geared towards my router, but easily adjusted. The only big thing missing is a way to specify a custom converter. I'll probably update this code snipplet when I get that figured out.

I decided against containing the code here as I have no syntax highlighting, so check it out as a gist

Anyway, what this will eventually allow is instead of making code like this:

//in an HttpHandler
int tmp=0;
if(!int.TryParse(RouteParams["id"], out tmp))
  throw new HttpException(404);
//tmp now contains a valid integer

instead, you can just create a route parameter model like so:

class BlogRouteModel
  public int ID {get; set; }

and then be able to do something like

Lookup(RouteParams.ID); //contains a valid ID

I haven't figured out the exact way this should all tie together. Apparently generics everywhere isn't the solution as I quit after I would have to somehow contain a list of generic lists with the lists being of a generic type and so on.. It was so fugly.

Also, this same type of convention will be used for HTTP Form variables, so no more parsing of integers and making sure things exist and such there.

Posted: 10/14/2012 12:55:57 AM

Improvements on BarelyMVC

So this weekend I decided to work on BarelyMVC more. I've decided it's nowhere near done(though it is usable). So far I've implemented:

  1. Caching for Route group lists(hint: fairly expensive to generate all of them on each request)
  2. XML documentation so now Intellisense works on most everything
  3. Testing (and fixing) for running under Visual Studio 2010/Cassini
  4. Reworked ViewEngine a bit so now the core code for it is in a separate file(hint: updating is much easier now)

Hopefully tomorrow, I'll have time to implement maybe "type matching" on route variables with regular expressions, and test it under Visual Studio 2012 and maybe Windows Server 2012.

Haven't got this site updated to use the new features yet, but after I do get it updated, I suspect my requests/second capacity will go up by quite a bit.

Posted: 10/7/2012 2:59:49 AM

BarelyMVC Handles Load Like a Champ

So, I recently got published at hackaday (hello fellow hackadayers!). With this, I've received a lot of traffic compared to usual. Along with the joys of being published and people actually being interested in my project, I've found that my website handles load really well. Right now I have about 20 times more traffic than usual. Yet, my server's CPU usage has barely spiked. It did average about 1% CPU. Now it's averaging around 2.5% CPU. I'd say that's a definite success for performance. So, basically this means BarelyMVC should be capable of making very performant websites. Of course, a couple thousand views per day isn't necessarily a ton of traffic, but a 1.5% rise in CPU time for such a large increase in traffic definitely indicates that it scales well.

Posted: 10/1/2012 3:12:37 AM