1. Worrying about the structure of the project and which directory things belong in.
2. Setup for a dev machine, in this case powershell scripts to create a database and some initial base data. I managed to avoid putting together deployment tools, but I have ended up with scripts to create the database.
3. Implementing authentication by hand rather than just using something off the shelf. This was truly a bad idea, but by the time I’d realised it, I was already too far down the rabbit hole.
4. Using a more secure hashing algorithm. While it was interesting to use BCrypt, it wasn’t really necessary.

So the Sql tables look like this:

1. status (status_id, message, date, user_id…)
2. status_view (status_id, date…)
3. status_like (status_id, date…)

This has a direct impact on how the code needs to be structured to support this. Rather than having a repository for each table, it needs to have a single repository interface to cover all of the interactions with status, ie something like this:

Structure

I took the time to split the code up between a number of projects in order to isolate the projects by functional area. I’ve currently got:

1. DataInterfaces – models and interfaces for accessing any data
2. DataSql – the sql implementation of the interfaces in DataInterfaces
3. SiteLogic – the business logic for the application, all code here should be completely unit testable
4. SiteLogic.NUnit – unit tests for the library
5. Site – the MVC site
6. Site.NUnit – the unit tests for the MVC site.

Testing

As far as possible I’ve been wanting to write unit tests for all of the code. Obviously this isn’t possible all the time, for example I gave up on unit testing the controller for authentication. 

1. I want to clearly separate the UI layer from the business layer in order to facilitate adding an API
2. The data access layer might be swapped out with a completely different data backend in the future, so that needs to be separated out. I’m currently thinking that I’ll implement these Entity Framework for the first version. I’ll avoid generic repositories to create a clean interface that doesn’t require implementing a LINQ interface over a NoSql database that might not cleanly support it.
3. I want the Authentication to be clearly separate from the business layer in order to keep this as dependancy free as possible. This tends to be a rather complex area that is well worth ensuring it doesn’t have any dependencies.
4. Cross cutting concerns like logging aren’t covered in this diagram