Jeff Bischoff schrieb:
Holgar,
I think this approach is a better choice than your original option #2.
This would have been a potential organizational nightmare. :)
What does mean would ^^, why do u think i am making a redesign and
asking this questions =P.
Putting the actions and data in the same class or not is really just a
matter of preference.
Ah ok, i also saw designs where a bean had an action method.
I didnt liked this.I think actions should go into an own class (Action
class)
This is one point i dont want to change.
Putting them together is more OO design, while separating them gives
you smaller classes which may be important for manageability in some
cases. But I agree that you should arrange your packages by purpose in
either case.
So the view on my package tree should be module centred.
Like David, we are not spliting our classes.
Hmm, ok u both convinced me, no separation in beans and actions on
package level, only separated by classname (*Bean* for bean *Action* for
action) and place them
into the same package.
For my current project its ok and i think it fits good.
Ill do it this way.
Regards,
Jeff Bischoff
Kenneth L Kurz & Associates, Inc.
Thank your very much to both of u!
Your helped me a lot making a decision.
One final question :
In my old project(not the one i am currently redesigning) we had another
source structure, repeating the module names in every different kind of
type.(like my original planned option #2)
Example:
com.mycompany.myproject.session.documents.news
com.mycompany.myproject.dao.documents.news
com.mycompany.myproject.beans.documents.news
com.mycompany.myproject.dataobjects.documents.news
One final comment on this please (is it really unusable/ bad designed)?
What would your change?
With best regards,
Holger
Holger Prause wrote:
Nebinger, David schrieb:
Well, since no one jumped in with an opinion, I'll share our
methodology...
i am currently programming a jsf application and i found out that i
have 2 different things in every package
.beans (jsf beans)
.action(jsf action)
Now how should i structure my packages.
First, we're not splitting beans from actions, but that's because
we're accepting the fact that the actions are really tied to the
beans and vice-versa. In our environment, a managed bean represents
a form, and the actions are truly tied to that form also, so there
is no real reason to separate the two. Your architecture could be
different, so I'd assume that you must have some reason to separate
them.
Since we are building portlets, we've structured our packages to be
based upon the portlet rather than scoped on some other concept. So
for portlet A, the objects fall under com.mycom.portlet.a.*, etc.
Portlets typically have much finer scope than a generic app, so the
number of objects we end up with is pretty small, so the this
organization does not become overwhelming.
The basic answer to your question is that there is no real answer,
it is all going to be based upon your project and the structure
should represent something applicable to the project, whether it is
based on workflow, page structure, object graph structure, whatever.
Hello first of all thanks for your reply.
quote: "The basic answer to your question is that there is no real
answer, it is all going to be based upon your project and the
structure should represent something applicable to the project,
whether it is based on workflow, page structure, object graph
structure, whatever."
Well i was afraid to get such an answer ^^
quote: "In our environment, a managed bean represents a form, and the
actions are truly tied to that form also, so there is no real reason
to separate the two. "
Hmm, thats also the case in my environment, i am using jsf for a
while now and u always have
1)entity beans (data objects)
2)jsf bean / managed beans (data representation)
3)jsf actions (logic)
thats why i wanted to separate them: (reasons for different packages)
* All my actions have logic, they implements a Buisness Interface and
are stateless,
* All my beans are plain java objects with nearly no logic and are
mostly session beans
on the other hand actions and beans always works hand in hand(like u
wrote before) but only for the current module.
example:
my.company.frontend.foo.groups.GroupsListBean (Session Bean)
my.company.frontend.foo.groups.ManageGroup (buiseness interface)
my.company.frontend.foo.groups.ManageGroupAction (Stateless Bean with
buiseness interface)
So the main problem is : jsf bean /action have some things in common
(works together for a certain thing) but some
are different (actions have logic, they implements a Buisness
Interface and are stateless, beans are plain java objects with
nearly no logic and are mostly session beans ), so is he differece worth
a new package?
I think ill choose your way and move actions and beans into the same
package (by the way: the backend is separated from the frontend , so
i have 2 packages "frontend" and "backend" , think that necessary),
maybe it gets problematic if u have many classes in a package (1
entity bean = 3 frontend classes)
If u have any further comments on it , please i would like to hear.
Thank you very much,
Holger
