В моем проекте я реализую пакет Common.Network, который обеспечивает комплексную реализацию сетевого сервера. Реализация основана на библиотеке NetMQ. Вот небольшое изображение, которое показывает зависимости между моим пакетом и библиотекой:
Как вы можете видеть, серверный класс использует много экземпляров классы из библиотеки NetMQ.
Поэтому мне интересно, стоит ли мне полностью применять здесь внедрение зависимости?
Если я это сделаю, конструктор сервера будет выглядеть так (+):
public Server(
ServerSettings settings,
IContext context,
NetMQ.Sockets.PairSocket mainThreadSocket,
NetMQ.Sockets.PairSocket serverThreadSocket,
NetMQ.Sockets.PublisherSocket dataSocket,
NetMQ.Sockets.RouterSocket inputSocket
)
{
//...
}
(+) Если я сделаю это, я в конечном итоге представлю классы-обертки для исходных сокетов NetMQ, в которых есть интерфейсы, позволяющие избежать ссылки на исходные классы непосредственно здесь. Но сейчас это другая история.
Преимущество этого состоит в том, что я могу использовать mocks вместо реальных сокетов для проверки моего Server класса. А позже я мог бы использовать адаптер для сокетов, чтобы изменить поведение при необходимости. Я действительно за это решение.
Однако недостатком было бы то, что создание экземпляра Server было бы настоящей болью: пользователь класса Server должен обработать создание экземпляра множество различных объектов сокетов и, кроме того, пользователь также должен позаботиться об очистке этих ресурсов. Хотя, если бы я инкапсулировал все эти вещи внутри сервера (создавая и удаляя экземпляры сокетов внутри класса Server), пользователю моего класса даже не нужно знать, что означает NetMQ и как он работает.
Что вы думаете об этом?