Backend access pattern (re: Games Library)

Topics: Conventions, Getting Started
Jul 14, 2012 at 10:28 AM
Edited Jul 14, 2012 at 3:02 PM


Has anyone had a look at the “back-end” access “pattern” EisenbergEffect is using in the Games Library example application, i.e. class QueryResult, extension method AsResult, the Backend class, and so on? 

Any thoughts on this approach?

(EisenbergEffect, what is/was your main considerations/concerns when deciding to use this pattern?)

For the sake of argument, let’s assume that a fictinonal project has implemented a set of DataAdapter classes that handles access to e.g. a database. The fictional project also uses DI and would like the DbBackend class (modeled after the FakeBackend class found in the Games Library) to get the data adapters injected. However, this does not seem to be such a good idea, because the DbBackend class’ constructor will grow out of proportions fairly quickly as we add more data adapters to the project (assuming we're using constructor injection of course).

Another smell with this approach is that the DbBackend becomes an all singing, all dancing "master" class with lots and lots of "Handle"-methods.

While writing this post it dawned on me that perhaps the backend class in the Games Library actually is a (kind of) data adapter? If so, this raises another couple of questions:

1) In this scenario, who owns the database connection, i.e. who is responsible for opening and closing the connection? The reason I'm asking this is that there are strong arguments for keeping the data adapters stateless passing the connection to each (data adapter) method that accesses the data base.

2) how do we tell the QueryResult class which adapter to use? In my previous attempts I've used an attribute for this, i.e. marked my xxxQueryResult classes with e.g. [DbBackend] or [AzBackend] and wired up my DI/IoC container (i.e. Ninject) so that it resolves the right backend class based on the attribute used. I must admit that I'm not sure if this is the most appropriate approach though,  especially if the assumption that DbBackend <=> DataAdapter holds.

On the other hand I guess one could go for a convention over configuration approach letting the IoC container resolve this e.g. the same way CM resolves which view goes with which view model.

Thoughts anyone? How have you implemented e.g. db access in your CM-based (production) solutions?


Feb 23, 2013 at 7:19 PM
I have actually run into exactly the problems that you mention. So far only a single backend was planned so for simplicity I sticked with the "FakeBackend". The Backend is now blown up with a large number of Handle methods, but probably have to stick with it. Now that requirements have changed and a webservice comes into play. I see the two choices that you mention: 1) Inject the proper backend into the Queryresult or 2) let the Backend handle the requests delegation to the correct adapters. For the sake of not blowing up the Backend even more, I actually prefer 1). But it would be really helpful to know what @EisenbergEffect thinks.