Помните, у Урсулы Ле Гуин в «Волшебнике Земноморья»: «Никогда не спрашивайте человека о его имени. Никогда не называйте своего». К сожалению, Entity Framework «из коробки» совершенно не руководствуется этим замечательным правилом, и при генерации классов на основании схемы базы данных (стратегия Database First) именует классы, свойства классов и навигационные свойства именно так, как именуется соответствующая таблица в БД.

А что делать, если есть задача разработать новый проект к уже существующей базе данных, в которой таблицы именуются по некоторому шаблону, скажем, по шаблону t_tablename (напр. t_order_product). А в проекте принято совершенно другое соглашение об именах, и разработчики желают видеть «человеческие», с их точки зрения, имена (OrderProduct). Конечно, можно выкрутиться из ситуации, приняв соответствующее административное решение, однако иногда очень не хочется идти наперекор чувству прекрасного.

Итак, мы открыли для себя Dependency Injection, уяснили все его плюсы и несомненные пользы и начали вовсю применять его в своих проектах. Давайте посмотрим, что же еще можно делать при помощи Dependency Injection на примере библиотеки Ninject.

Для работоспособности кода нам понадобится, помимо непосредственно Ninject, установить еще три расширения: Ninject.Extensions.Factory, Ninject.Extensions.Interception и Ninject.Extensions.Interception.DynamicProxy. Эти расширения доступны в NuGet с соответствующими идентификаторами.