Posted by & filed under NoSQL.

Eric Brewer is the man behind NoSQL database design and implementations with CAP theorem. CAP theorem was proved by Nancy Lynch at MIT.

Brewer has given a talk regarding NoSQL history. Worth to watch.

Posted by & filed under Design Patterns.

Even though Service locator is an anti-pattern. There are still many corps using this pattern within their infrastructure with a comment “it works!”.

Here is a simple implementation of Service Locator in C#.

You can enhance Service Locator with Lazy Initialization.

Well if it works out for you and want to keep things simple, go for it. In terms of testability, you can still inject mocks and fakes into service locator. One handicap of service locator is that it hides details from you.

Another major difference between Service locator and Dependency Injection Container is that, with Service Locator there is no Lifetime Management of dependencies.

Posted by & filed under Programming.

MVC 4 has this great feature to reduce http requests by bundling and minification of css and js files.

I used to do this manually or via external program. This is certainly great.

Here is some post about it:

http://www.codeproject.com/Tips/389545/ASP-NET-MVC4-Bundling-and-Minification

bundling and minification will speed up your site by reducing http requests.

 

Posted by & filed under Programming.

Performance is really important part of any application. Everyone wants “fast” applications. “Fast” is not the correct measurement for an application performance however it is thought to be.

Knuth “Premature optimization is the root of all evil”. This is so true. and once you design and program properly you wont really need any optimization.

Anyways. Here is a nice article you can read about .net performance. this also applies to java as well.

http://www.simple-talk.com/dotnet/performance/net-performance-cribsheet/#_Toc198269210

Posted by & filed under Design Patterns, Programming.

A small note to myself on how to configure structuremap with code, including parameter for constructor. You usually need to pass in config files to cross cutting concerns and below is how you can inject configuration to your cross cutting concern.

string config = “someconfig”;

c.For<IFoo>().Use<Foo>().Ctor<String>().Is(config);
c.For<IBar>().User<Bar>().Ctor<String>().Is(config);

Posted by & filed under Design Patterns.

There are several tutorials, and blogs writing about dependency injection, inversion of control, dependency inversion and related concepts. One of the challenge is not only the terminology but also understanding what really dependency injection is all about. For a novice developer to get into dependency injection, folks usually look for a container, use it and expect some magic to happen when they are using the container. However, that is usually not the case and there are several misuses due to not fully understanding dependency injection. It is essential to understand the concept and patterns behind dependency injection before a developer can truly implement it in the application.

First of all, you need to know that dependency injection is quite easy and straight forward. Very easy to understand even though you encounter all these complicated terminology. Moreover Dependency injection will not make your application perform faster or more efficient. But it will give you lots of flexibility for maintainability, testability, extensibility and so on.

If you haven’t read about SOLID principles in object oriented design methodology. please do so and because Dependency injection uses all these principles for a better software development experience.

Dependency Injection is NOT one of the followings, even though you can achieve them with Dependency Injection:
Late binding: even though with dependency injection, you can switch implementation very quickly at run time or compile time easily, this is not what dependency injection is all about.
Unit testing: By using Dependency injection unit testing becomes very easy. Many software companies who uses TDD, prefers using dependency injection because it makes things testable easily. But this is not what dependency injection is all about.
Object factory: dependency injection is not an object factory that you ask for instances and it provides you correct implementations. This is a very wrong assumption and many people fail to understand this. This particular pattern is Service locator which is the opposite of dependency injection.
Object container: Dependency injection is not container. Even though container are here to help us and easy the implementation of dependency injection, it is not required to use a container to implement dependency injection. If you are not using a container but implementing dependency injection, that is called poor man’s DI.

Loose coupling gives the ability for easy maintainability, extensibility and testability. We program to an interface rather than an implementation. Then we face the challenge of where do we inject the dependencies. This is usually done at composition root of the application. Thus we achieve inversion of control. This is what inversion of control is. When you inject dependencies at composition root the control is inverted.

to be continued…

Posted by & filed under Design Patterns, Programming.

In Software development there are set of principles which are called the SOLID principles. These are

  • Single responsibility principle.
  • Open/Closed principle.
  • Liskov Substitution principle.
  • Interfage Segregation Principle.
  • Dependency Inversion Principle.

Single responsibility principle:
While developing software, underlying components should have single responsibility. Benefit of this principle is loose coupling and high cohesion. The component should be specialized doing only one thing.

Open/Closed principle:
With open/closed principle software components/entities should be open for extension and closed for modification. Benefit of this principle is also loose coupling and high cohesion.

Liskov Substitution principle:
While developing software it is highly recommended to program to an interface rather than programming to a implementation. Also known as program to a contract. In this context programming to an interface both contains Interfaces and Abstract classes. Due to polymorphism, you should be able to substitute an implementation with another implementation due to this principle.

Interface segregation principle:
while developing software we said programming to an interface is good. However, it is not quite good to make a single interface and implement that. Interface segregation suggests us that interfaces should be highly cohesive and specialized. Obviously this will provide us high cohesion.

Dependency Inversion principle:
Dependency inversion principle tells us that we should build our software depending on abstractions not implementations which will provide us loose coupling. In this context abstractions means programming to an interface, just to be clear.

This is kinda small summary about SOLID principles. There are many other principles in the same context which will be forth coming.