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
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 <=>
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?