Session Bean Method Placement Standards


EJB design: Session Bean Method Placement Standards

  1. Session Bean Method Placement Standards (3 messages)

    I presents a simple question that may be mostly based on personal opinion rather than best practices. Its difficult to explain without giving and example. In my example i have two session beans CompanyManager and AccountManager. Lets say i need a way to pull accounts for a given company. Where should the method go? @Local public interface CompanyManager extends Manager { List queryAccounts(Company company); } --OR THIS--- @Local public interface AccountManager extends Manager { List queryByComany(Company company); }

    Threaded Messages (3)

  2. method and class names[ Go to top ]

    If the session beans acts just as a fascade - then I'd use just one bean which will encapsulate whole module - and I'd called methods just as a simple getters / setters (instead of queryAccount which is quite blind - maybe as finder method - but this is clashing with entity finder methods) - also to call everything 'Manager' seems to me as some kind of illness :) so ... I assume you have underneath some entities so there in the session bean there should be business logic which will be getting some particular subset of data from entities and translate them into some kind of data transfer objects for specific use on the client.
  3. to little info i guess[ Go to top ]

    The examples i gave would have more responsibilities than just querying or as you stated getting but i tried to keep the example simple. I can relate to your suggestion about pushing them to new 'module' because the facades in the example are pretty lazy. But the facade would have more business process as well factory methods to encapsulate all the business domain code than the example I gave. As far as method naming goes this is our standard 'query'. A 'get' should only be encapsulating access to a variable and should be very simple. Not using a 'get' also provides the developer that the process maybe be performance intensive and should be avoided when possible. But my question was not about our naming standards.
  4. Re: method and class names[ Go to top ]

    for the scenario you mentioned, since the return type is same, having a generic method which takes additional parameters or criteria would do there by making it a single bean/method. Cheers, Sridhar