Advanced Automatic Ninject Bindings

Published on Jan 13, 2014 by Jamie Munro

Problem


You have a common interface that is used by multiple concrete classes and you donít want to specify each Ninject binding manually.

Solution


The solution to this problem is very similar to my previous post on Automatic Ninject Bindings because it also leverages the NuGet package Ninject.extensions.conventions.

In this example, letís assume you have a single interface called IService<T>.† This interface contains a generic reference to a class or object (e.g. a database model).† Then you have multiple classes that implement the interface.† E.g. UserService : IService<User>.

With the following line of code, all of your classes that implement the IService interface will automatically bind to the corresponding class:


 ††††††††††† var kernel = new StandardKernel();

 ††††††††††† kernel.Bind(x =>

 ††††††††††† {

 †††† †††††††††††x.FromThisAssembly()

 ††††††††††††††††††† .SelectAllClasses()

 ††††††††††††††††††† .InheritedFrom(typeof(IService<>))

 ††††††††††† ††††††††.BindSingleInterface();

 ††††††††††† });

 

Read more >

Tags: Uncategorized | ASP.NET | c# | mvc | ninject

Automatic Ninject Bindings

Published on Jan 7, 2014 by Jamie Munro

Problem


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.

Solution


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.


 IKernel kernel = new StandardKernel();



 kernel.Bind(x =>

 {

    x.FromThisAssembly()

    .SelectAllClasses()

    .BindDefaultInterface();

 });


Read more >

Tags: ASP.NET | c# | mvc | ninject

Automapper Performance Testing

Published on May 27, 2013 by Jamie Munro

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:
 Mapper.Map<Customer, CustomerViewItem>(customer);
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Ö

Read more >

Tags: Optimization | ASP.NET | c# | automapper

Why the Repository Pattern

Published on May 20, 2013 by Jamie Munro

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.

Read more >

Tags: ASP.NET | Theory | c# | entity framework | repository

Entity Framework Beginnerís Guide Done Right

Published on May 13, 2013 by Jamie Munro

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.

Read more >

Tags: ASP.NET | Theory | c# | entity framework

The Best Way to Prevent SQL Injection

Published on Sep 19, 2012 by Jamie Munro