In this post, we will extend the query functionality to handle stored procedures with parameters. To do this we need to create a new query type interface with an example implementation: Now that we have the ability to create stored procedure queries we need something to handle them. To do this we need a concrete implementation of the interface “IHandleAQuery”: Finally, we update our factory to handle the new query interface and return the correct . . .
In part 3 we created a SQL repository object that took a populated instance of IQuery to select/return an enumerable list of objects. A limitation of the repository was that the query had to be text-based, it couldn’t handle stored procedures and/or parameters. By incorporating an abstract factory pattern we can extend the functionality to handle different types of query. The original code inside “SqlRepository.Get(…)” needs to be changed from: To: The static factory class . . .
In Part 1 of this series, we started with a basic Data-Reader / SQL Connection/Command pattern and illustrated how it is possible to abstract the parsing of the Data Reader into a standalone object that can be fully unit tested in isolation of the calling code. In Part 2 of the series we made a very simple optimisation to the “DataReader” convertor and updated the tests to capture/verify the changes. In part 3 of the . . .
In Part 1 of this series, we started with a basic Data-Reader / SQL Connection/Command pattern and illustrated how it is possible to abstract the parsing of the Data Reader into a standalone object that can be fully unit tested in isolation of the calling code. In Part two of the series, we will highlight a very simple optimisation that can be made to the “DataReader” convertor and the required update to the tests to . . .
Recently we’ve been looking at improving our unit test code coverage and reducing the amount of duplicated code around our bespoke data access layer. Where possible we have moved over to NHibernate but certain parts of the data access must still be written using the standard ADO.NET connection/command pattern. Typically hidden right in the middle of this bespoke code is a while loop that is pivoting a data reader into a POCO that is impossible . . .