Должен ли я создавать библиотеки DLL для модульности?
Я ' я работаю над созданием приложения, которое будет анализировать статьи MSDN на предмет мета-информации, такой как заголовок статьи и другие статьи, которые находятся в той же коллекции. Это приложение также имеет интерфейс GUI.
Я заинтересован в том, чтобы сделать эту программу более модульной, разделив интерфейс от серверной части и серверную часть на две части - одна, которая обрабатывает поиск и общий разбор HTML-документа и тот, который выполняет более конкретный разбор, связанный с самим MSDN. Идея заключается в том, что это позволит добавлять пользовательские интерфейсы в бэкэнд и позволить приложению анализировать другие сайты (возможно, результаты поиска Google), просто подключив другую DLL.
Насколько я понимаю, что вы обычно создаете библиотеки DLL для совместного использования кода между различными приложениями. Однако в этом случае я Я только ищу модульность для этого конкретного приложения. Это все еще уместно для создания DLL в этом случае? Или я должен рассмотреть другой вариант, например, просто объединить все классы в одну сборку?
Я должен отметить, что я относительно новичок в программировании, поэтому даже если ответ «нет», тогда это все еще будет хорошим упражнением для меня. Если это так, я хотел бы знать, следует ли каким-либо образом изменить это упражнение, чтобы сделать его более подходящим.
3 ответа
Я думаю, что ваша идея использования DLL в этой ситуации - хорошая идея. Нет никаких заметных дополнительных затрат на использование DLL (возможно, немного больше затрат на запуск). И даже если в настоящее время вы планируете использовать их только в одном приложении, не помешает еще спланировать будущие изменения. Всегда есть хороший шанс, что библиотеки DLL можно будет использовать с небольшими изменениями или вообще без изменений в другом приложении, если это необходимо.
Кроме того, разделение его на отдельные библиотеки DLL для модульности может даже помочь в процессе проектирования и разработки. Это затрудняет «совместное использование» глобальных данных (и это, вероятно, хорошо). Если все находится в одной монолитной сборке, может быть некоторая тенденция просто взять некоторые данные из другого места. Если эти данные хранятся в другой сборке, вероятность того, что такая потенциально плохая практика возникнет, снизится. Это может заставить разработчика переосмыслить способы решения проблем.
У создания DLL есть несколько преимуществ:
- DLL может быть изменена независимо от вызывающей программы (интерфейс)
- DLL может распространяться сама по себе, независимо от проблема вызывающего абонента (интерфейс)
- , если несколько одновременно работающих программ используют одну и ту же DLL, объем памяти будет меньше
Это также связано с расходами:
- вы не можете использовать простую схему наследования для расширения DLL классы
- совместное использование глобальных данных по-прежнему возможно, но более сложно (некоторые могут сказать, что это заставляет улучшать дизайн, но это все еще ограничение)
- модульное тестирование кода, включенного в DLL, сложнее
- есть проблемы с установкой ( dll должна быть помещена в специальные места и зарегистрирована, в зависимости от того, как вы ее используете)
. Но главное, что касается модульности, заключается в том, что DLL - это еще полумера. Даже если мы проигнорируем затраты, это не намного лучше, чем библиотека или даже просто повторное использование существующих классов. Основные преимущества предназначены для торговых посредников, а не для разработчиков программного обеспечения, за исключением случаев, когда вы ожидаете сторонних участников. И вызываемые функции по-прежнему выполняются в том же процессе, что и основная программа.
Если вам нужен настоящий чистый разрез для модульности, вы можете использовать настоящую многоуровневую архитектуру с отдельными процессами для внешнего и внутреннего интерфейса и уровнем связи между ними (скажем, сокеты TCP). Обычно это и более универсально, и надежно, и не намного сложнее, когда делается на достаточно раннем этапе жизненного цикла проекта.
DLL может помочь в обслуживании вашего приложения. Если у вас есть будущие обновления и / или исправления ошибок, вы можете обновить определенные библиотеки DLL, а не все приложение. Это также поможет уменьшить площадь поверхности для тестирования.
Во время разработки также будет немного проще заглушить определенные классы / библиотеки DLL и заменить их в реальных библиотеках, которые позже будут разработаны.
Я бы не стал сумасшедшим и помещал каждый класс в отдельную DLL. С высокого уровня должна быть четкая группировка классов, которые должны быть вместе.