Session Bean God Class : Floyd Marinescu Command Pattern: Repost


EJB design: Session Bean God Class : Floyd Marinescu Command Pattern: Repost

  1. Hi All

    Sorry If this appears twice:

    In chapter 1 Page 10 Floyd says creating Session Bean God class i.e putting all use case calls in one session bean is bad as it creates bloated session bean....
    He says it is bad for development reason, is it all or are there any performance reasons....

    Because when i see EJB Command Pattern, a set of command beans go to Remote Command Server. Now this remote command server looks to me as "Session Bean God Class".

    The nice thing about EJB command pattern is that it is insulating client and ejb layer, but if I use this design my project is basically becoming
    1. A single session bean
    2. Multiple Command Beans ( I am not planning to use entity beans)

    Another intresting thing is that ...
    "Is the command bean also a Data Transfer Object, because along with executing command I also need to pass data to insert/update/delete data.

    If you can give me your thoughts on this, I have been reading this book a lot last week and hope my questions are meaningful.
  2. As long as there is enough stateless EJBs in the pool to service the requests that come in there should be no performance issues. Generally projects that use Session Facades do not have one "god like" session bean but instead create a number of Stateless EJB Facades. Each one contains related use cases.

    IMHO the command server in the EJB Command pattern is not really a god class but acts more as a Front controller. Its job is to simply call "execute" on the command.

    Fianlly the whole discussion of what is/is not a DTO is an blury one. I am still trying to work out is there a difference between Value Objects and DTO's. In the EJB command pattern you probably could think of a command as a DTO since you are using it to transfer data. Is not as I would descibe it a Value Object.