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

Habanero Faces has the Capability to Dynamically generate User interfaces. This is a powerful mechanism that if used correctly can result in the developer having to do very little maintenance of his/her User interface and No Dragging and dropping. The way that this is achieved is via Control Mappers. A Control Mapper maps a property or relationship of the Business Object to a Control on the User interface and will handle all updating and communication between the control and the Business Object. Think of it like binding on steroids. For more info on Control Mappers check out the Habanero Wiki  on Manipulating User Interfaces as well as Peter’s article Dynamically Generating User Interfaces.

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 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 testing complex logic typically in the Logic/Services Layer you land up a significant number of your test doubles being simple Stubs (i.e. they are there to fulfill a parameter list or are being used inside the method but are of no interest to this particular test).

In these cases I typically use RhinoMocks (the new RhinoMocks is awesome) to create my Stubs. The problem is that I then have to register my Proxy Stubs with the IOC Container so that the Resolve works. This is just another overhead with testing. I am a firm believer in making testing as frictionless as possible.

Enter the AutoMockingUnityContainer

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.

Peer programming with an Intermediate today and I called my Test Double a xxxxSpy. My Peer immediately asked me why? I quickly ran a survey with several friends who all do TDD and realised that the difference between different types of Test Doubles is not well understood.

Since I am a believer that a common language helps communication I decided to quickly write this blog. It mostly contains references to other peoples excellent writtings on these topics.

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:

I am not going to delve too deeply into the arguments on whether the User Interface should be tested or not. The principles of Unit Testing of User Interfaces are hotly debated in various Blogs. In this particular project I was using a third party control that was returning me a result of and I really needed to test my interaction with this control. The problem was the Control had to be run in STA and most Test Runners run in MTA. This seemed fairly simple since there is a [RequireSTA] in NUnit. Unforturtunately this did worked with some Test Runners but others seemed to ignore this attribute. The solution therefore became to create a Cross Thread Runner.

ComboBox Linker

Ok so I have to admit that I have had to solve this problem several times over the past 12 years of programming. The problem is fairly generic and up untill now there was no general solution to it in Habanero.Faces.

The problem is when you have two combo boxes that are linked i.e. the data from the first combo box filters the data in the second combo box. e.g. Select a Country and you get a filtered list of States for that country.