In the comments over on my old MVVM Resource List post Peter Rosario asked a great question. A question I thought I’d covered in my video but I suspect I might have edited it out in an attempt to fit into the CodeRage time limits. So I thought I’d answer it here.

The question was about my MenialTasks sample app, and why I’d used TEnumerableBindSourceAdapter to bind my collection of TTasks to the UI, rather than the more common TListBindSourceAdapter.

TListBindSourceAdapter has a lot going for it. It comes “in the box”, would certainly have been easier, and would work just fine. Given that, why didn’t I use it?

The sticking point I had with TListBindSourceAdapter is because it expects to be bound to a TList<T>, and my TTaskList is not a TList<TTask>. Rather, it is a domain wrapper around TList<TTask> (actually a TObjectList<TTask>, but that’s beside the point).

My TTaskList controls access to the underlying TList<TTask>, providing methods like AddNewTask, AddTask(Task : TTask), etc. These functions make sure that any View or ViewModel code that wants to mess with the contents of my TTaskList has to go through my validation logic (or any other code I want).

Using TListBindSourceAdapter would require exposing my underlying TList<TTask> to client code, allowing them to Add, Delete and Insert as much as they like, and I’d be left having to try and react after the fact.

On the other hand, using TEnumerableBindSourceAdapter meant I just had to expose a TEnumerable<TTask>, providing a much more limited set of capabilities to the client, and leaving my TTaskList in control of its contents.

The follow-on question is: was this the right decision?

If this were one of my own projects it would be an easy answer: Yes, totally. My own convictions on how I design my code, and the relative values I place on expediency vs purity mean I would (and do) use TEnumerableBindSourceAdapter in this situation.

However this wasn’t strictly “my” code. Yes, I wrote it, but it’s for public consumption. Further, the aim of this code wasn’t to show someone how I like to design applications, but rather to serve as a minimal example of MVVM. Given that, maybe I was over-complicating things, or putting the emphasis on the wrong areas? Which option served the educational purposes better?

This is what I went backwards and forwards on many times. The code actually existed both ways at various stages. In the end I decided the additional complexity introduced by TEnumerableBindSourceAdapter stank less than exposing my TList<TTask> in my domain object.

Someone much smarter than me once said “Design is Compromise”, and this is the key here. This decision may not be right for you, or even right for me in every situation. We develop in an imperfect world and often you are left having to balance two imperfect options.

That balancing act is the source of some of the most educational parts of the job, in my view.

Anyway, thank you Peter for the question. I hope that answered it ok.