For a while now, I have been developing my own blogging framework using Microsoft WebMatrix and ASP.NET Web Pages. As these technologies are still in beta releases, I’m not prepared to release any beta version of my own blogging framework. What I would like to do, is share some of my experience writing the web app on this new platform. This is the first post in a series where I will explain some of my experience and hopefully give some pointers and hints.
In The Beginning
Initially I was amazed with the incredible speed and power of the ASP.NET Web Pages Razor syntax and the Microsoft WebMatrix editor, in combination with the new IIS Express. Modifications was super quick to do, no compilation involved, it just worked and it rendered fast. I started out prototyping the web app and wrote lots of code inside the .cshtml files. Even included SQL code straight in the view files, this was the beginning of web development for me when I started out on classic ASP (Active Server Pages). After a while, I moved most of my SQL queries into classes that I kept in my App_Code folder. The Microsoft Data Helpers relied heavily upon the new dynamic type. All methods returned just a dynamic type, which I initially consider to be great and powerful, I could easily extend my types with any additional properties.
It was both easy and powerful to build my web app in this manner, but as my web app kept growing I realized I needed to make some improvements. From early on, I made a very conscious decision to not rely on any ORM (Object Relational Mapping). I didn’t want the requirement to compile or generate any code. Generated code is always bad. So there was no LINQ to SQL or Entity Framework for me… but that was until…
A New Beginning
… Microsoft released a CTP (Customer Technology Preview) for the next version of Entity Framework (EF). And off I went refactoring my code into relying on the Code-First capabilities of EF CTP. Instead of manually writing my SQL scripts, which I had done up until now, I relied on the Entity Framework to generate my tables automatically. Instead of writing SQL statements, I now wrote entity types, just simple Plain Old CLR Objects (POCO). For me, it’s much more natural to write simple C# objects than SQL statements and I get better type safety which avoids some bugs, but obviously removes the benefits of working with dynamic types as I did earlier.
Here is a typical example of one of my earlier entity types:

As I continued with my refactoring, a pattern started to emerge in my code base. I had my entity types, I had my catalog objects (DbContext), I had my static helper methods for all my entities and I still had a bunch of logic inside my .cshtml files to handle new elements, editing of existing elements, deletion of elements, validation of the model (user input) and often some other parts, such as the notification text to display when a save succeeded.
I started thinking that this is pointless, no developer should ever be put to write tedious repetitive code. I have lots of entities that I need the standard CRUD (Create, Read, Update, Delete) actions for and there is no chance I’m willingly going to write every single page for all of my entities. There is not legacy database, no legacy object types and no legacy requirement of any sort in my blogging framework, so I figured it was time to do more by-convention.
Don’t Repeat Yourself
So I started out thinking about how I could avoid repeating myself. I needed a convention for URLs, I came up with this current solution, will possibly change in the future, but for now it sticks:
http://url/Admin/EntityTypeName/View/FriendlyNameOrId
One example then, would be for the authors:
http://url/Admin/Author/View/admin
The type of actions I added was View, Edit, Delete, Create. View was planned to be used in the future if I add permission control that disabled the ability to edit the entity, but it’s not used much in the administration interface. Some of the guidance from REST is added here, but not all the concepts. The Delete action is only possible to do when you do a POST (or HTTP DELETE).
Here is a really simple example on how you can get the 3 input values from the URLs. All you have to do is create an Admin.cshtml file and then the above URL pattern will work just fine. UrlData won’t throw exceptions when you try to access index values that doesn’t exists, so there is no need to validate before you read the URL input.

Final Thoughts
One obvious question would be why I didn’t choose to do this in ASP.NET MVC 3? It already supports the HTTP verbs, good separation of views, models, etc. The simple answer is that I think ASP.NET Web Pages in combination with WebMatrix is simpler and I wanted to do this project to learn the new technologies. I’m already doing lots of ASP.NET MVC development on my daily job, so this was a fun experience to learn something new.
I’m currently researching how I can automate the views for all my entities, by configuration or simply by reflecting over my DbContexts? Right now, I’m investigating with reflection over my DbContext types, I’ll keep you updated in the next part on this blog series.


One of the first things you learn when searching for training material on MVVM in the context of Silverlight and WPF, is that many developers tends to chunk all their View Models and Views into a single project folder. This might work for a small project that has a minimal set of views, but for any bigger projects this will quickly become a mess so my advice is to avoid it altogether, you never know if your project will expand beyond your initial plans.