Struts and the Old EJB Question

Discussions

EJB design: Struts and the Old EJB Question

  1. Struts and the Old EJB Question (10 messages)

    Hi,
    I am relatively new to EJB development - however, the question I am asking is an age-old question, I guess.

    My project is in a stage where we are making decision on whether to use EJBs or not and we are evaluating the following options.

    1. Implementing a Session Facade with Entity Beans for data updates and DAO for data retrieval.
    2. Implementing a session facade and using just DAOs for both updates as well as retrieval - thus doing away with using Entity Beans

    The application we are developing has the following requirements/features -

    1. Medium sized database with complex transactional logic (multiple table updates are very regular)
    2. Data retrieval logic for large chunks of data with paging

    We have decided to use the Struts framework for our Controller tier.

    Any advice on this - weighing the two options or even suggesting a new one - would be greatly appreciated. I am also looking for some general knowledge/trends when it comes to using Entity Beans since my experience is limited.

    Of particular concerns is the much talked about "performance overheads". And I am weighing it against the transaction management features of the EJB container.

    Looking forward to your advice/opinions. I would be happy to answer more questions about my applications if you want to go into the specifics.

    Thanks!

    Threaded Messages (10)

  2. Struts and the Old EJB Question[ Go to top ]

    The bottom line i think is whether you want to make use of Entity beans and various features that are provided by the container or you want to write a lot transactional logic in the DAOs. You could go either way. If your database is modelled well, try using entity beans and then later you can configure the optimal pool settings etc.

    -sri
  3. when your guys're talking about to use DAO, lots of transaction logic need to be written, while in CMP Entity Bean, container will provide such transaction logic. I'm not quite sure what kind of transaction logic?, could any one give me some kind of code example?
  4. Struts and EJB[ Go to top ]

    Hi all,
    We had a discussion with three architects and decided to go the "Session Facade - DAO" way.

    Entity Beans option was discussed but no one was sure enough to bet on it.

    Thanks for all your valuable suggestions.

    Next step, we are planning to evaluate a few "O-R Mapping" api's so that it could help build our data layer better.

    Suggestions on that, experiences to share - welcome!

    Thanks again!
  5. Struts and the Old EJB Question[ Go to top ]

    Try to use POJOs(Plain Old Java Objects) and implement logic in POJOs, DAO can be used for data access using entity bean. Use VOs(Value Objects) try set max no of fields so that u can access values from VO instead of Action Form Try to implement Dynamic Queries in a seperate file say SQLIntf.java and use that file to make dynamic queries.
  6. Struts and the Old EJB Question[ Go to top ]

    It is good ides to use Struts as controller . Try to extend "org.apache.struts.action.Action and modify it as per ur application requirements. write less coode in ur Action class.
  7. agreeed with sri but.....[ Go to top ]

    HI!
    I am aggreed with sri but would like to add soemthing.Actually we are also in the same stage of our project like you , but we have decided to use session beans as business components,DAOs (along with one to one maping of java beans with database table) as data retrievel and insertion as well(We will have to handle transaction by writing code) and struts for web interface and swing for desktop interface.
    Reasons why we didn't chooce Entity bean were

    1) My previous experience says that if in later stages of a project you want to change your database , then a small change could result in very hard work on entity bean (data) layer.
    2)Although CMP has many advantages like transaction managment e.t.c but i will be more comfortable to handle those issues by myself :).AS a little change in CMP could require to edit recompile and regenrate other CMPs.
    3)If we use java beans, and DAOS(for Insertion,updation,deletion,finding single record,searching multiple records).it's very easy to manage them.

    Suggestion :- You must also think about creating a tag liabrary for all those setup/parameter tables for which you want to show combo boxes on the page so that they will be reusable in every page and you don't have to write logic for each combo again and again.That's what we used to do in our last project, we didn't use tag liabraries in that sense which resulted into hudge amount of repeated code at the end :).
    Hope it helps you
    wish you good luck for your project
    Sajjad Ahmed Paracha
  8. Struts and the Old EJB Question[ Go to top ]

    As you said this is a big age old question. There was one big discussion whether to use EJB at all or not . That can be seen at

    http://www.theserverside.com/discussions/thread.tss?thread_id=30165

    I too go by the suggestion to use SLSB as Faccade and DAOs for persistence. This offers more maintainability that partial entity beans and partial DAO. If you are writing the queries on your own, you will have the freedom to optimize the queries if you are using DAOs.

    By the use of SLSB itself you can manage the transactions through the container. Moreover I guess you might not want to distribute your EJB layer. In that case you need not go for Entity Beans at all.

    Hope it clarifies.

    Regards
    Jaise
  9. Fallacy: DAOs || EntityBeans[ Go to top ]

    DAOs are not incompatible with entity beans. DAOs simply encapsulate the persistence technology within a standard interface.

    Hence you could implement Entity Beans inside a DAO if you wish, then change to JDBC code or some other solution (Hibernate, iBatis, JDO) for DAOs that perform badly.
  10. Struts and the Old EJB Question[ Go to top ]

    Why use EJB at all?

    I'm a proponent of EJB, but you have to realize what EJB is for before you blindly use it everywhere. EJB gives you two main benefits; (1) the ability to remote-deploy business objects and distribute them across a large number of machines; (2) a declarative transactional framework.

    A lot of projects don't really need benefit (1) at all. Are you expecting to deploy your application on many machines? Do you need to be able to scale it to accomodate tens of thousands of users? Is there a significant architectural reason to run different pieces of business logic on different physical machines? If so, then you should use at least Session EJB. But if you're planning to deploy the whole thing on one server, then you're not getting the main benefit of EJB.

    Declarative transactions are a pretty good thing to have, and maybe you want to use (Session) EJB just to get this benefit. Although it's not too hard to manage transactions on your own, particularly if you are using a tool like Hibernate.

    As for entity beans -- most people aren't using them anymore. An O/R mapping tool like Hibernate will be easier to use and likely provide better performance.

    When I first learned J2EE about five years ago, I accepted EJB as the defacto way to create server components without giving it a lot of thought. I went home and rewrote my personal web site using entity beans, session beans, servlets and JSP pages. Now, this was not a bad learning experience, but my personal web site gets about 100 hits a day. If I had done the same thing for an employer it would have been a collosal waste of his money.

    Frank
  11. Struts and the Old EJB Question[ Go to top ]

    Frank,
    I pretty much agree with most of what you have said.

    As for why we are using EJB - it is with an eye on the future. Our application has good potential for future size increase and we just want to be sure we have the right framework to support it.

    And yes, we do want declarative transaction management and thats a reason.

    We are currently evaluating Hibernate and Toplink for ORM.

    Thanks for your inputs.