@Pete: thanks for the answer! :-) "pete.muir(a)jboss.org" wrote : "brachie" wrote : In my opinion injecting one SFSB into another should be avoided, but maybe I am wrong.. | | anonymous wrote : | | Why? | | | I thought it would be a too tight dependency between the SFSB. For instance, if you inject SFSB A into SFSB B and SFSB C and change some business logic in A maybe B or C are broken because they use some methods of A. anonymous wrote : | | | The following questions are in my mind: | | anonymous wrote : Should there be one SFSB for every persistent class of your domain model which acts as a manager and manages the actions connected with the (injected) entity (e.g. SFSB PersonMgr for creating, deleting persons in DB etc)? | | This seems reasonable, and is the approach we take with seam-gen (using EntityHome for scaffolding). | | anonymous wrote : Or would it be better to have one SFSB component for each page you have in your application, which manages the actions connected to the specific page? | | This strikes me as a bad idea and hangover from older design patterns. | | anonymous wrote : Or would it be good to have one SFSB per use case of your application? | | This is, IMO, another very valid approach. It could easily be combined with your first suggestion (an EntityHome for each entity, a component for a use case can call the EntityHome as necessary). Ok, so I would have to inject the EntityHome into my SFSB implementing the use case? Regards, Alexander View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121623#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...