IoC и .NET Framework

Question

Я хочу знать, как лучше всего использовать шаблон IoC при работе с .NET

Например, следует ли мне создать SqlConnection / OracleConnection или любого другого провайдера через контейнер IoC или с простым новым ключевым словом?

Имеет ли какое-либо значение разделение моего класса на конкретные типы поставщиков (в том числе, когда я хочу использовать только один тип поставщиков)?

Answer 1

Обслуживание кода - это больше, чем просто замена одного провайдера на другого.Для меня внедрение зависимостей больше связано с сохранением кода логически разделенным и, следовательно, более легким в обслуживании, чем с проверкой на будущее кода в течение дня смены поставщика.

DI также позволяет вам повторно использоватькод из одного проекта в другой легче, потому что это делает зависимости между различными частями более явными.

Тем не менее, я никогда не использовал контейнер IOC, и я никогда не видел необходимости в одном, поэтому яне может комментировать этот аспект вопроса.

Но вам определенно следует как можно больше удалять неявные зависимости из вашего кода, просто для того, чтобы код можно было многократно использовать, поддерживать и корректировать.

Answer 2

Внедрение SqlConnection или IDbConnection было бы довольно бесполезным, потому что DbConnection - это дырявая абстракция. Вы можете использовать его только для вызова хранимых процедур или простых запросов типа SELECT * FROM VIEW. Любые более сложные запросы будут отличаться для каждого диалекта SQL.

У вас будет лучшая смена преуспевания, когда вы будете скрывать соединение за абстракцией более высокого уровня, например, IUserRepository или чем-то еще Реализация по умолчанию этого интерфейса, вероятно, будет SqlUserRepository, который будет взаимодействовать с MS SQL Server, или OracleUserRepository, который будет взаимодействовать с Oracle.

Еще лучше было бы отойти от низкоуровневого API ADO.NET DbConnection и перейти к O / RM, такому как LINQ to SQL или Entity Framework. Тогда у вас, как правило, будет LinqToSqlUserRepository.

Обратите внимание, что в этом случае я все еще говорю о XXXUserRepository. Интерфейс до сих пор не изменился. Другими словами: IUserRepository не является утечкой абстракции. Вы можете заменить этот интерфейс для модульного тестирования, хотя это вряд ли возможно при использовании SqlConnection.

Answer 3

Может иметь значение для модульного тестирования, если вы используете IDbConnection и все другие классы вместо конкретных классов.

Кроме IOC и тому подобного, я на самом деле использовал DbFactoryProvider ( немного больше информации ) несколько раз для создания моих соединений и других связанных с БД объектов,и прочитайте провайдера через ConnectionString.

Основная проблема с базой данных заключается в том, что обычно вы не можете использовать только ANSI-SQL с базой данных, поэтому, пока вы отделены от конкретных классов, ваш sqlне транспортируется(ограничение i / e в MySql или Over и Partition в Sql Server).

О DI / IOC с другими вещами, не связанными с БД, здорово разделить ваши классы и удалить зависимости, а также помогает при модульном тестировании,скажем, если у вас есть служба, с которой вы работаете. Это полезно, даже если вы не участвуете в модульном тестировании, когда вы работаете против службы, а другая команда все еще разрабатывает службу, вы можете создать поддельную службу, которая в основном решает ваши проблемы (невсе) так что вы можете работать против чего-либо, прежде чем настоящий сервис станет доступным.

Примеров гораздо больше, но работа с сервисами (хранилище БД / web / авторизация / что угодно) является первой наиболее простой добавленной стоимостью.

Answer 4

Хорошей практикой будет использование IoC даже для классов .NET.Это позволит вашему коду быть привязанным только к интерфейсу или базовому классу, если он доступен.Кроме того, вы можете использовать свою инфраструктуру IoC для указания аргументов конструктора.Это может быть полезно для строк подключения в SqlConnection.

Следует также отметить, что использование IoC и запись кода только для интерфейса значительно упростит модульное тестирование.Это особенно верно при работе с соединениями с БД.

Answer 5

IOC существует, так что, хотя вы хотите использовать один тип провайдера в реальности, когда-нибудь что-то изменится, и вам может понадобиться дополнительный адаптер, поэтому лучше использовать IoC вместо создания объекта с использованием нового ключевого слова. IoC позволяет гибко менять вещи с течением времени (по мере изменения требований).