Какова наилучшая практика (и последствия) для упаковки проектов в JAR? - PullRequest
4 голосов
/ 23 марта 2010

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

JAR за слой (презентация, бизнес, данные) JAR на (значительную?) Панель графического интерфейса. Для существенной системы это приводит к большому количеству JAR, но JAR (должны быть) более пригодны для повторного использования - мелкозернистая гранулярность JAR за «проект» (в смысле проекта IDE); "common.jar", "resources.jar", "gui.jar" и т. д.

Я опытный разработчик; Я знаю механизм создания JAR-файлов, я просто ищу мудрость для лучшей практики.

Лично мне нравится идея JAR для каждого компонента (например, панели), поскольку я безумно увлечен инкапсуляцией и святым Граалем повторного использования в разных проектах. Однако я обеспокоен тем, что на практическом уровне производительности JVM будет бороться с загрузкой классов в течение десятков, а может быть, и сотен маленьких JAR. Каждый JAR будет содержать; код панели графического интерфейса, необходимые ресурсы (т.е. не централизованные), чтобы каждая панель могла стоять отдельно.

Когда я говорю «святой Грааль повторного использования», я говорю это больше, потому что он демонстрирует четко отделенный, инкапсулированный дизайн, а не обязательно ожидает его повторного использования в другом месте. Я считаю себя "нормально умным" человеком; Я считаю, что спагетти переплетенной чепухи, с которой мне приходилось сталкиваться в течение моей карьеры, замедляет меня в 10-100 раз. Четко отделенный дизайн позволяет мне иметь дело с одной концепцией за раз, одним слоем, одним классом.

Есть ли у кого-нибудь мудрость, которой можно поделиться?

Ответы [ 4 ]

5 голосов
/ 23 марта 2010

Я бы порекомендовал как можно меньше JAR.

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

Отсюда и появление файлов .war, в которых все зависимости веб-приложения помещены в один файл.

Кстати, в Eclipse есть плагин-экспортер JAR, который помещает все зависимые jar-файлы в супер-jar и предоставляет основной метод начального уровня, поэтому вы можете запустить свое приложение с помощью команды java -jar file.jar. Хотя результирующий jar может быть большим, оборотная сторона не поддерживает очень сложные пути классов для вашего приложения.

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

2 голосов
/ 23 марта 2010

На самом деле вы можете использовать оба подхода.Например, Spring предлагает большой монолитный файл JAR, который содержит наиболее распространенные функции.Однако, если вы хотите, вы также можете скачать независимые файлы JAR.Затем пользователю остается выбрать, что лучше.Файлы больших jar легче развернуть, но их сложнее обновить.Также вам может понадобиться добавить большую банку, тогда как вам нужен только простой класс.Я считаю, что легче обнаружить зависимости с небольшими файлами JAR.Я также думаю, что обновление / обновление проще.

1 голос
/ 23 марта 2010

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

0 голосов
/ 14 января 2014

Я где-то читал (и я пытался найти его, когда я нашел это), что проект для слоя является лучшим.Это то, что я делал.Struts, Spring MVC, Swing, что угодно на одном уровне, EJB на другом, бизнес-сервисы на другом и DAO на другом.Я поместил все DTO в его собственный проект, хотя они не представляют слой, а вместо этого пропускаются через слои.Главное преимущество, о котором я помню, это возможность создавать версии каждой банки отдельно.Да, и кстати, каждый уровень на самом деле имеет два jar, один для интерфейсов, которые использует уровень выше, а другой для реализации (й).

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