A Breath Before the Start

Well, I had a friend look at my blog the other day. He is someone who I respect in the technical world, knows heaps, and is just an all round good guy.  (For those wondering, the man is Richard Banks, who you can find here.  He is also worth a follow on twitter, over here.) Anyway, he pointed out some spelling and grammar issues, which I was expecting.  He also gave me some tips and tricks for blogging, like the code colouring and where I can host files without any ads, which I will incorporate I to my last few posts.  I'm not going to tidy every post, just the last two. Hope to do that this weekend.

Then he ended his advice with a “but”. He wanted to know why I was looking at using prefixes on table names, and my thoughts on a "decoupled" application. And he recommended that I review some other patterns, such as the repository pattern. Taking this advice, I did some searching on the web to look into the repository pattern, and as he suggested I reviewed my thoughts and the post content.  Following this, I have decided that he is right (as he usually is).

As a result, I am going to make some changes to my approach.  Firstly, I am going to write an updated version of my audit code.  One without named prefixes, that makes more sense with regards to naming conventions.  (As you can see I am dropping the prefix naming convention on the data layer.)

Secondly, I am going to write a decoupled application in the correctly.  One that has it’s layers decoupled, not the modules within each layer.  This means some changes to my intentions, but I can make that work.  I am still going to maintain the audit functionality in a separate database from the Line of Business database, and I will explain my reasoning's for that when I release a new version of that little project.

Thirdly, I am going to write code that has a designated purpose.  I am going to achieve something that I can use as a vehicle to learn.  It has been said that without vision people perish.  Probably from not having a goal and aimlessly wandering around til they did. I am hoping that with a goal to aim for, I can be more focused on doing and learning rather than wandering down a dark alley.

As an aside, this is the point of me coding and writing blogs about what I am doing and my thoughts on it all.  I am wanting to learn, and I just happen to be in a position where I can ask people to check my blog and code.  If one stops being teachable, stops wanting to learn, then they are, in my opinion, not worth listening to.  I don’t want to be one of those people.  Other than fixing formatting issues and typos, I wont be altering or removing the previous posts.  It is a reminder to me of mistakes I have made to teach me not to make them again.

So, my next post will detail what I am aiming to do with my audit scripts, which I will do try to get out as soon as I can.

Names and Meanings

As you might expect, I am going to use the Autofac IoC container to write a decoupled application the does "stuff". I haven't defined much of what I want this application to do, as I have mentioned in an earlier post, I just want to learn.

One of the things rattling around in my head is how to name the database objects. It seams like something trivial, I mean what's in a name? But names have meaning, and just as with naming children changing them later in life can cause more problems than it is worth!

My options as I see them are to name the objects with names that match the tables or to add a prefix to the table names, still having some semblance to the name of the object. Let me go through my thoughts.

My first option is to name the tables names that reflect the objects they represent. Names like user, settings and individual.  This would help in matching the data store to the entity layer, and any custom queries would be easy to read.

Select * from [user]
    inner join individual on [user].id = individual.id

This is easier to read and understand at a glance.  It returns the user and the individual that it is attached to. Simple.  But here is my problem with that.  I am attempting to write a decoupled application.  What if I want to move one of the parts to another set of servers? For example, if the core of the app gets more use than the rest, then performance wise wouldn't I be better moving it if I could? And I don't just mean the presentation layer or the model, but the data layer also? The problem with this naming approach is that I can't tell, from a data layer perspective, which table belongs to which module.

The second option is to attach a prefix to the table names, which could signify what part of the application it was apart. It turns the earlier SQL statement into

Select * from acsUser
    inner join coreIndividual on acsUser.id = coreIndividual.id

Which is not as readable, but I can tell the module that each part comes from. Now for a simple example it isn't too bad, but for more complex examples it can get rather difficult to manage.

I guess the question is how decoupled do I want the code to be? I was speaking to a friend and he said that a decoupled application was rarely going to be decoupled at the data layer. How many places can afford to have multiple database servers in production (that are not replicated and the like)?

Also, if I decouple the data layer, that can create it's own issues, like how to search across multiple parts of the app? How to maintain data integrity across multiple sources? And another issue, how do I maintain data access security across those different modules?

After much thought, I have decided to write an extremely decoupled app, one where it is decoupled from the data layer up. There are 2 reasons for this. One is that I am doing this to learn how to improve my coding. And two, I like a challenge. So I am going to write each "module" with it's own database, web service, and then write integrative UX environments that bring it all together! So now I need to review the architecture of the app, to make sure that it is in line with this.