Когда у меня есть закрытые методы в классе, которые являются достаточно сложными, что я чувствую потребность протестировать закрытые методы непосредственно, который является запахом кода: мой класс является слишком сложным.
Мой обычный подход к решению таких проблем должен чесать новый класс, который содержит интересные биты. Часто, этот метод и поля, это взаимодействует с, и возможно другой метод или два, могут быть извлечены в к новому классу.
новый класс представляет эти методы как 'общественность', таким образом, они доступны для поблочного тестирования. Новые и старые классы теперь оба более просты, чем исходный класс, который является большим для меня (я должен сохранить вещи простыми, или я заблудился!).
Примечание, что я не предлагаю, чтобы люди создали классы, не используя их мозг! Точка здесь должна использовать силы поблочного тестирования, чтобы помочь Вам найти хорошие новые классы.
Какой бы подход вы ни выбрали, убедитесь, что вы действительно получаете значение из него. Другими словами, не служите архитектурному принципу (упаковка / банка), позвольте архитектурному принципу служить вам.
Вам нужно найти баланс между разделением проблем и эффективностью. Чем больше у вас проектов, тем сложнее становятся вещи, но если у вас один проект, он также может быть громоздким.
Посмотрите на свои требования, контекст и размер вашего приложения и решите, какой подход будет вам лучше всего.
В моей компании мы объединяем каждый уровень в свой собственный JAR. Затем мы включаем его в WAR.
Если у вас нет каких-либо EJB, которые нужно управлять, нет никакого реального преимущества в использовании EAR перед WAR для развертывания.