This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Packaging for Reuse Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Packaging for Reuse" Watch "Packaging for Reuse" New topic
Author

Packaging for Reuse

Jamie Jackson
Ranch Hand

Joined: Jan 11, 2005
Posts: 58
I'm a rookie, but I've been doing some of the setup work on a Struts app. I don't have any experience packaging modules, so I need some guidance.

Say I've got these modules:

com.myFirm.app1.module1
com.myFirm.app1.module2
com.myFirm.app1.module3

The architect wants to separate the MC from the V (as in MVC) in the package structure, so that we can easily reuse the MC pieces in future Struts apps. I further suggested separating all three layers, in case pieces of the model might be repurposed for a non-Struts app.

Just so we're straight, here's what how the architect is classifying the pieces:

M = Business Objects
V = (Struts) ActionForms
C = (Struts) Actions

Therefore, it's looking like we should do something like:
com.myFirm.app1.module1.model
com.myFirm.app1.module1.view
com.myFirm.app1.module1.controller
com.myFirm.app1.module2.model
com.myFirm.app1.module2.view
com.myFirm.app1.module2.controller

But I don't recall ever seeing such package structures. Is this prudent architecture? Please feel free to comment on all of the above. Any discussion on packaging would be enlightening.

Thanks,
Jamie
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In our project, we have the follwing seperation:

module1.model
module1.swing
module1.web
module2.model
...

you get the idea...

We don't do strict MVC - actually we are experimenting with more of an MVP approach. Anyway, we find that the navigation/presentation logic is quite coupled to the type of view, so we don't care about putting it into its own module yet (though they typically *do* go into their own java package(s)).


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jamie Jackson
Ranch Hand

Joined: Jan 11, 2005
Posts: 58
The architect envisions most reuse to be struts reuse, so that point of view argues for a separation of V from C, also. I don't know if this separation of V from C will actually be useful when/if the code is ever reused, but it does meet her requirement.

I see what you're doing, and it does make good sense to me. It's also probably the most practical separation.

Your structure is similar to mine, so I'm more comfortable with my structure now.

Thanks,
Jamie
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This Dependency Inversion presentation has a couple slides on different motivations for different types of packaging. Let me know if it's at all helpful. Thanks!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jamie Jackson
Ranch Hand

Joined: Jan 11, 2005
Posts: 58
I read through the presentation. Nice to see a presentation by example, I get lost in abstractions, until I'm familiar enough with them.

This might help me later, when I'm refactoring the modules themselves.

Thanks,
Jamie
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Packaging for Reuse
 
Similar Threads
Switching Modules in Strurts1.1
STRUTS 1.1 - Switching between application modules
Modular java software using jars
Multiple Controller Servlet
changing the context