Showing posts from March, 2009

IoC Container Vs. Service Locator

I had a conversation over the weekend with one of my colleagues because I didn't understand the difference between an Inversion of Control (IoC) container and a Service Locator. After our twitter conversation, I had to go back and read the article by Martin Fowler on the topic. Although the article is dated, it provides some valuable information. That information along with my colleague's information clarified the difference.

The confusion was mostly because both tools provide similar services, both provide run time resolution of dependencies. Also when improperly used, an IoC container can be used in the same fashion as a Service Locator can- as was the case in one of my former projects.

Before I get going too far, let me explain what I mean when I say "run time resolution of dependencies". In order to write testable code in OO we have to write classes that are loosely coupled. No coupling at all would be optimal (for testability), but as any programmer knows, that is…

Using KISS with Demos

I recently prototyped a simple application to see how the simplest form of posting and receiving messages using MSMQ worked. The prototype was a simple WinForms application with two buttons - one for post and one for receive - and a rich textbox to log the activity. All of the logic for the process was in the event handlers for the two buttons. There was no MVP, no separation of layers, no unit testing. The whole form file was no longer than maybe 80 lines of code.

I showed the demo to one of my colleagues and he shook his head in disappointment. Being that we have recently paying attention to the craftsmanship movement on DDD, BDD and the like he asked "Where is the MVP? Where are the unit tests?". I proceeded to explain to him that it was all a simple test that I wanted to perform and I didn't want to clutter my code with unnecessary complexity. Besides, the code was very straight forward and did nothing useful other than demonstrate how to post and receive trivia…

Reasons to Stay Away from CSLA

We've been using CSLA - Component-based Scalable Logical Architecture in a product for approximately one year and while it solves quite a few problems it violates some major good practices.

No Clear Separation of Layers

While at the time that we chose CSLAwe knew very little about domain driven design, it is no excuse for the framework to possess the data access layer within the business object. This makes it extremely difficult to separate the concerns. As a result, it is difficult to mock the data-access layer creating many problems when attempting to perform unit tests. This also puts the additional responsibility of data access on the business object class, violating the Single Responsibility Principle(SRP). Data access layer should be totally separated from the business object period. Having the data access within the within the BO class is not the only additional responsibility placed on the class but is the most significant one I can think of.

No Context Validation

In the CS…