Monthly Archives: May 2014

Framework vs. library

Posted on by

Two software terms that programmers use every day. Yet, if you ask programmers what they are, you will most likely receive different answers from one programmer to another. I found out this the other days asking some of my colleagues and I then realized I have a personal definition for library and framework, which, of course, I consider to be the right definition.

For me, a library is a collection of methods and functions (and even classes or other more exotic structures) that help achieve a result, or solve a problem. The application calls the methods in the library to solve its tasks.
A framework, on the other hand, is the abstract structure of an application. To complete the application, the programmer adds code that customize this framework in such a manner that will solve the applications tasks. The framework calls this code when it needs. A framework typically already contains most or some of the logic and the structure of the application and some special points where custom code can be inserted in the default flow to alter it in order to achieve new functionality. Sometimes, framework are very complex and might include programming languages or compilers.
FWVSLIB2

 

And I think that if we look at some examples, the things become quite clear:
  • C Runtime Library – contains functions like sprintf that a programmer can call to format a string.
  • 7-zip compression library – contains functions that a programmer can call to compress or decompress files.
  • ASP.NET is a framework, because you only provide a few missing pieces to the barebone to have your web application.
  • Spring – a framework for Java applications. Again, the programmer just writes some of the missing pieces, the framework does the rest.

Book: Dependency Injection in .Net

Posted on by

Dependency Injection in .Net by Mark Seemann

I must say from the beginning, this is definitely one of the best book I’ve read about programming. I found the book written so well that I think Seemann reviewed the text at least a hundred times and fine tuned each phrase to obtain the perfect whole.
The thing I liked the most about the book was that the information was very well structured and presented in a very logical way. The second thing I liked it was the fact that once I started reading, I couldn’t let it off my hand until I read it all. And I like that on a book.
Going through the content, the book is made In Part 1, the author explains what DI is, why it is useful and shows some DI examples: a simple one first, but also a more complex one, because it is the complex and large projects where the DI becomes extremely helpful. Despite being complex, this second example is quite easy to understand because is constructed based on a (kind of) real life discussion between programmers.
Part 2 is all about how to do and how not to do DI. These are presented as patterns (constructor injection, property injection, method injection and ambient context injection) and anti-patterns (control freak, bastard injection, constrained construction and service locator – and I know there is an ongoing discussion here about the service locator being good or evil, but Seemann makes a pretty damn good point about it in the book).
Part 3 goes a step further and, in order to better assimilate the concepts, it shows how you can create your own DI container. This will guide the reader between all the aspects and the problems DI faces and explains how to address issues like object life time, object creation interception, cross cutting concerns, etc. There is also a chapter about object composition when working with some of the most important .Net technologies (ASP.NET, WPF, WCF).
In part 4, each chapter is dedicated to one of the most used DI containers: Castle Windsor, StructureMap, Spring.NET, AutoFac, MEF and Unity. These chapters are not detailed references about the containers, but are there more to give the reader a feel about how using one container or the other might be like.
Now that I showed a little bit what subject the book touches, I must say that I can’t emphasize enough how much I enjoyed the way in which this information was presented: simple, with reminders, with case studies, with well-made arguments.
I strongly recommend this book to every .Net developer, even to those who are already using one of the DI containers available for .Net; they will better understand the concepts and will find about alternatives to the container they are already using. And for those who never used DI before, this is definitely a must read. You will see programming a lot more different after reading it.