Это может показаться очевидным для большинства людей, но я просто пытаюсь подтвердить, что внедрение зависимостей (DI) основано на использовании интерфейсов.
В частности, в случае класса, который имеет определенный интерфейс в качестве параметра в своем конструкторе или определенный интерфейс, определенный как свойство (он же Setter), инфраструктура DI может передать экземпляр конкретного класса для удовлетворения потребностей. этого интерфейса в этом классе. (Извините, если это описание неясно. У меня возникли проблемы с описанием этого правильно, потому что терминология/концепции все еще несколько новы для меня.)
Причина, по которой я спрашиваю, заключается в том, что в настоящее время у меня есть класс, который имеет своего рода зависимость. Не столько зависимость от объекта, сколько URL. Класс выглядит так [C#]:
using System.Web.Services.Protocols;
public partial class SomeLibraryService : SoapHttpClientProtocol
{
public SomeLibraryService()
{
this.Url = "http://MyDomainName.com:8080/library-service/jse";
}
}
Класс SoapHttpClientProtocol имеет свойство Public с именем Url (которое представляет собой старую простую «строку»), и здесь конструктор инициализирует его жестко запрограммированным значением.
Могу ли я использовать структуру DI для ввода другого значения при построении? Я думаю, что нет, поскольку this.Url не является каким-либо Interface; это String.
[Кстати, приведенный выше код был "автоматически сгенерирован wsdl", согласно комментариям в коде, с которым я работаю. Так что я не особо хочу менять этот код, хотя и не вижу себя в его повторной генерации. Так что, возможно, изменить этот код можно.]
Я мог бы представить себе создание альтернативного конструктора, который принимает строку в качестве параметра и таким образом инициализирует this.Url, но я не уверен, что это правильный подход к сохранению слабо связанного разделения задач. (система на кристалле)
Любой совет для этой ситуации?
