Internal project – step 2 in progress

~ David Cameron

After a bit of a hiatus, I’ve returned to working on my internal project:

I’ve partially completed my initial planned step 2. I ended up spending a lot of time on setup activities, ie yak shaving. I’ve been trying to restrain myself, but it is hard.
Some of the yak shaving activities:
  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.
However I did find something fairly interesting things during this process.

Future plans impact structure now

I was planning to swap out the backend for a nosql database. The aim was for this change to be seamless. However the structures that you might use in a relational database would be different to a nosql database.

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…)
However for a nosql or document oriented database, it would make far more sense to have a single document represent each post, including all the data associated with the post.
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. 

Published by David Cameron

Leave a comment