Design Principles

Why logging is important in Distributed Systems architecture?

When we design for distributed systems logging is one of the important thing that we need to consider. Why is it so important? As we all know, when we take a distributed system there are many layers involved and also many third party integrations such as facebook, twitter, payment gateways, etc. All these component together may build your enterprise solution.

So the problem arises when it comes to locate issues within your system. The business needs are changing and new competitors comes up all around the world and no one can rest, sometimes you may get requirements to be implemented over night. So these requirements need to be implemented and deployed to the target users as quickly as possible and we can’t afford to have bugs in these releases as they will end up with catastrophic results to the end users.

Debugging would be an ideal and the apparent solution for this, but believe me if you have several different layers in your solution and some third party integrations, it is not. Because you’ll have to spend hours to locate the locations to put the break points and have to run the debugger several times to identify the issue. This is like brain surgery hard scenario and you can’t spend time one these. And if you have any asynchronous processing and any threads involved, identifying an issue will be more difficult than anything else.


Building your own IOC container – Part1

This article is about to get a good understanding of how an IOC containers works. In real life you don’t have to create IOC containers by yourself as there are many frameworks that can be used, such as Unity, Castle Windsor, Ninject etc. But as a developer understanding the mechanics of this is important.
First we’ll have a look at what is as IOC container is and how it can resolve dependencies. As an example I will be demonstrating the constructor injection.
In basic terms we can think of an IOC container as a framework for implementing dependency injection. This is the fundamental purpose of the IOC container. Apart from that it can manage the lifetime of an object, but here our focus is on the primary feature, i.e. to do the Dependency Injection automatically once we configured it. In the configuration you configure the dependencies so if you have an interface and when you ask for it the configuration will resolve it to the particular concrete type. Also you can use this concrete type to resolve to another type down the class hierarchy. The key concept here is you set up the dependencies and the container will automatically resolve it for you.
So if you ask for IPerson interface and the IOC container will resolve it to an Employee or Student concrete types. In this case any of the scenarios doesn’t know about the dependencies, only the IOC container knows about the dependencies.
Following is a high level visualisation of the implementation of the IOC container.


Hard delete or soft delete?

I have been working on some R&D work and came accross to delete records from the database. So I’ve been thinking that whether to do a soft delete or to do a hard delete. What do you think?
In my point of view, it all depends on the end user requirements. If the transactions are used in pattern analysis by the top management and especially in decision support systems, I think the soft delete would be appropriate. I’m sure that you all know what is meant by soft delete. In simplest of terms it is just using state variable to. When the user selects a record and confirms to delete the record will not get deleted from the database, but a deletion state will be changed to record and other related data appropriately.
But using a soft delete can also cause you more space, because you are keeping all the historical data. For that you could use a separate mechanism for archiving, for example a flat data structure which may use a trigger in the source entity and write the important data related to the transactions to the flat table. After that you can perform a hard delete by using a service or a daily SQL server job to clean up the data in your database with the specific deletion status.
As I mentioned earlier, there are other factors affecting this decision, such as business domain requirements, hardware such as storage and software requirements, cost, etc. Based on these conditions you could provide a better solution. In my case I thought of going with the soft delete and archive important data to a flat table. In this solution I have added an additional column to all tables in the database called “Deletion State”. After that to use a daily SQL Server job to clean up the data with the deletion status equals to an appropriate value.

Published via wordpress mobile

Theory behind MVC (Model – View – Controller)

My greediness to exploring technology drove me to look into ASP.NET MVC technology few months back and started to do great deal of R&D work during that time. So I thought of blogging the things I have learnt so far and the best way to start is to look into the theory behind this.

So what is this MVC stands for Model View Controller. According to the definitions that I followed, there are three components in this as its name defines: a Model, a view and a controller. This is an alternate for ASP.NET web forms. Some high level features of this technology include ease of use, highly testable and light weight. One interesting thing about this is that majority of developers are familiar with this technology and some types of web applications, not all, will benefit from this. On the other hand there could be applications that could use both technologies, but what ever the technology that we use should have a balance between Cost, Quality and the Budget. I’m sure that all will agree that our ultimate goal is to stick to these three pillars.

Let’s have a closer look at the separation of the model. In each explanation that I referred on the web was having the same fundamental illustration as bellow, but I’ll try my best to illustrate it more further on a separate diagram.