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.
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
Joined: Jan 11, 2005
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.