Holgar,
I think this approach is a better choice than your original option #2.
This would have been a potential organizational nightmare. :)
Putting the actions and data in the same class or not is really just a
matter of preference. 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.
Like David, we are not spliting our classes.
Regards,
Jeff Bischoff
Kenneth L Kurz & Associates, Inc.
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
