myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Prause <h.pra...@gmx.net>
Subject Re: packe structure question
Date Tue, 05 Dec 2006 17:37:11 GMT
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
>>
>>
>>
>>
>>
>>
>
>


Mime
View raw message