I’ve been reading Chapter 11 (Testable Design Patterns) in the Professional ASP.NET MVC 1.0 book. In the examples in this chapter, data access is split into a number of repositories: IOrderRepository, IProductRepository, etc. That all makes sense: a single repository for a single class of data.
However, this breaks down somewhat for me when you consider the links between the tables: an Order contains a number of Products. When the Order class is created by LINQ-to-SQL, the order class will have a Products collection that enumerates all of the products related to that order. So by using this collection we’re bypassing the ProductsRepository.
Therefore when mocking, I’m going to not only have to mock the OrderRepository and the ProductRepository, I’m also going to have to populate the Products collection in the returned Order objects. Which means that the mocked OrderRepository has to know about the mocked ProductsRepository and so on.
It seems a waste to ignore these collections that LINQ so kindly created for me, so my question is, in this case wouldn’t a single repository make more sense?
Other factors to consider include the likely lifespan of the product and the likelihood of having to change from LINQ-to-SQL to some other O/R mapper at any point in the lifetime. The smaller the project, the less critical the product, the less you need to worry about abstracting minutae to the nth degree.