Table of Content
Awhile back I’ve published my EF4.0 Data Generator and I thought like posting about the philosophy behind some of the decisions I took there and provide some more documentation to make it more useful for developers that want to use it in their work.
There are few generators that are doing almost the same thing, why another one ?
There are few reasons to that.
- The ADO.NET C# POCO Entity Generator provided by Microsoft produces unreadable code so I modified it to generate a more readable output.
- I tried ADO.NET Unit Testable Repository Generator and I didn’t really like it, while testability is great I have my way of doing things and with all due respect I find it silly (explanation below), I just wasn’t satisfied with existing solutions.
- I needed more control over the templates and both of these generators were written in such a way that it’s almost impossible to modify as they are barely readable.
- I wanted to study the materials into depth and so I had to build everything from the ground up, practice it and write it myself to meet my own expectations and choices.
Abstractions and Unit Testable Repositories
Anything on the data layer that execute queries should be tested against a real database system through integration tests and integration tests only, why ?
Ask yourself why are you doing unit tests at all ? to test that the code in question is working as expected, right ?
So you mock the ObjectContext to make the repositories testable and you’re in the assumption that just because the code works and you got yourself a green bar the code will work in production ? you’re wrong.
Your mocked version just used a different kind of LINQ provider under the hood and it may not work as you expect it to work, in the worst case scenario you will have unnoticed bugs or better yet an exception, if you’re lucky.
Different LINQ providers have different functionality and features, even if everything was supported, the abstraction is mainly for testability and has no real value to the application so in my opinion it’s not worth the time and effort.
That’s exactly the reason I chose to use ObjectContext directly in my repositories.
If you want to support multiple database systems or a different kind of ORM you can just move the interfaces of the repositories into another assembly and create a dedicated assembly for each database or ORM that you want the application to support.