Design Principles

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.


What is this “Odata”

I have been using Odata services with Dynamics CRM for some time, but would liked to learn the theory and benefit of the technology. This is a high level overview of Odata and I’m looking forward to blog detail explanation of the technology and how it is used.

First will have a brief look into the technologies out there and later we’ll see what exactly Odata. When it comes to building services there are few designs principles that can be used to best represent the services.
1. SOAP: Simple Object Access Protocol
SOAP is all about exchange data as XML and that is part of the goal of interoperability. This is the most popular mechanism to make distributed method calls and it opens an interoperable mechanism for communicating or exchanging data. It also provides a suit of protocols embedded in the data messages. These protocols cover things such as security, transactions, etc. This provides a rich set of metadata or information about the services which indicate what the service provides, so the end users can easily invoke the service. Also these are operation or verb focused such as Insert, Update, Create, Get, etc. In terms of the web all the SOAP messages use HTTP Post only. So you always packaging up the body of the information and posting over the web.