I try to lower expectations in order not to be disappointed, but in this case I was asked by several individuals to address the fact that IoC container power is in the ability to “hook” implementer with the contract through an external file, leaving application code unaware of the actual implementer till the run-time, having no reference to implementers’ assembly or whatsoever. I am going to expand the sample from the part 1 post to achieve that goal in a couple of days.

I was exposed to an interesting product from innotek called VirtualBox. If you like MS VPC or VMWare, check this one out. It's free, it's not bad (so far I was just playing with it installing Windows XP and running some applications on a quiet slow host machine). Would love to hear others comments on this one, or any other alternative that is welcomed.

In a multi layered application architecture, loosely coupled code is more than a important. It’s the basic which can either help the entire project progress, or drive it down the slope to the end (in the bad meaning of the word). One of the basics to keep coupling as low as possible is Inversion of Control (IoC) container.

I will try to show how to put in place a simple version of IoC container to allow loosely coupled design. The solution will contain several projects to emulate a layered application as much as possible. The choice of console application is only driven by intent to keep it as simple as possible.

Mr. Mo has wrote a nice post about securing collection and turning it into an immutable object. I am adding my 20 cents by reminding a great example JP Boodhoo has showed during his “Nothin But .NET” training session, leveraging ReadOnlyCollection class to make a collection immutable.

Lately I am paying more and more attention to aspects of Domain Driven Development (DDD), development where code is looking more at the domain in which it is trying to resolve problem(s), rather than technologies it is using. One of the biggest headaches that you getting into when trying to adopt DDD is persistence. Normally persistence is done in Relational database such as SQL server, Oracle, or another vendor database. And this is exactly the problem - Object Oriented model vs. Relational Data model. So what is more important, a software that is written in DDD way,  that forces you to put DB on a lower priority, or DB efficiency as a priority pushing your software from Domain driven development to become a Data Driven development? If you asking me - domain is more  valuable. I will show an example that to me serves the best proof for those who still try to save the “extra round trips to DB” or “we could combine the queries and have a single call to the DB”. Keep in mind, I am not going against DB efficiency, after all a sloppy data access can kill the best application out there. But having a great data access model will not make you application writing easier, on contrary.

Understanding what are you working on is the priority #1. If you not sure, then you don’t know what are you working on. How do you keep several items linked logically while working on them - you try to keep something common between them. To be more particular, I will bring an example of an application I was exposed to with my team, and show several approaches, including the one I am so against.

I was looking at anonymous delegates today in .NET 2.0 and thinking how much “syntactical noise” it has and how clean and delicate it is with Lambda expressions. Remember though how it used to be?

Looking for some feedback from ASP.NET community - are you using ORM mapping tool and how disconnected your business logic from the persistence during initial development?

To give a hint, I was looking at NHibernate, Microsoft Entities Framework, and in-house grown entities framework based on DB schema-first as opposed to the pure ADO.NET direct access. Thanks.

This is a non-technical post (contains no code).

“The size of disappointments is proportional to the size of expectations.” – translation from Hebrew (גודל האכזבות כגודל הציפיות). This is one I have to write down and stick in front of my eyes. I was expecting my team members to pick up the bug I got not so long ago on doing unit testing, TDD, DDD, Patterns and Principles, automation, pragmatic approach, etc. As much as I was expecting them to pick up the stuff and run with it, that much I was amazed to see that it is not going to happen. What is my conclusion? Don’t over-expect (as over-design), don’t ask what-if, act based on what-now. And the most important - don’t have expectations for others, only for yourself.

The goal of the application is to allow specifications for search (criteria’s) to be specified by the client in order to perform a custom search. Figure 1 demonstrates the requirement. I intestinally keep it simple for the sake of the exercise.

Where do I start?

This is probably the most difficult question – where do I start? From the beginning, of course. I will try to make it sort of TDD way, and keeping the Agile concepts in head to respect some of the OO principles I have learned lately – no over-designing.