You have a large project with many interfaces and many different concrete implementations. Because of this, managing every single Ninject binding is becoming challenging and time consuming.
By leveraging an additional Ninject NuGet package called Ninject.extensions.conventions, you can write a single line (wrapped over several for readability 😉 that will manage all of your Ninject bindings.
I’ve only been doing TDD for a few weeks, but I’m completely sold. I don’t want to go back! I’ll be honest though, it hasn’t been easy. I’ve made mistakes, I’ve wasted time, but I’m really starting to reap the benefits.
I’ve always thought I was a good developer. I write decent code and it works mostly as expected. It took me many years into my career before I wrote my first unit test. It always fell into the category of too time consuming or expensive. Oh the irony!
As I started learning how to write to unit tests, I always found myself rewriting things I already did just to get them to be unit tested; how frustrating! A unit test that should have only took a few minutes, ended up taking a really long time because the code had to be refactored just to be tested. No better way to turn you off from unit testing.
Enter test-driven development…
I hate typing more lines of code then I need to; especially something as simple as mapping a domain model to a view model. Enter Automapper!
By performing a one-liner: [code] Mapper.Map<Customer, CustomerViewItem>(customer);[/code] I can quickly map my domain models to my view models.
I was recently reviewing an old article on CodeProject: http://www.codeproject.com/Articles/61629/AutoMapper that contains a quick and easy demo. Inside this article, it discusses performance and it indicates that Automapper is 7 times slower than manual mapping. This test was done on 100,000 records and I must say I was shocked.
My first thought is this requires more testing. Especially since 100,000 records is a lot. In most scenarios I would estimate my largest mapping might be 1,000, but even 1 would probably be a very regular use-case. Let’s put it to the test…
After the incredible reaction to a recent blog post, Entity Framework Beginner’s Guide Done Right, I feel like before writing some more code to further the basic example, I’ll take a step back and explain my beliefs in the repository pattern.
I was really overwhelmed with the reaction; what started with a simple 30 minute blogging effort has turned into something absolutely incredible. The original post was really a starting point about not placing direct querying and saving to the database mingled with the core code.
Please note, these are my thoughts on the pattern based on current and previous pain points that I’ve/am experiencing and I’d love to hear others input in making things better.
Entity framework is a great ORM provided by Microsoft. There are a ton of examples of how to get up and running with it really quickly. The only problem with all of them, is the get you off on the wrong foot.
In all of the EF example guides, the DbContext class is typically deeply embedded into the core of your code. This of course is great for Entity framework because the effort to change will be next to impossible – speaking from experience of course here.
Instead, by making some subtle changes we can integrate Entity framework in a separate layer in case at some later date you wish to replace it. Of course, you might never need to replace it, but following these simple techniques will allow better segregation of code and even provide simpler unit testing.