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
