Starting a new database project, the most important thing for me is to design it for test. In order to do that effectively, we have to keep the business objects and the data access separate.
This concept is nothing new, but there's a lot of different ways to do that these days.
The first idea I had was to have the data access encapsulated within a DataProvider layer which would be interfaced directly by the application. This would create and return basic DTO objects for the application to play with, as there is little to no business logic in the classes at this point.
Following discussions with my team, this morphed slightly into having the DTOs converted into fully-fledged Business Objects, which would have knowledge of the DAL and access the database in this way.
It seemed okay.... but then I got thinking about how to return a collection of objects, and how all that worked. So that brought me to the
Repository Pattern.
Simply put, the Repository Pattern abstracts the Data Access part from the Business Objects, which means that to fetch an Object, one has to go via the Repo.
There are a number of ways to implement this - doing a search will bring back a LOT of Linq-related implementations.
Right now, I'm going to keep it more in line with the original specification of this pattern. My Repository is simply going to return the Business Objects themselves. At the moment it is read only so there is no need for CUD - because of the way we have separated this we can easily come back to this at a later date.
