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

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:

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.

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.

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)

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)

Strive for better unit test coverage(Don't plan on measuring it, but a lot better than right now)

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.

Platform

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)

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! :) )

So, I finally have CacheGen to where I can probably integrate it into this website. I did some rough concurrency testing (spawning 60 threads accessing the cache with random clearing). It's a rough test, but it does show that there isn't anything obviously wrong with it at least.

So, the code it generates is brilliantly simple as well. Some good use cases for this:

Keep all your cache settings in one place

Statically typed and named! No more remembering manual casts or magic strings

Make your caching logic testable! It generates code against an easily mockable interface

Switch out your caching layer with ease.

Now, I'm only going to elaborate on the last point. "Why would I ever want to change out my caching layer!?"

Here's why. You built Bookface 1.0 and a few dozen users are on it. People start talking though and suddenly you have a few thousand(or more). You page response times have crept up into the seconds range. Something must be done. After upgrading servers, and expanding some of the hardware, you find the bottleneck. Your web server's caches are being cleared too often. There isn't anything you can do though, the memory is maxed out as it is. So, obvious choice: Use something like memcached for distributed caching on a dedicated server or two.

What's makes using memcached or something so hard? It requires code changes! Luckily for you, you used CacheGen though. Why? All of your caching is in one place, and your interface to the caching method(CacheMechanism) is in one single simple class. It's trivial to implement a two-level cache between ASP.Net and memcached at this point and all of your code relying on your cache will just magically work without being changed.

This is what I think makes CacheGen especially awesome. It manages your caching settings, makes everything statically typed, AND lets you have an almost unreal amount of flexibility.

It's not quite ready for primetime yet. I've proved that it should work, the thing now to do is clean up the API some and add some more unit testing to see if I can catch more bugs.

Anyway, I don't expect this process to take too long. I plan to tag an alpha release for this relatively soon (within the month)

Well, I'm announcing it finally. I've broken out the Authentication module from EFramework and I'm going commercial with it(after fixing quite a few things and extending it). If you still have a copy of the BSD licensed code, I ask you kindly to buy a commercial license. But of course, I can't force you to. I can't retroactively remove the BSD license afterall.

Anyway, I need beta testers! What is FSCAuth? Well, it's a very handy authentication module for ASP.Net. It works on Mono/.Net/Webforms/MVC/You name it. And it's easy, even after the initial "hey a user can login" phase. It's designed to be customized and works well no matter what your database is. Like GUIDs as a unique ID? Go ahead, use em'! Prefer integers instead? You can use those too!

A quick summary:

My nemesis is Forms Authentication. Why? Well, because I don't like writing 200 lines of code just so I can use something other than the crappy SQL Server Compact database. Or heaven forbid you want your database to be halfway clean without 50 stored procedures(which do nothing) littered in it.

My target audience is small and medium size web applications.

I find it a breeze to work with. This blog uses it(in a hidden form)

If you are interested in beta testing, please send me an email at earlz at this domain name(lastyearswishes.com). Beta testers that give me feedback will get a non-expiring single-site license when the project is released. The few that give me outstanding feedback will receive a non-expiring multi-site license. In your email please include "fscauth beta testing", a little about yourself, and how you will beta test it(for instance, are you going to put it in your own blog? etc)

Demo Application

Also, if you'd like to see a small demo application you can look at fscauth-demo. It uses an in memory list of users and is limited to 100 users. But you can see the hashes for everyone's account and try hacking stuff.

Below is some more information about it. NOTE: Some of this is not yet implemented(MongoDB and SQL Server UserStores particularly). This is a projection! Some of these features may change or be removed completely.

What is this?

This is a very easy to use authentication module for use in ASP.Net. It's been designed from the beginning to be flexible, but requiring as little setup as possible. It can be used for any database/data store imaginable. I provide as an example 3 different datastores implementations

SQL Server

MongoDB

Generic in-memory list

Why use it?

Well, I created this because I thought ASP.Net Forms Authentication required too much work for simple systems. I wanted something easier, but also more secure out of the box.

Easier?

For setup you only have to populate 2 fields, and call an Authenticate method from Global.asax. After that, you're ready to show off awesome code like this:

//Some secret stuff you don't want to show to people
Authenticate.RequiresInGroup("secret");

or even

if(Authenticate.LoggedIn){
//show something only logged in people see
}

Security?

Right from the beginning Fast, Secure, and Concise Authentication was designed to be fool proof for security. It was designed to be secure enough that even if a dump of the database behind it got leaked, your user's credentials would be safe, and hackers would still not be capable of logging in. By default, all passwords are SHA256 hashed and salted. All login cookies are impossible(or almost) to forge.

Don't take my word for it though; check out the source code. With every license but Personal No Commercial, full source code is included. The source code is not overly complex and at the core is only a few hundred lines including comments. If you look at it and think I did a horrible job, then return it. Binpress offers a 14 day money back guarantee.

Speed?

Of course, authentication is a core part of a website, so it needs to be fairly fast. Speed was actually the lowest priority of the project, but actually, it's still very fast. The only operation requiring more than one database access is adding a user, and that is only for ease of implementation. On each authentication, there is a total of two hashes computed. With SHA256 this equates to microseconds. This will not be the component that slows your website down.

Also, there is no need for a persistence of session state. So no extra memory used on your servers, nor messy tables in your database. This is what I like to call a "stateless" authentication system.

What's Capable?

Notably, this project does not try to implement everything that is in Forms Authentication. If you require Windows Authentication, or complex Member/Role/Task/Group support, then maybe you should stick with Forms. This is designed rather for the 90% of websites out there that just need a simple user login system with maybe a few groups, and don't want to mess around with writing 200 lines of code to do it.

Well, I'm trying to get EFramework to work together with webforms. As you can tell, it's not working so great. Everyone just says "oh just use Context.Rewrite". Well, I'm sorry to tell everyone, but that doesn't do shit.

Basically, I've managed to get it so that everything is good on the client side. Friendly URLs are used in form tags and friendly URLs are used by GET requests. But the problem is postbacks. Basically, I add a button to the page, I attach a click handler, and then I click said button... and nothing happens. The page will POST as normal, the Form field is even filled in Request.. but for some reason, ASP.Net refuses to set the IsPostback property and call my button's click method.

Why? Well, I have no idea. Everyone says it should be working, but it isn't.