Зависимость вводит (DI) “дружественная” библиотека

Это должно сделать трюк

UPDATE
    <tablename> 
SET
    <fieldname> = replace(<fieldname>,'\n',char(13)+char(10)),
    <otherfieldname> = replace(< otherfieldname >,'\n',char(13)+char(10))

Я считаю, что вы ищете char (13)...

select 'hi' + char(13) + 'there'

Можно заменить\n в инструкциях select...

select replace('hi\nthere', '\n', char(13))

Или вы можете сделать обновление...

update table set str = replace(str, '\n', char(13))

Термин «инъекция зависимостей» не имеет никакого отношения к контейнеру IoC вообще, даже если вы склонны видеть их вместе. Это просто означает, что вместо написания кода:

public class Service
{
    public Service()
    {
    }

    public void DoSomething()
    {
        SqlConnection connection = new SqlConnection("some connection string");
        WindowsIdentity identity = WindowsIdentity.GetCurrent();
        // Do something with connection and identity variables
    }
}

Вы пишете это так:

public class Service
{
    public Service(IDbConnection connection, IIdentity identity)
    {
        this.Connection = connection;
        this.Identity = identity;
    }

    public void DoSomething()
    {
        // Do something with Connection and Identity properties
    }

    protected IDbConnection Connection { get; private set; }
    protected IIdentity Identity { get; private set; }
}

То есть вы делаете две вещи, когда пишете свой код:

1. Полагайтесь на интерфейсы, а не на классы, когда вы думаете, что реализация может потребоваться изменить;

2. Вместо создания экземпляров этих интерфейсов внутри класса передайте их в качестве аргументов конструктора (в качестве альтернативы они могут быть назначены общим свойствам; первый - инъекция конструктора , второй - инъекция свойства ).

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

Если вы ищете пример, посмотрите не далее самой Рамки .NET:

• Список < T > реализует IList < T > . При проектировании класса для использования IList < T > (или IEnumerable < T > ) можно воспользоваться такими понятиями, как «ленивая загрузка», как Linq to SQL, Linq to Сущностей и NHibernate, как, например, закулисная загрузка свойств. Некоторые классы рамки фактически принимают IList < T > в качестве аргумента конструктора, например BindingList < T > , который используется для нескольких функций привязки данных.

• Linq к SQL и EF построены полностью вокруг IDbConnection и связанных интерфейсов, которые могут передаваться через общедоступные конструкторы. Но вам не нужно их использовать; конструкторы по умолчанию работают нормально с последовательностью соединения, находящейся где-то в файле конфигурации.

• Если вы когда-либо работаете с компонентами WinForms, вы имеете дело с «сервисами», такими как INameCreationService или IExtenderProviveService . Вы даже не знаете, что представляют собой конкретные классы . .NET на самом деле имеет свой собственный контейнер IoC, IContainer , который используется для этого, и класс Component имеет метод GetService , который является фактическим локатором службы. Конечно, ничто не мешает использовать любой или все эти интерфейсы без IContainer или конкретного локатора. Сами услуги лишь свободно связаны с контейнером.

• Контракты в WCF строятся полностью вокруг интерфейсов. На фактический конкретный класс обслуживания обычно ссылаются по имени в файле конфигурации, который по существу является DI. Многие люди не понимают этого, но полностью возможно заменить эту систему конфигурации на другой контейнер IoC. Возможно, более интересно,поведение службы - это все экземпляры IServiceBehavior , которые можно добавить позже. Опять же, вы можете легко провести его в контейнер IoC и выбрать соответствующие варианты поведения, но функция полностью пригодна без него.

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

Если вы хотите спроектировать библиотеку с поддержкой DI для максимального удобства использования, лучше всего предоставить собственную реализацию IoC по умолчанию с использованием облегченного контейнера. IContainer - отличный выбор, потому что он является частью самой Рамки .NET.

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

Затем разоблачить слой над логикой DI для пользователей библиотеки, чтобы они могли использовать любые рамки, которые вы выбрали через ваш интерфейс. Таким образом, они все еще могут использовать функциональность DI, которые вы выставлены, и они могут свободно использовать любые другие рамки для своих целей.

Позволяет пользователям библиотеки подключить собственную Di Framework, кажется мне немного неправильно, так как это резко увеличивает объем обслуживания. Это также становится больше среды плагинов, чем прямой.

Edit 2015 : время прошло, я понимаю, что все это было огромной ошибкой. Контейнеры IOC ужасны, и ди - очень плохой способ справиться с побочными эффектами. Эффективно, все ответы здесь (и сам вопрос) следует избегать. Просто будьте в курсе побочных эффектов, отделите их из чистого кода, и все остальное происходит на месте или не имеет значения и ненужная сложность.

Оригинальный ответ следует:

Я должен был столкнуться с этим же решением при разработке Solrnet . Я начал с целью быть снова дружелюбным и контейнером-агностическим, но, когда я добавил все больше и больше внутренних компонентов, внутренние фабрики быстро стали неуправляемыми, и полученная библиотека была негибкой.

Я закончил написать свой собственный очень простой встроенный контейнер IOC , а также обеспечивающий Windsor Facility и модуль Ninject . Интеграция библиотеки с другими контейнерами - это просто вопрос правильной проводки компонентов, поэтому я мог легко интегрировать его с Autofac, Unity, StructureMap, что угодно.

Недостатная часть этого состоит в том, что я потерял способность к новым Я также принял зависимость на CommonserviceLocator , который я мог избежать (я мог бы решить его в будущем), чтобы проще реализовать встроенный контейнер.

Подробнее в этом пост блога .

Masstransit , кажется, полагается на что-то подобное. Он имеет интерфейс Интерфейс IObjectbuder Ibject, который действительно является IserviceLocator CommonserviCelocator с парой больше методов, то он реализует это для каждого контейнера, то есть NinjectObjectbuilder и регулярный модуль / объект, то есть masstransitmodule . Затем полагается на iObjectbuilder , чтобы создать то, что ему нужно. Это действительный подход, конечно, но лично мне это не очень нравится, так как он на самом деле слишком много проходит вокруг контейнера, используя его в качестве сервисного локатора.

Монорелью внедряет свой собственный контейнер , который реализует старый старый ISERVICEPROVIDER . Этот контейнер используется на протяжении всей этой рамки через интерфейс , который предоставляет известные услуги . Чтобы получить бетонный контейнер, он имеет встроенный локатор поставщика услуг . Виндзор Windsor Parit указывает на этот локатор поставщика услуг для Windsor, что делает его выбранным поставщиком услуг.

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