Эффективное использование DLL - PullRequest
0 голосов
/ 02 июня 2011

До сих пор я использовал только DLL в качестве источника для плагинов в моих приложениях.

Но я знаю, что использование DLL позволит мне намного быстрее обновлять свою программу "на стороне клиента", постоянно перезагружая основной EXE-файл.

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

«Приложение» в данном случае - игра XNA.

Так, например, у меня есть три основных класса (исключая основной класс игры)

Единицы игроки Networking.

Я бы хотел, чтобы Units / Players в одной DLL и Networking в другой DLL, или на минимум перемещали сеть в отдельную DLL, но способ работы сетевого класса и его кодирование потребует, чтобы в DLL была ссылка на игру, а в игре - ссылка на библиотеку DLL, что запрещено в Visual Studio для предотвращения циклических зависимостей.

У меня вопрос, как я могу эффективно использовать DLL для хранения своего сетевого класса, у меня есть пара идей, но я не уверен, насколько осуществима какая-либо из них.

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

Но до сих пор мне удалось найти способ получения и отправки в Main game.exe и переместить функции обработки в dll, и даже тогда функции обработки не могут (легко) взаимодействовать с игрой.

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

Если такого рода вещи нельзя сделать с помощью DLL (обратная связь между программой хоста и dll), то зачем они все-таки используются?

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

В любом случае, я всегда склонен рассуждать о вещах, которые не имеют значения (по большей части), так что спасибо за взгляд и за любые ответы:)

Ответы [ 3 ]

0 голосов
/ 02 июня 2011

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

0 голосов
/ 02 июня 2011

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

Итак, вопрос, который вы задаете:

«Почему и как у меня будет больше проектов в моем решении?»

Это сводится к организации исходного кода.

В ООП объекты обычно можно сгруппировать в более мелкие домены, которые можно описать самим и работать как черный ящик.

Эти черные ящики являются DLL.

В игре я могу представить несколько отдельных проектов:

  • базовые классы
  • игровая логика
  • визуализатор
  • сериализация / десериализация (менеджер сохранения)
  • менеджер аудио
  • код утилиты ...

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

Вы не можете получить их, не реорганизовав то, что имеете.

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

0 голосов
/ 02 июня 2011

ОК - у вас есть 3 класса с зависимостями друг от друга.

Можете ли вы изменить отношение так, чтобы вместо одного класса ссылались на другой, вместо этого вы ссылались на интерфейс?

например. У ClassA есть метод, который использует ClassB - MethodB1 ClassB реализует интерфейс IB, так что теперь класс A имеет ссылку на IB

Поместите все ваши интерфейсы в отдельную сборку. Теперь A, B и C не имеют ссылок друг на друга - только на класс интерфейса. В вашем исполняемом файле используйте Dependency Injection, чтобы связать реализации класса Concrete.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...