The Concept of Object Persistance and Object identity have been around for as long as I've been programming (14 years) and probably longer. Unfortunately most systems and most developers in the Microsoft world have been developed using a database centric approach. The flow to Domain Driven Designs has thankfully finally started to flow strong and hard and I find myself spending less time having to argue the merits of DDD with other developers.

However when Consulting I am regularly faced with Database Designs that use AutoIncrementing Fields or mutable properties or even worse composite mutable properties as the Primary Key in the Database.

Example of AutoIncrementing Primary Key. Person has a PersonID : int as the Primary Key and the PersonID is set by the Database when the Person is first inserted into the DB.

Example of a Composite mutable property as a Primary Key. Person has FirstName: string and Surname : string as the Primary Key in the Database. If these are mutable then some sort of Cascade Update is set so as to ensure that all other related tables FK's are maintained as valid.

Now 12 years ago I used to see a lot more of this type of Database Design I still see quite a lot of this today. The reasons are numerous and sometimes inescapable e.g. I am developing with a legacy database, I have an .xxx.. DBA who is stuck in the 1960's. The company has programming standards that were written in the 80's etc.

In this blog I will discuss why I prefer and rcommend using Guids whenever possible or an application generated Integer (when the DBA has an unjustified fear of GUID's) and also how

TDD (Test Driven Development) is an amazing Software Design and Development methodology that revolutionises the way that you build Software.

When Doing TDD you are trying to Isolate your SUT (System Under Test). To do this you typically create Test Doubles (see previous blog) either automatically with a tool such as RhinoMocks or manually (i.e. you hand code the TestDouble).

When using Microsofts Latest addition to the plethora of IOC Container Unity I kept running into the annoying 'ResolutionFailedException' this is a really frightening error with an obscure error message and it is really not obvious what the problem is.

One thing we've regularly needed to do is to load and save objects to multiple data sources. One example where this might apply is when your security objects (users, roles etc) are stored in a separate database to your application database. Another example is where you have application data and user preference data - the application data being stored to a centralised database and the user preferences being stored to a local xml file, and you would like a unified interface where you simply save objects and have them go wherever they should.

In Habanero 2.3.2 this can be achieved with a DataAccessorMultiSource.  Here is an example:

So the new Habanero version (2.3.2) is out, and one of the new features is an improvement in loading collections in the form of an IN operator (and its negative, not in).  This works similarly to how it's used in SQL - in fact it gets translated into a SQL in clause if your Habanero app is running against a database.  Here's an example of using it in loading a set of Person objects:

BusinessObjectCollection persons = Broker.GetBusinessObjectCollection( "Surname in ('Wiles', 'Powell', 'Naidu')"); It's a really intuitive syntax because of its close relation to SQL's in statement.  Also available is the 'not in' operator which does exactly what it says - searches for items not in the given list.

If you want to load using the more type-safe Criteria objects, or you are using code to build up your criteria clause, you can do it like this:

object[] values = new object[] {"Wiles", "Powell",...

So, we are starting to develop a project in an Agile, TDD manner and we don’t really want to be concerned with too much other than this object has this property and relates to some other object... because my test that I’m currently writing needs it. I don’t really care how this fits into the whole scheme of things at this stage. The fact that my “Invoice Line” object can only ever exist on an “Invoice” and that the invoice must be associated to a “Customer” in order to be valid doesn’t really concern me at this stage. Although all those other facts are true, they have no relevance to my SUT (system under test)...