Professional Test-Driven Development with C#: Developing Real World Applications with TDD

ABSTRACTING THE DATA ACCESS LAYER

Most business applications use some sort of data store. It could be a traditional Database Management System (DBMS), a text or binary file, a web service, or some other mechanism for persisting data. Data manipulation and persistence are the focus of most of what you will do as a business developer. But when writing unit tests, it's important that you isolate code being tested, even code that needs to be involved in accessing data. The repository pattern lets you abstract the components of your application that are responsible for accessing external data stores from your business logic and thus create isolated tests for that business logic.

Moving the Database Concerns Out of the Business Code

When .NET 1.0 was released, it featured an update to Microsoft's ActiveX Data Object (ADO) framework called ADO.NET. ADO.NET was not simply a .NET port of ADO; it added many features designed to allow developers to quickly and easily work with classes and objects. As such, early users of ADO.NET adopted a “smart object” architecture in which each class was given the ability to be self-persisting. More often than not this included embedding quite a bit of ADO.NET code within the class itself using either data readers or datasets to retrieve and store data to the database.

Although this did create a code base where developers could quickly and easily develop these self-persisting objects, it caused many other issues. Having the data access logic distributed ...