Use Struts + Hibernate for a simple web app?


EJB design: Use Struts + Hibernate for a simple web app?

  1. Use Struts + Hibernate for a simple web app? (8 messages)


    I'm building a simple web app (~20 screens; ~10 tables in a single database). After looking at frameworks such as Struts, Spring, Hivemind, for building the app and Hibernate, JDO, etc. for the persistence layer, I've decided to go with Struts + Hibernate (and POJOs for the business objects).

    QUESTION: Is this a good choice?

    My reason for Struts versus Spring is that it will be easier to find talent for maintenance of the system and Struts is already being used on other projects currently (where I work). I'm a consultant, so I want to leave behind code that is easy to maintain and/or find talent for (again, picked Struts for that reason).

    As for Hibernate versus JDO, it appears this is a much discussed topic but Hibernate appears easier to use (to me, personally) and the fact that it is associated with EJB 3.0, gives me some warm-and-fuzzy that it'll be around.

    To summarize, my objectives are:
    1. Keep things simple for quick development (less learning curve)

    2. Use lightweight stuff (i.e. no EJBs, no heavy framework)

    3. Make maintainability (ie. use industry standard stuff that you can find talent for easily such as standard J2EE, Struts, log4j, etc.)

    Any thoughts would be appreciated.

    Threaded Messages (8)

  2. In my opinion, this can quite certainly be a good choice for your requirements. However, that assumes that your application's business requirements are easily expressed in an object oriented fashion. If you are looking at a legacy database or a database that does not lend itself well to object-oriented concepts, you may want to look at a framework such as iBATIS for your persistence layer.

    Also, for further scalability, you may wish to implement a sort of mock session facade. This will allow further scaling to an EJB session facade if it's ever needed with less trouble. Specifically, the idea is to move your direct interactions with the domain model away from the controller. This would mean that your struts Actions should never interact with hibernate directly, but instead with your facade. If you do it this way, turning your mock facade into a true session facade later on down the road will be easier.

    If you want to take it a step further, you could go ahead and ensure that the objects returned to the controller are initialized (lazy-loaded objects are eagerly fetched) and serializable when they leave your facade. Then, you won't have to worry about the serializable aspects of RMI as much if you ever deploy a true session facade... but then taking it that far may be a bit further than you want to go right now :-)
  3. Re[ Go to top ]

    In other words :)
    Use Struts(view layer) + Spring (business layer) + Hibernate(backend).

    Make use of:
    - Service Layer
    - Dao Layer
  4. Spring MVC (versus Struts)[ Go to top ]

    I believe I'll stick with Struts for the view layer. I've been trying out the Spring MVC Web Framework and as much as I like Spring Dependency Injection stuff, their web framework is a bit confusing. So, this combination you suggested looks good:

       Use Struts(view layer) + Spring (business layer) + Hibernate(backend)

    By the way, any thoughts on JSF (for the view layer instead of Struts)?
  5. Spring MVC (versus Struts)[ Go to top ]

    Yeah. dont use JSF yet.
    Wait for the next jsf version.
  6. Spring MVC (versus Struts)[ Go to top ]

    I'm glad you mentioned it since we decided against JSF and went with Spring MVC last week :-)
  7. where can i get free meterial/e-book on Hibernate?. Cud u please suggest me!!!
  8. Hibernate[ Go to top ]

    Sry, but I dont know any hibernate openbook. But i can suggest you to read the hibernate documentation:
  9. Hibernate[ Go to top ]

    It's not free, but Hibernate in Action is well worth the money.