A couple thoughts,
There's nothing really wrong with separating the layers into different jars, at the least it enforces strict separation of concerns. However, unless you have distinct teams working on each piece of the project, it does tend to become a pain in the rear when everytime you have to make a change to the underlying model or dao, that you must propogate the resulting jar to your UI project(s). Frequently, newly discovered requirements in the UI layer necessitate a change in the business layer(s).
Saying that, in my current project, I actually do separate the three business layers (model, DAO, service) into an implementation jar and an interface jar. The implementation jar runs on the application server and exposes its methods via RMI. The UI projects that interact with the RMI services only need the interface jar (only the interfaces are included). But this particular design was necessary because I have several projects that interact with this RMI-based (and read-only) back end. Additionally, there are developers outside of my control who also use the exposed services. It is nice to be able to hide the implementation via only sending them the interfaces (with well formed, thorough javadocs).
If you are only using them for one project, though, I do not really see the need to separate the business layers into jars. As long as you always code to interfaces it's inherently pluggable already, why make it harder on yourself. :)
|