Stacking Code

This is post #2 in the Building Neno series. Please click here for a description of the Building Neno project and instructions on how to access the source code for this post.

I'm starting the domain model for the new blog. Right off the bat there will be some abstractions which will need to go into the new framework, so I've created a new solution and repository for the framework which I'll call Moja. (The blog engine is called Neno if I didn't mention it before.) Since the development of the two will be side by side for some time, the Moja projects will be included in the Neno solution to make life a little easier. If you want to follow along, you'll need to have your Neno and Moja solutions in adjacent directories.

You can find the repositories for the two solutions here:

• https://bitbucket.org/stackingcode/neno
• https://bitbucket.org/stackingcode/moja

The code as of this post will be tagged 2010/11/25/domain-model.

Entities

I know this domain model will be persisted to a database, so there's a couple of things every domain object will have to have. An Id and a Version property. The Version property is used for optimistic concurrency -- it will stop users from writing over changes made by each other in the event they're working on the same data at the same time. Rather than type those two properties out for every domain object, I'll make an IEntity interface and an abstract Entity class in Moja that the domain objects can implement or inherit from.

A Blog Defined

It's time to define the domain model for my blog, so back to Neno... I want to keep it as simple as possible right now because I want to get the basics up quickly. I'll need posts, tags and comments, and the actors will be commenters, authors and administrators.

I would like commenters to be able to log in and leave comments. I may allow anonymous comments also, but I'm not sure yet. Authors and administrators will definitely have to log in before doing anything special. I'm going to lump commenters, authors and administrators together into one class for now, User, and see how that goes. I'll refactor it later if it needs to change.

Despite being in the domain model stage, I still need to think about how users will log in. In corporate intranet land this is normally a non-issue thanks to Windows authentication. This is on the net though, so authentication will have to be some flavour of forms authentication. I don't want to use ASP.NET Membership as that will tie me to SQL Server, or mire me down with custom providers. I don't really want to store usernames and passwords at all to be honest. Wouldn't it be great if there was a third party on the net that could handle authentication for me? Well there is. OpenID will let me pass off authentication to any OpenID provider out there and will save me from having to implement passwords, salting, hashing and all that time sucking minutiae. Most people already have an OpenID (whether they know it or not), so I don't think this will be too hard for users to get their heads around... At least for a technical blog.

I'm not exactly sure how OpenID will work just yet, but I do know users can have multiple OpenIDs, so I'll make that a collection on the User class for now.

Assemblies

You may have noticed that the domain model is going in the StackingCode.Neno assembly and not in the StackingCode.Neno.WebApplication assembly. That's because I consider StackingCode.Neno to be my application and StackingCode.Neno.WebApplication to be just a UI. I don't want to tie my domain model to any one UI. More on this in later posts.

Prepping for NHibernate

NHibernate works with POCOs, but there is one caveat if I want to take advantage of lazy loading... All my properties and methods on my domain classes will need to be virtual. This helps the proxy factory out and it's a small price to pay to work with domain objects instead of recordsets.

NHibernate also needs a no argument constructor on each object so it can create instances when it needs to. It doesn't have to be public, but it can't be private. As a result, my Post and Comment classes get a protected no argument constructor I wouldn't otherwise put in.

Iesi.Collections.Generic.ISet is a holdover from my early NHibernate days. NHibernate will work with IList of course, but ISet has given me less problems over the years and "just works" in most situations. If it ain't broke, don't fix it.

Validation

NHibernate has its own validation library, but I don't want to use it as that would give the impression of tying my domain model to NHibernate. Even though I believe it can be used independently of NHibernate, it doesn't feel right having an ORM related assembly referenced at the most basic level. There are a number of good validation frameworks out there, all of which can work with NHibernate, but at the moment I prefer System.ComponentModel.DataAnnotations. It's simple, easy to extend, and has the advantage of being inbuilt to .NET. It integrates nicely with ASP.NET MVC 2 out of the box too.

That's it for now. Nothing is hooked up to the web application yet so this post will be done in XML again.

Edit: It was actually done on an iPad in the standard Notes app using the Markdown syntax. ;) But it will be copied to posts.xml for publishing.