Article: Wiring Your Web Application with Open Source Java

Discussions

News: Article: Wiring Your Web Application with Open Source Java

  1. Mark Eagle has written an article on putting together an application with Struts on the presentation layer, Spring as the business services layer, and Hibernate for persistence. This seems to be the common architecture of choice for certain web applications.

    Conclusion
    This article covers a lot of ground in terms of technology and architecture. The main concept to take away is how to better separate your application, user interface, persistence logic, and any other application layer you require. Doing this will decouple your code, allow new code components to be added, and make your application more maintainable in the future. The technologies covered here address specific problems well. However, by using this type of architecture you can replace application layers with other technologies. For example, you might not want to use Hibernate for persistence. Since you are coding to interfaces in your DAO objects it should be apparent to you how you might use another technology or framework, such as iBATIS, as a substitute. Or you might want to replace your UI layer with a different framework than Struts. Switching UI layer implementations should not directly affect your business logic or your persistence layer. Replacing your persistence layer should not affect your UI logic or business service layer. Wiring a web application is not a trivial task but it can be made easier to deal with by decoupling your application layers and wiring it together with suitable frameworks.
    Read Wiring Your Web Application with Open Source Java

    Threaded Messages (74)

  2. I'm guilty[ Go to top ]

    Yeah, I have applied the "bad" practice of putting data access code and
    busisess logic in my Struts Actions. This article is helpful to me as I'd like to decouple the biz layer from the presentation layer completely. I like that fact that Spring has "built-in" support for Hibernate. Hibernate is cool.

    Thanks,
    Michael
  3. do we have to ![ Go to top ]

    One Servlet controller+perform business logic in a ejb container using session bean =safe J2ee practice. Using Hibernate,DAO or any of the rest of frameworks doesn't make much dif.
  4. do we have to ![ Go to top ]

    Right on Faisal!

    The system you describe is as robust, maintainable and scalable as you would ever need. Plus it supports the KISS principle - Keep It Simple, Stupid.
  5. do we have to ![ Go to top ]

    One Servlet controller+perform business logic in a ejb container using session bean =safe J2ee practice. Using Hibernate,DAO or any of the rest of frameworks doesn't make much dif.
    I agree. Why is there a current obsession with using as many frameworks as possible - even in simple applications? Is it just because it's the cool thing to do?

    I admit to using Struts but what can mastering the ever increasing number of frameworks offer that a simple JSP/servlet/Struts, session bean and entity bean based application can't offer? Using appropriate design patterns can decouple the different layers using these standard components quite nicely.
  6. do we have to ![ Go to top ]

    One Servlet controller+perform business logic in a ejb container using session bean =safe J2ee practice. Using Hibernate,DAO or any of the rest of frameworks doesn't make much dif.
    I agree. Why is there a current obsession with using as many frameworks as possible - even in simple applications? Is it just because it's the cool thing to do?I admit to using Struts but what can mastering the ever increasing number of frameworks offer that a simple JSP/servlet/Struts, session bean and entity bean based application can't offer? Using appropriate design patterns can decouple the different layers using these standard components quite nicely.
    Note that adding Spring and Hibernate to the mix does not complicate at all the scenario, since they allow a radical simplification of the development, and suggest a rational and effective architecture to what you're doing. Basically, it's as if you gained at the same time a simpler model (pure javabeans instead of EJBs, ORM instead of pure jdbc or EJB CMP, a nice IOC way of wiring components instead of looking them up via jndi, nice declarative features controlled both via xml config or via metadata...) and a set of architectural best practices which are naturally suggested by the development model.
  7. I'm guilty[ Go to top ]

    Yeah, I have applied the "bad" practice of putting data access code and busisess logic in my Struts Actions. This article is helpful to me as I'd like to decouple the biz layer from the presentation layer completely.
    Surley this is a job for design patterns, not frameworks?
  8. I'm guilty[ Go to top ]

    Yeah, I have applied the "bad" practice of putting data access code and busisess logic in my Struts Actions. This article is helpful to me as I'd like to decouple the biz layer from the presentation layer completely.
    Surley this is a job for design patterns, not frameworks?
    Well, a good framework such as Spring is soundly based on a set of design patterns: using patterns requires code, and often that code results in a "custom framework" developed in-house. Spring is simply a better solution than custom ones.

    If the tools you use already implement those patterns (such as the factory and singleton features that the ioc container in Spring offers), this is better for you. Other than that, you're not forced to use Spring: as someone who is using it every day with great satisfaction I suggest you to take a look at it, but the world won't cease to exist, if you don't. ;)
  9. Frameworks apply design patterns[ Go to top ]

    Yeah, I have applied the "bad" practice of putting data access code and busisess logic in my Struts Actions. This article is helpful to me as I'd like to decouple the biz layer from the presentation layer completely.
    Surley this is a job for design patterns, not frameworks?
    Duncan,

    Yes, but a good framework *applies* the appropriate design patterns, enabling you to build more maintainable and flexible apps. In addition, you'll find the good frameworks like Spring enable you to write much less code, as they address the more complex, infrastructure-related problems common in any enterprise app (for example, database session managemenet accross a transacation, or model data binding.) Good code breeds good code.

    Keith
  10. Frameworks apply design patterns[ Go to top ]

    you'll find the good frameworks like Spring enable you to write much less code, as they address the more complex, infrastructure-related problems common in any enterprise app (for example, database session managemenet accross a transacation, or model data binding.) Good code breeds good code.Keith
    Exactly. Why wouldn't you take advantage of that fact if it is available to you? In other words, I see the value in mixing the frameworks because it more clearly defines your "system" into parts which makes it easier to maintain and scale. If you need a new fuel injector system for your car you would go buy one not make one at home from scratch (assuming you know how). Same thing with web applications, when possible. I'd like to see this taken one step further by adding Aspects to the mix to handle exceptions or logging.

    Michael
  11. have a look at this link:

    http://anti-freeware.tripod.com
  12. I have just deployed a web-based bioinfomatics research application for a major pharmaceutical company using a very similar architecture:

    1. JSTL and Struts taglibs in JSP using Tiles for layout
    2. Struts DispatchAction and ActionForm subclasses
    3. Spring BeanFactory-based service layer and application configuration
    4. DAO objects that extend Spring's HibernateDaoSupport classes and use Spring's HibernateTemplate internally.
    5. Transaction management using Spring's HibernateTransactionManager
    6. Hibernate Session management using Springs's OpenSessionInViewFilter
    7. Hibernate for persistence (Oracle)
    8 Tomcat 4.1.29 (light load intranet deployed app)

    The real beauty of this architecture is the ability to pass graphs or collections of hibernate domain objects directly to the view.

    Using a robust service layer makes the Struts action class implementations very light weight. We chose to use Struts over Spring's MVC implementatin primarily because of the skill set of the developers on the team.

    Overall, my experience with this architecture has been really positive. It's very flexible and performant and it effectivly hides a lot of complexity that makes it easy to focus on solving business problems. Using tomcat makes day to day development so much easier. Our success with this application is a real credit to the hard work of the Struts, Hibernate and Spring framework teams.

    -Ravi
  13. 1. JSTL and Struts taglibs in JSP using Tiles for layout2. Struts DispatchAction and ActionForm subclasses3. Spring BeanFactory-based service layer and application configuration4. DAO objects that extend Spring's HibernateDaoSupport classes and use Spring's HibernateTemplate internally.5. Transaction management using Spring's HibernateTransactionManager6. Hibernate Session management using Springs's OpenSessionInViewFilter7. Hibernate for persistence (Oracle)8 Tomcat 4.1.29 (light load intranet deployed app)
    That's what I call overkill.
  14. 1. JSTL and Struts taglibs in JSP using Tiles for layout2. Struts DispatchAction and ActionForm subclasses3. Spring BeanFactory-based service layer and application configuration4. DAO objects that extend Spring's HibernateDaoSupport classes and use Spring's HibernateTemplate internally.5. Transaction management using Spring's HibernateTransactionManager6. Hibernate Session management using Springs's OpenSessionInViewFilter7. Hibernate for persistence (Oracle)8 Tomcat 4.1.29 (light load intranet deployed app)
    That's what I call overkill.
    It's the complexity of the business logic (among other factors), but not the traffic load which determines the use of frameworks such as Spring or Hibernate. Since we don't know anything about the complexity and other requirements the project has had, we can't call it overkill

    joe
  15. It's the complexity of the business logic (among other factors), but not the traffic load which determines the use of frameworks such as Spring or Hibernate. Since we don't know anything about the complexity and other requirements the project has had, we can't call it overkilljoe
    I agree. That's why I used "lightweight" instead of "light-load" in my second post.
  16. 1. JSTL and Struts taglibs in JSP using Tiles for layout2. Struts DispatchAction and ActionForm subclasses3. Spring BeanFactory-based service layer and application configuration4. DAO objects that extend Spring's HibernateDaoSupport classes and use Spring's HibernateTemplate internally.5. Transaction management using Spring's HibernateTransactionManager6. Hibernate Session management using Springs's OpenSessionInViewFilter7. Hibernate for persistence (Oracle)8 Tomcat 4.1.29 (light load intranet deployed app)
    That's what I call overkill.
    I apologize that I rushed to judgment.

    I'm currently working on a J2EE project that uses a nuke to light a cigarette, and left me pretty pissed off at the concept of "let's use it, just because it's there and it sounds cool".
  17. Peter,

    You obviously haven't used Spring or Hibernate. They each provide simple yet powerful features without adding unecessary complexity. The parts of our app that I described are the simplest parts of our application. (The business logic is the hard part). These pieces are simply the framework upon which our app is built. Overkill is using a full blown EJB server w/o the specific business requirement simply because I want declarative transaction management. Or, implementing my own 750 line custom Digester framework just so I can parse an xml config file and load some objects w/ data. And don't get me started on using JDBC to load data into Domain objects by hand... Overkill.

    Anyway, most of the developers on this app don't even see alot of these pieces--b/c they are hidden behind the simple service interfaces they get from the BeanFactory. All they know is that it takes them a few lines of code to do what they need to do and it all works. That's not overkill, thats efficency. I suspect that if you do some research on Spring and Hibernate (or better yet, start using them) you will change your tune.

    -Ravi
  18. Our experience with different frameworks in J2EE application development can be boiled down to following key points:

    1. Using Hibernate (together with XDoclet) for persistence greatly improves developers' performance (as no one has to care about JDBC code) and portability across databases (currently our app works with MySQL, SAPDB, Oracle and Hypersonic). However there's learning curve involved (one to few weeks) and there are minor hassles taming native id generators and BLOB persistence.

    2. Using Tapestry for user interface also involves even longer learning curve, but at the end it pays off greatly in unpreceeded flexibility and reuse.

    3. Whatever frameworks are used, it seems always good to put some efforts designing application in such a way that its business logics isn't directly coupled with framework code, whenever practically possible. In other words, code containing business logics never should be allowed to import and call any framework classes. Wrapping all components in your own interfaces ('services') allows to switch implementations from session beans to direct calls transparently to the client. The client i.e. business logics class must be thus not allowed calling any framework code (e.g. EJB Home and bean methods), but instead doing something like:

    <code>
    MyService service = MyServiceFactory.getMyServiceInstance();
    service.doIt();
    service.doItDifferently(withThisArgument);
    service.close(); // if actually required to clean up, release resources
    </code>

    Another example: isolating asynchronous message delivery with abstract DeliveryService allows to use either JMS/MDB or direct in-memory queues or whatever.

    In this way you depend much less on particular framework implementation, be it J2EE or Spring or PICO or whatever.
  19. In other words, code containing business logics never should be allowed to import and call any framework classes. Wrapping all components in your own interfaces ('services') allows to switch implementations from session beans to direct calls transparently to the client. The client i.e. business logics class must be thus not allowed calling any framework code (e.g. EJB Home and bean methods), but instead doing something like:

    <code>
    MyService service = MyServiceFactory.getMyServiceInstance();
    service.doIt();
    service.doItDifferently(withThisArgument);
    service.close();
    </code>

    In this way you depend much less on particular framework implementation, be it J2EE or Spring or PICO or whatever.
    Timur,

    You're essentially missing the very point of an IoC container: If you wire your application objects via IoC, those objects receive dependencies and config values via bean properties or constructor arguments at initialization time. Init and destroy callbacks are configurable in a declarative manner. Your objects do not have to depend on a specific framework like Spring for this; most importantly, they can still easily be used in a programmatic fashion.

    I completely agree regarding decoupling from EJB, i.e. JNDI lookups, or any other service locators (like Avalon). This is something that Spring provides in an IoC fashion too: EJB proxies and other JNDI-located objects can be configured as bean definitions, getting passed into your applications objects via bean properties or constructor arguments, just like any other dependencies. Your objects never have to do manual JNDI lookups or the like.

    Juergen
  20. The end of evolution: Spring Rules[ Go to top ]

    It is not always possible to maintain improvement and evolution. For instance, Hi-Fi equipment used to boast of the frequency curve, but eventually all could reproduce 20-20 000 Hz clear and distort-free and there was no much point to increase to 30 000 or 40 000 and to..because nobody can hear these frequencies! So, evolution moves on to other areas.

    In my opinion, we have reached that same level now. Spring effectively makes any ordinate web container into a J2EE Server- but without the excessive fat of the big Java J2EE servers. You just use what you want and need, nothing more, you get speed, faster upload time, lesser lines of code, you get "KISS"!! As Whack Nine says, "That's not overkill, thats efficiency"
    Also you get something that Sun has no control over ;)

    Spring does not try to induce you to use any special solution for presentation for example, and in that differ from otherwise good solutions like Tapestry or Webwork- that IMO "do too much". The most important thing is that we don't want a box that does everything for us, that has already been tried with Weblogic, Websphere, JBoss etc. Spring acts like glue only, enabling different (smaller) black boxes to work seamlessly together.

    So what now?
    The most important and immediate need is to port Spring to .NET and Mono.NET, in that case J2EE will come to .NET! But what shall we call it? NJ2EE? J2EE.NET? :)

    Regards
    Rolf Tollerud
  21. The end of evolution: Spring Rules[ Go to top ]

    The most important thing is that we don't want a box that does everything for us, that has already been tried with Weblogic, Websphere, JBoss etc. Spring acts like glue only, enabling different (smaller) black boxes to work seamlessly together.
    I'm not sure why you guys are mixing up application servers with an application framework?

    I was also puzzled when I was reading the description of an upcomign book by Bruce Tate (the Bitter Java/EJB author) about Spring/Hibernate called Better, Faster, Lighter Java, and it says:
    Building server applications with "heavyweight" Java-based architectures, such as WebLogic, JBoss, and WebSphere, can be costly and cumbersome.
    and then goes to say:
    As an alternative means for building better applications, the authors present two "lightweight" open source architectures: Hibernate--a persistence framework that does its job with a minimal API and gets out of the way, and Spring--a container that's not invasive, heavy or complicated.
    It sounds as if Spring/Hibernate are about to knock BEA out business! Do they mean EJB when they say WebLogic architecture?

    WebLogic, WebSphere, and JBoss are application servers, and provide a web container, connection pooling, transaction support, clustering, caching, etc. As far as I know, Spring doesn't provide any of the above, but an abstraction layer to utilize them. Spring can't run without an application server.
  22. It sounds as if Spring/Hibernate are about to knock BEA out business! Do they mean EJB when they say WebLogic architecture?WebLogic, WebSphere, and JBoss are application servers, and provide a web container, connection pooling, transaction support, clustering, caching, etc. As far as I know, Spring doesn't provide any of the above, but an abstraction layer to utilize them. Spring can't run without an application server.
    Of course it can't and it does not even try to! I don't think Spring will put Bea or any other j2ee server vendor out of business: it is just showing an alternative way to j2ee development. One where EJBs are shown to be non necessary even for transactional and mission critical applications, and where the features normally provided by the EJB container can be effectively (and much more practically) provided by the framework.

    All of this with a nice architectural structure based on IOC and AOP, careful distinction between layers, careful eye on quality (for the level of information provided by logging, configuration options), a lot of useful tools in terms of integration and of features directly provided by the framework... But for distributed transactions, for example, Spring relies on a transaction manager: and that's where the J2EE vendors provide their sound infrastructure and give a reason for their existence.

    People have been saying that J2EE is not equivalent to EJB for years: I think that Spring is THE alternative "ready now" that shows a viable way to a J2EE without EJB where the "without EJB" does not mean at all "without the power of EJB": that power comes from different tools, though. A similar approach could be provided by EJB 3.0, maybe, but I frankly don't give a damn, now that I've switched to Spring and am happy with it.
  23. People have been saying that J2EE is not equivalent to EJB for years: I think that Spring is THE alternative "ready now" that shows a viable way to a J2EE without EJB where the "without EJB" does not mean at all "without the power of EJB": that power comes from different tools, though. A similar approach could be provided by EJB 3.0, maybe, but I frankly don't give a damn, now that I've switched to Spring and am happy with it.
    Agreed. EJB is a pain-in-the-ass part of the J2EE specs. There are many other parts of J2EE like servlets, XML, transactions, JMS, JMX, etc.

    So saying Spring/Hibernate provide better architecture than WebLogic doesn't make much sense, because we're basically comparing apples and oranges.
  24. Even it is that complex[ Go to top ]

    Hi Davide,

     Actually i am building a whole ERP JSR 168 Portal using this KISS:
    ONE Servlet controller + only ONE Session Bean, and it works nice and easy for me.
    the web tier is already solved neatly with Struts - as adpated to my own framework. As for the EJB tier, I don't need more than Hibernate with a serialized SessionFactory in Jboss MBean to deal with a safe and fast business actions performing. I will use whatever I need from Spring as seperate source code and include int my app .


    Open Source is about freedom and i am free ,only ,when i use no framework as it is!

    Faisal
  25. Peter,

    You are not very logical here! First you say,

    Agreed. EJB is a pain-in-the-ass part of the J2EE specs. There are many other parts of J2EE like servlets, XML, transactions, JMS, JMX, etc.

    OK. Here you basically agree that Spring/Tomcat ( + what you may need, JMS, JMX, transactions, XML, whatever) can replace all the functionality of a big J2EE server).

    But then you say, we're basically comparing apples and oranges

    Why? When a) can do everything what b) can do you do have a valid comparison.
    I take for granted that Spring + different Open Source and third party "black box components" will eventually replace the dinosaur J2EE Servers. That it is probably a correct observation is indicated in the vehemence of the argumentation from the JBoss quarter.

    Regards
    Rolf Tollerud
    Spring for C# now. Immediatemente!
  26. Rolf, you're reducing the whole J2EE to its EJB support. I've been using WebLogic for three years, and never once have I used EJB with it. I use it for its clustering/load-balancing, transactions/JTA, JMS, JMX, security, JNDI, connection pooling, web services, RMI, servlets, etc.

    EJB is but a SMALL part of a huge spec a certain J2EE server needs to implement.

    You can't say that Spring is better than WebLogic because it really dosn't make sense. The first is a framework and the second is a server.

    May be you can say a solution that uses Spring on WebLogic is better than a solution that uses EJB on WebLogic.
  27. Spring is better[ Go to top ]

    Peter: "You can't say that Spring is better than WebLogic because it really doesn’t make sense. The first is a framework and the second is a server".

    It is Spring together with a webcontainer like Tomcat (=the combination) that makes a competition to Weblogic, not Spring alone.

    Peter: "clustering/load-balancing, transactions/JTA, JMS, JMX, security, JNDI, connection pooling, web services, RMI, servlets, etc."

    All of with can be done better with Spring/Tomcat + modules IMO.

    Regards
    Rolf Tollerud
  28. Spring is better[ Go to top ]

    I'm not sure why you're throwing Spring into the mix, because you can run Spring equally on Tomcat AND WebLogic.

    Your argument bascially boils down to whether Tomcat is superior to WebLogic.
  29. Peter: "Your argument basically boils down to whether Tomcat is superior to WebLogic.

    I don’t have any example from Weblogic yet, but I have one with JBoss! :)

    Richard Öberg: "Bye bye JBoss
    ..so we also removed all dependencies on JBoss from our CMS SiteVision. Now we can run it with just Tomcat, and boy does it run. For development this is going to be great, since Tomcat starts much MUCH faster than JBoss."

    http://jroller.com/search/rickard?q=jboss

    The case is that if when you load any big J2EE server and Spring you are loading tons and tons of unnecessary classes and resources. Trick question: "How many classes do Weblogic loads at start? (there is a price for first right answer!). Then you battle not only with poor performance but also with an added number of bugs and quirks that is the inevitable result of hundreds of thousands lines of code that is now between you and your customer.

    If I didn't knew better, I would believe that Rod & Juergen made Spring after my (wish) specification! Read for example this old posting, (and many others like it)

    about the disappearance of the Synclavier,
    http://www.theserverside.com/news/thread.tss?thread_id=16739#67162

    Regards
    Rolf Tollerud
  30. It depends on what you want to use WebLogic for. If you're not going to use EJBs, the class loader won't load any support classes for them. The same goes for other J2EE services.

    There is also a lightweight version of WebLogic (Express) if you don't need to use EJB or other services like JMS.

    But WebLogic Express has nothing to do with preloading classes or taking a peformance hit for things you're not using. It's about price!
  31. House of Owls[ Go to top ]

    and guess what a group of owls is called !
    a Parliament - according to Jboss's Juha
    thank u MR speaker !
  32. Murphy's Laws: If anything can go wrong, it will.
    If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. If there is a worse time for something to go wrong, it will happen then


    I think that the J2EE developers in the world is descendants to naive old VB developers from 1992, - you know, the kind of developer that make 26 separate buttons, each a independent and complete window with its own loop..when the user is asked to choose a letter on their windows 95 box.

    For every ca 1500 lines of code in a 3 year period you are going to have an "issue" that you have to sort out with your customer.

    So the arithmetic is simple. Just take the total number of delivered code including third party software and divide it by 1500. Then you know approximately how many unpaid visits you will have to do..

    So there are lots of reasons to avoid a big J2EE App Server at the customer.

    So unless your customer is a beautiful girl- use Spring! :)

    Online Survey Ponders Java App Reliability
    http://www.theserverside.com/news/thread.tss?thread_id=22504

    Regards
    Rolf Tollerud
  33. P.S. Conclusion[ Go to top ]

    The main reason to become a J2EE App Server consultant can be to get a social life! (When you are out to fix all the problems you can meet charming and interesting people ;)
  34. Spring is better[ Go to top ]

    Ok, so I stop using EJB's session beans for business logic and stop using EJB's entity beans for simplified persistence.

    Then, I replace them with Spring and Hibernate.

    What exactly have I gained?
  35. Spring is better[ Go to top ]

    Well, in my case, I gained money. Simply because I am paying for the host service and a non-EJB host is less expensive than an EJB host. Other than that, maybe save time because you don't have to configure an ejb.xml. I have nothing against EJBs. I think they are great. I was looking for the most economical way to serve my web app which in-turn dictates the design. If the cost of the host is irrelevant (if you are your own, for example) then you don't save much and should keep doing what you are doing.

    Michael
  36. Spring is better[ Go to top ]

    Ok, so I stop using EJB's session beans for business logic and stop using EJB's entity beans for simplified persistence. Then, I replace them with Spring and Hibernate.What exactly have I gained?
    You gain immense productivity with Hibernate. Hibernate is so good that we hardly spend any time on the persistence/ORM layer. All of this is taken care of by utilizing Hibernate and its associated tools and integrating them into our build environment. We point Middlegen at our database, and it generates all the Hibernate mapping files. We then use the hbm2java tool to generate POJOs for the Hibernate mappings. That's it..and you have the whole persistence/ORM layer taken care of w/o writing a single line of code (it takes a few days to setup the stuff and integrate it into your build, but after that, there is nothing that you have to do as far as persistence/ORM is considered). Also, there are no DTOs involved...it's the same POJO that you use in the business logic layer as well as your view layer. Hibernate rocks!
  37. Spring is better[ Go to top ]

    ...immense productivity with Hibernate. Hibernate is so good that we hardly spend any time on the persistence/ORM layer.
    With the right tools, the same is true for Entity EJBs. Other than generting the classes etc., WSAD will also generate simple JSPs to "front" the simpler tasks.
  38. Spring is better[ Go to top ]

    ...immense productivity with Hibernate. Hibernate is so good that we hardly spend any time on the persistence/ORM layer.
    With the right tools, the same is true for Entity EJBs. Other than generting the classes etc., WSAD will also generate simple JSPs to "front" the simpler tasks.
    If you can name those tools, I would much appreciate (I know there are some tools like XDoclet, etc but you still have to do a lot of stuff to correctly map all the table relationships (1-1, 1-M and M-M)). If entity beans were as productive and as flexible (I know the EJB QL is pretty lame) as Hibernate, why do you think most people don't use them and instead use non standard frameworks like Hibernate, etc?
  39. Spring is better[ Go to top ]

    Shireesh: why do you think most people don't use them and instead use non standard frameworks like Hibernate, etc?

    First, I really hate the use of the term "non-standard" here. Yes, you can say that it isn't a JCP standard, but is that really what you mean? Sometimes, the best solution to a problem is not going to be based on a JCP standard, so I would not look at this as an automatic disqualifier, although it is one aspect to consider when making a decision.

    Second, Hibernate is an "free and open source" software license, and that can make a compelling argument for its use in projects that would otherwise never consider it. So for the number one reason why people use Hibernate, look no further than the price tag for the software license. Again, there are a lot of costs involved with software development, and too often people choose the wrong software because of cost, so I suggest using this only as one aspect of a choice.

    Third, (IIRC) Hibernate was based on problems that Gavin experienced when he was doing J2EE development, and thus it solves some real world problems. That is far different than certain technologies (like the original CMP 1.0) that were obviously designed by space aliens. So chances are good that if your problems are similar to other happy Hibernate users, that it could help solve your problems too. Hibernate is not a one-size-fits-all solution, though. OTOH, it's one of the best "free" toolkits for doing ORM.

    If you're doing J2EE development, particularly with a commercial J2EE server and/or commercial development tools, and your application's data access is transactional, then you should also be evaluating entity EJBs as one option. Also, JDO is a good option for a lot of ORM tasks; some JDO implementations come with pretty extensive tools for accelerating development.

    $.02

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  40. Spring is better[ Go to top ]

    Cameron: "If you're doing J2EE development, particularly with a commercial J2EE server and/or commercial development tools, and your application's data access is transactional, then you should also be evaluating entity EJBs as one option. Also, JDO is a good option for a lot of ORM tasks; some JDO implementations come with pretty extensive tools for accelerating development."

    All this is true but "particularly with a commercial J2EE server and/or commercial development tools" is superfluous because everything Cameron says applies equally to Spring where you can do Global transactions (using JTA) or Local transactions (with JDBC) programmatic or declarative even with POJOs. Hibernate transaction manager is build-in as is JDO transaction manager. To change is just a configuration issue. You do not need EJB, the same component runs in all contexts.

    But if you absolutely want EJB then Spring makes that easier too than with a "commercial J2EE server" (please include JBoss).

    So there is no reason to go outside Spring that have all the signs of going to be "the industry standard" (in Java,.NET and Mono), especially with JSF (coming in Spring 1.3) that are so similar to .NET web controls.

    Regards
    Rolf Tollerud
  41. Spring is better[ Go to top ]

    Spring with Tomcat/Resin is a Weblogic killer.
  42. Spring is better[ Go to top ]

    Cameron: Shireesh: why do you think most people don't use them and instead use non standard frameworks like Hibernate, etc?First, I really hate the use of the term "non-standard" here. Yes, you can say that it isn't a JCP standard, but is that really what you mean? Sometimes, the best solution to a problem is not going to be based on a JCP standard, so I would not look at this as an automatic disqualifier, although it is one aspect to consider when making a decision.
    Cameron...you got me wrong here. First off, I am a great Hibernate fan...standard or not period. All I meant when I said it is not a standard is that it is not a standard Java/J2EE API like JDBC or the entity beans. That's all...nothing more than that.
    Cameron: Second, Hibernate is an "free and open source" software license, and that can make a compelling argument for its use in projects that would otherwise never consider it. So for the number one reason why people use Hibernate, look no further than the price tag for the software license. Again, there are a lot of costs involved with software development, and too often people choose the wrong software because of cost, so I suggest using this only as one aspect of a choice.
    Like I said Hibernate is rock solid and I like it very much...again, no issues here.
    Cameron: Third, (IIRC) Hibernate was based on problems that Gavin experienced when he was doing J2EE development, and thus it solves some real world problems. That is far different than certain technologies (like the original CMP 1.0) that were obviously designed by space aliens. So chances are good that if your problems are similar to other happy Hibernate users, that it could help solve your problems too. Hibernate is not a one-size-fits-all solution, though. OTOH, it's one of the best "free" toolkits for doing ORM.If you're doing J2EE development, particularly with a commercial J2EE server and/or commercial development tools, and your application's data access is transactional, then you should also be evaluating entity EJBs as one option. Also, JDO is a good option for a lot of ORM tasks; some JDO implementations come with pretty extensive tools for accelerating development.
    Again, no issues here...I don't even know why you replied to my message instead of replying to the parent message, where the user asked why did he have to use hibernate instead of entity beans, for which I replied and explained why he should.
  43. Hibernate, EJB, JDO, ...[ Go to top ]

    Shireesh: Again, no issues here...I don't even know why you replied to my message instead of replying to the parent message, where the user asked why did he have to use hibernate instead of entity beans, for which I replied and explained why he should.

    Sorry about that :-). I was trying to relate my own opinions / experiences, not to argue.

    We've got J2EE projects going on (both internally for demos as well as externally with customers) with Hibernate, JDO and entity EJBs, so I'm getting to see more and more of the pros and cons of each. I'm hoping to be able to get a demo app published sometime showing how they compare and contrast.

    Both JDO (the spec, as well as some specific vendors' implementations) and Hibernate seem to have really "come into their own" recently, and -- somewhat suprisingly -- entity EJB is also very usable with the top app servers (like BEA/WL and IBM/WS) and corresponding tools (like WSAD) -- which is not to say other combinations are not also good, but I can only relate what I'm actually getting to see in the market. It almost feels like all those amazing things that the specs promised three to five years ago are now coming to fruition. I think what developers could benefit from are some "recipe guides" that explain when to use (and more importantly when to avoid) specific technologies.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  44. Hibernate, EJB, JDO, ...[ Go to top ]

    Cameron: We've got J2EE projects going on (both internally for demos as well as externally with customers) with Hibernate, JDO and entity EJBs, so I'm getting to see more and more of the pros and cons of each. I'm hoping to be able to get a demo app published sometime showing how they compare and contrast.
    Great! Looking forward to your demo app.
  45. Spring is better[ Go to top ]

    ... You gain immense productivity with Hibernate. Hibernate is so good that we hardly spend any time on the persistence/ORM layer. All of this is taken care of by utilizing Hibernate and its associated tools and integrating them into our build environment.
    Just came off a project where we used Hibernate for persistence.. Our persistence needs were complicated by the fact that we had triggers to capture history records.. history entries were tracked using version numbers..(so, each time data changes, version goes up by one and the data record gets added to the history table)
    Due to the structure of the triggers, we were constrained to having only one update per version..
    It was a nightmare to get Hibernate to work properly.. Going through the hibernate logs ( BIG logs! ) was a nightmare and sometimes i would see illogical sequence of events like
    (1) insert something into a table
    (2) delete the inserted record
    (3) re-insert the record..

    Added to this was the facts that I am a Hibernate newbie and the persitence layer was already developed when i got into the project and had to make changes. I don't know about other people, but there was no way that i could make sense of the documentation.. I could not go to a specific section in the documentation and try to resolve my immediate problem ( It seemed like i had to read the entire documentation, understand the abstractions provided by Hibernate to understand a problem in a specific context.. great, if you have a lot of time on your hands.. frustrating if you are working on a production bug that has to get resolved by the end of the day. )

    Maybe Hibernate is good.. But i'd take good old JDBC anyday where i have more control.. For a framework that was supposed to make things easy, it sure did make them overly complicated and cumbersome..
  46. Spring is better[ Go to top ]

    But Spring does not force Hibernate or any other database layer upon you, you are free to choose iBATIS, the JDBC abstraction layer or any other system including your own. Spring > flexibility > still rules.

    But when will Spring come to C#?

    I don't think people really understand the implication of Spring for .NET. For the first time there will be a common context of understanding between the two camps. But I admit that the Microsoft guys will have the greatest advantage from it..

    Regards
    Rolf Tollerud
  47. Spring is better[ Go to top ]

    Rolf,

    I'm going to be vactioning in Europe this summer. Can I meet you and get your autograph please?
  48. Hi Race,

    Please don't be grumpy but you have to admit that things generally moves the way I want :)

    When Spring exist for C#/.NET Java guys will have lost their last advantage over the MS developers. May I ask you one thing. Do you see this as something sad or good? That is: Would you rather prefer to have some knowledge that is not universal or do you adhere to the principle "spread the light as much as possible"?

    Regards
    Rolf Tollerud
  49. Hi Race,Please don't be grumpy but you have to admit that things generally moves the way I want :)When Spring exist for C#/.NET Java guys will have lost their last advantage over the MS developers. May I ask you one thing. Do you see this as something sad or good? That is: Would you rather prefer to have some knowledge that is not universal or do you adhere to the principle "spread the light as much as possible"?RegardsRolf Tollerud
    Create account on http://sourceforge.net and clone Spring,
    if you know both .NET and j2ee then I think it will take a week to clone it. Just do it and we will see how Java guys lose their last advantage over the MS developers next week.
  50. no problem[ Go to top ]

    Juozas: "..clone Spring, if you know both .NET and j2ee then I think it will take a week"

    Yes I will do that. I shall just finish my study of the Cello first which I began last week. I went to a concert with Rostropovich and after I got home I tried to play. Unfortunately it didn't fell out so well. I wonder why?

    I think I was not sitting near enough! So I will try again on Saturday and the next week I will convert Spring.

    Regards
    Rolf Tollerud
  51. no problem[ Go to top ]

    Juozas: "..clone Spring, if you know both .NET and j2ee then I think it will take a week"Yes I will do that. I shall just finish my study of the Cello first which I began last week. I went to a concert with Rostropovich and after I got home I tried to play. Unfortunately it didn't fell out so well. I wonder why?I think I was not sitting near enough! So I will try again on Saturday and the next week I will convert Spring.RegardsRolf Tollerud
    Yes, it is very trivial to implement or to clone framework, but it is not trivial to "sell" it, I hope .NET developers are more "hungry".
    BTW .NET is framework implementation too, are you going to implement something better ?
  52. Rolf,

    I'm not grumpy at all. I don't care who wins the software race. I'll write Notepad documents if it pays enough. I'm a contractor so to answer your question, I guess I would prefer to not spread the light as far as possible. I try to exploit every advantage I have over other developers. It's a dog eat dog world. Once IT development has been completely commoditized and rates have bottomed out, I will be well onto another line of work. I write code for no other reason than because it pays well.

    Cheers!
  53. frustrating[ Go to top ]

    Going through the hibernate logs ( BIG logs! ) was a nightmare and sometimes i would see illogical sequence of events like
    (1) insert something into a table
    (2) delete the inserted record
    (3) re-insert the record..
    Of course, Hibernate will never do something like that of its own accord. I absolutely guarantee you that somewhere, someone wrote code that explicitly saved, deleted and then resaved an object ;-)
    the persitence layer was already developed when i got into the project and had to make changes
    Hum, combined with your last observation of strange behaviors, could it be that you might be assigning blame a little low in the stack? ;)

    It is certainly possible to write a broken persistence layer with Hibernate. Hibernate is not a panacea, and we do not sell it as such. Persistence is complex and no tool will remove all the risk associated with it.

    Nevertheless, we think that Hibernate does reduce risk significantly, for the kinds of applications it was designed for.
    I could not go to a specific section in the documentation and try to resolve my immediate problem ( It seemed like i had to read the entire documentation, understand the abstractions provided by Hibernate to understand a problem in a specific context.. great, if you have a lot of time on your hands.. frustrating if you are working on a production bug that has to get resolved by the end of the day. )
    Certainly, we expect you to understand Hibernate properly before you try to develop with it. You simply can't get good results with an incomplete understanding, and without having read the documentation.

    So it is really not at all surprising that you had problems.
    But i'd take good old JDBC anyday where i have more control
    For some kinds of projects, "good old JDBC" is great. For others it is not.
  54. Spring is better[ Go to top ]

    Ok, so I stop using EJB's session beans for business logic and stop using EJB's entity beans for simplified persistence. Then, I replace them with Spring and Hibernate.What exactly have I gained?
    Two things immediately come to mind.

    You gain the ability to create an object-oriented application with a domain model that uses inheritance where appropriate. You're also free from other hard restrictions and recommended EJB practices (e.g., don't make your entity beans reentrant) that impose arbitrary limits on your domain model.

    You also gain the ability to write unit tests against your domain objects that can be run inside your IDE, greatly reducing the unit test, code, unit test cycle.

    If your business logic is trivial and your application(s) have limited complexity EJBs are fine.

    If you're not writing automated unit tests then the testing issue doesn't apply to you.

    If you are writing complex applications and you're employing the engineering practice of writing automated unit tests, you'll be much more productive with POJOs than with entity beans.
  55. Spring is better[ Go to top ]

    A final word :
      J2ee Framworks should be provided as seperate solutions. Hibernate for ejb tier,Struts for the web tier etc... To assemble a wholistic framework that could be the all in one solution can not be good option for a developer who needs to keep in control. And in any case , ALL these frameworks can not provide an alternative to Datawarehousing in case of building a real world enterprize solution.
  56. Spring is better[ Go to top ]

    A final word :   J2ee Framworks should be provided as seperate solutions. Hibernate for ejb tier,Struts for the web tier etc... To assemble a wholistic framework that could be the all in one solution can not be good option for a developer who needs to keep in control. And in any case , ALL these frameworks can not provide an alternative to Datawarehousing in case of building a real world enterprize solution.
    Consider you don't lose any solution separation, by using Spring: it's not a "wholistic" framework in the sense it removes options. It GIVES options, and provides tools that you would have to implement by yourself in terms of integration: check out the hibernate integration, it simply implements the same patterns (open session in view, thread locals for session and transaction info propagation, callbacks and templates that reduce the amount of plumbing code...) you would have to write if they weren't supported. Struts integration, coming out-of-the box in the 1.0.1 version which is near (I think it will be released during the next week) is simply the "Spring integrated version" of a bunch of solutions that everyone using SPring and struts together was implementing with "non spring" code. I surely trust the Spring provided solution to be better of the one I have implemented myself, because it includes the work of different people, and more than that it has the "spring logo", which to me works as a quality cerftification.

    You don't lose an ounce of control, with Spring, and you strongly reduce the risk of losing control of what you've done in the future.
  57. You can't say that Spring is better than WebLogic because it really dosn't make sense. The first is a framework and the second is a server.May be you can say a solution that uses Spring on WebLogic is better than a solution that uses EJB on WebLogic.
    I'm not sure why you're throwing Spring into the mix, because you can run Spring equally on Tomcat AND WebLogic.Your argument bascially boils down to whether Tomcat is superior to WebLogic.
    Peter,

    Good points there! Spring is indeed an application framework, not an application server; this can't be repeated often enough. Unfortunately, recent efforts by certain app server vendors try to blur that distinction from the bottom, adding to the confusion. And EJBs are far too often used as high-level local components within an application, which is not what they're good at.

    From my point of view, an application framework is about the application space; this is clearly distinct from the system services space. Spring addresses infrastructure gaps in the application space with lightweight solutions (leveraging all sorts of existing tools where possible), while the J2EE spec and J2EE app servers are inherently all about "big iron" system services.

    Spring does enable you to decouple your business logic from concrete environments like JNDI, JTA, and EJB: You can run your application components in any environment, as far as possible. Spring will take care of the wiring and plumbing: passing in resources and config values, applying transaction strategies, etc. This also naturally allows for easy unit testing.

    So it's somewhat pointless to argue that Spring can "replace the application server": It rather complements an app server, as framework to be used within an application. If you run your application components in a J2EE environment, Spring allows them to leverage the system services that are available there, like JNDI DataSources and the JTA transaction manager.

    However, if you don't actually *need* those system services, for example because you're just accessing a single database and thus don't need distributed transactions in the first place, Spring offers alternative strategies that can run in any environment, be it a J2EE web app in plain Tomcat, a standalone app with a Swing GUI, or a unit test suite.

    Note that Spring has numerous adopters that use it for standalone applications, completely outside a J2EE environment, typically using Hibernate or JDBC as data access strategy. Still, most people use it within J2EE web applications, happily deploying to Tomcat, Resin, WebLogic, WebSphere, whatever - using simple WARs but still achieving declarative transactions etc.

    It seems that Spring is pretty unique as a Java application framework in addressing not only J2EE apps but also the widely neglected area of (database-driven) non-J2EE apps: having similar facilities available there (e.g. for transaction and resource management), using the same configuration style, being able to share your application components between J2EE and non-J2EE apps.

    Juergen
  58. The good guys lightweight and KISS always win in the end :)
  59. 1. JSTL and Struts taglibs in JSP using Tiles for layout2. Struts DispatchAction and ActionForm subclasses3. Spring BeanFactory-based service layer and application configuration4. DAO objects that extend Spring's HibernateDaoSupport classes and use Spring's HibernateTemplate internally.5. Transaction management using Spring's HibernateTransactionManager6. Hibernate Session management using Springs's OpenSessionInViewFilter7. Hibernate for persistence (Oracle)8 Tomcat 4.1.29 (light load intranet deployed app)
    That's what I call overkill.
    It's maybe because you've never used Spring + Hibernate: it looks overkill to someone who has never used it, but it's very simple after a couple of days spent understanding ioc concepts and spring configuration. I suggest you to read the spring tutorial and have a look at the example applications.
  60. OpenSessionInViewFilter & MVC[ Go to top ]

    Ravi,

    Can you explain why this pattern doesn't violate MVC since I have to import Hibernate jars into my web tier in order to implmement OpenSessionInView ?

    Regards,

    G
  61. OpenSessionInViewFilter & MVC[ Go to top ]

    Ravi,Can you explain why this pattern doesn't violate MVC since I have to import Hibernate jars into my web tier in order to implmement OpenSessionInView ?Regards,G
    I'm sure the MVC "purist" can make the argument that it does--b/c the servlet filter has a dependancy on the hibernate jars, and assuming that the filter is part of your "controller" then I have allowed the controller to have a dependancy on the implementation details of my model (my hibernate-aware POJO domain objects) I'm not that much of an MVC purist :-)

    In my case, its not a big issue b/c my actions and views only "see" the POJO domain object interfaces and have no idea that they have hibernate decorators or proxies. They have no direct dependancy on hibernate.

    Additionally, my application's requirements don't mandate that my application's layers be physically seperated (ie-, they all live in a single webapp in a single instance of Tomcat), so I never have a duplicate set of hibernate jars that I have to deploy, and b/c I'm not using an EJB container, I don't have to worry about the annoying classloader issues that can occur then you use the same classes in both the web and ejb container.

    So, allowing this dependancy was really a design decision that we made based more on our knowledge of the client's production environment topology (one web container) and less on "purist" MVC practice.

    -Ravi
  62. Struts because of the skillset??[ Go to top ]

    This is something I don't get... the hardest part about learning to use the likes of Struts, is the MVC component. Once you've used one MVC, it's pretty straightforward picking up another one.

    So why oh why do people keep using something over-complicated such as Struts? If your app is mainly used to display info. take a look at the likes of Webwork. If your app has a lot of data input, try looking at Tapestry.

    Hibernate rocks tho.
  63. I don't understand what's wrong with simple JSP and plain JDBC/SQL for simple or lightweight apps? Someone will call you stupid? Or do you want to demonstrate your overengineering skills to the wretched soul who needs to master four to six involved frameworks to be able to maintain your me-too app?
  64. I don't understand what's wrong with simple JSP and plain JDBC/SQL for simple or lightweight apps? Someone will call you stupid? Or do you want to demonstrate your overengineering skills to the wretched soul who needs to master four to six involved frameworks to be able to maintain your me-too app?
    nothing is wrong with that. It's the good old "right tool for the right job" theme. The only important thing is that you make *informed* decisions which you can *explain* and justify to your customer/manager.
  65. I don't understand what's wrong with simple JSP and plain JDBC/SQL for simple or lightweight apps? Someone will call you stupid? Or do you want to demonstrate your overengineering skills to the wretched soul who needs to master four to six involved frameworks to be able to maintain your me-too app?
    There's nothing "over-engineered" in a solution based on Spring and Hibernate: what results is a much, much, much simpler application than one based on "simple JSP and plain JDBC/SQL". Just look at the petshop implemented with or without Spring: the Spring + Ibatis petshop is incredibly simple. Look at the other examples in the Spring distribution: none of them feels "over-engineered", all of them are very simple.

    You just have some .jar more in your WEB-INF/lib dir, a lot less code and an architecture that is likely to be much more solid and understandable.
  66. I am glad most of u appreciate the efficiency of simpler and straighforward j2ee practice. Knowing this would have saved me loads of time instead of spending months checking most frameworks(Avalon,Open for Business,WAF...). Keep it simple stupid... that's the word
    faisal
  67. I am glad most of u appreciate the efficiency of simpler and straighforward j2ee practice. Knowing this would have saved me loads of time instead of spending months checking most frameworks(Avalon,Open for Business,WAF...). Keep it simple stupid... that's the wordfaisal
    Keep it simple is the word when what you have to do is simple. When the problem domain is complex, the solution tends to become complex: and that's where the frameworks have a role.
  68. Tell me how often, in a software project, did you say: Ho, nice a new technologies (JSF), lets change the presentation layer (Struts) and replace it with the new thing. It is going to be better (lot better ?). In software, we program with layer to not impact other layer, yes we can replace a layer but how often. Did you ever did that ?
  69. I resonnate with this notion that DTOs are optional. In my shop, my folks think I'm a freak for thinking this way. It's great to see others out there who have come to the same conclusion.

    DTOs can be really useful, however. They are not necessarily "evil" as Gavin King may suggest. From King's perspective, there's no need for these bean-like data objects when you can simply detach (in Hibernate parlance, evict) objects from their Hibernate session. He's right when we're programming in the small. However, I see two problems with adhering to this idea as a law (for me using the word "evil" has that kind of force):

    1. I have found that in a sufficiently complex application, the DAO static structures necessarily contain additional abstractions that should be kept secret from outside of the business service. So, I can conceive of a software system where the shared domain model has different structural relationships than the persistence model.

    2. I have also found that in applications that provide remotable session facades (e.g. using Stateless Session Beans), I'd like to transmit those object graphs over the wire. Often, Hibernate objects are byte-code enhanced. This prohibits that transmission.

    In my experience, #2 is pretty rare. In fact, when you get to that stage, we're talking about a whole nother genre of application (e.g. a front-end for an Operational Data Store).

    #1, however is not uncommon. I can think of rather simple constructs that contain these so-called secrets. For example, let's say I have a class that represents a document: Document. A document has a revision number (every time you edit the document, we increment the revision #). Let's say, I'd like to allow those other than the author to view the document, but not edit it. Let's further say that those same people can (as an alternative to editing the original document) create a linked-copy of the document (let's call it a Version of the original document) in such a way that it is a separate document with its own revision history, but still has a link back to its parent document. One reasonable way to model this would be to create a second abstraction called a Version. However, I'd like to expose ONLY the notion of a document outside of my document management service. My DocumentImpl will have all these relationships between it and the VersionImpl class. In this case, I'd say, I would start thinking about creating a parallel domain model that may flatten this Document+Version construct into a single Domain Model Document.

    So, I say, "hurray" for the support for the idea of using detached objects as a first-round implementation. But be aware: avoid the real evil of extraneous coupling (by exposing the business service's secrets) by opting for a separate domain model. Yes, it's an additional model to maintain. But at that point in your application's life, to couple your persistence structures with your business and presentation structures leads to an increasingly brittle application.
  70. DTOs useful?[ Go to top ]

    DTOs can be really useful, however. <
    Sure, /occasionally/.

    >> They are not necessarily "evil" as Gavin King may suggest. <
    I am sometimes guilty of overstatement. :) My "DTOs are evil" rant is intended to make people think these issues through. Remember, it was not so many months ago that DTO was considered an "Obviously Good" pattern by most of the J2EE community.

    If you have a real concrete requirement for DTOs - that is not simply that your persistence mechanism doesn't allow serialization of your persistent objects - of course you should use them.


    >> I can conceive of a software system where the shared domain model has different structural relationships than the persistence model. <
    It is not inconcievable. It is, however, /unusual/.


    >> I'd like to transmit those object graphs over the wire. Often, Hibernate objects are byte-code enhanced. This prohibits that transmission. <
    This is just not correct. Hibernate allows persistent classes to be serialized via RMI. It Just Works. You /do/ need hibernate.jar and cglib.jar available on the client side, but this is not really a problem in most environments.


    >> So, I say, "hurray" for the support for the idea of using detached objects as a first-round implementation. But be aware: avoid the real evil of extraneous coupling (by exposing the business service's secrets) by opting for a separate domain model. Yes, it's an additional model to maintain. But at that point in your application's life, to couple your persistence structures with your business and presentation structures leads to an increasingly brittle application. <
    One of the goals of ORM is to interpose the mapping solution between the "persistence structures" (the database tables) and the domain model (the persistent classes) and have it act as a level of decoupling. So, indeed, if you use ORM technology, you should already achieve some degree of decoupling without the need for DTOs.

    Thanks for the interesting post :)
  71. 2. I have also found that in applications that provide remotable session facades (e.g. using Stateless Session Beans), I'd like to transmit those object graphs over the wire. Often, Hibernate objects are byte-code enhanced. This prohibits that transmission.
    <br>
    In my experience, #2 is pretty rare.

    Hello,

    I don't think that #2 is that rare. You often have to transfer objects "over the wire" if you physically separate Web-Container and EJB-Container within a clustered environment. In fact you don't even have to separate the containers, since when it comes to session failover within a cluster, those objects may be transfered between different servers in the cluster.

    Regards,
        Dirk
  72. aren't all mvcs too complex?[ Go to top ]

    Jsp, tapestry, etc, all seem overly complex.
    Servlets and forms are really very simple as is writing
    the degree of abstraction you need for your application.
    The value add seems small given the degree of indirection
    required.

    Hibernate itself, unless you really need
    to backend objects in a RDBMS, isn't that
    easy either. Complex object models are not generated
    correctly and are difficult to use. The mapping of
    objects to sessions is frustrating.
  73. true[ Go to top ]

    That is true...and Just when u fully master them ...u realize that u don't need them

    time to go back to basics
  74. if you define "business logic" as including the creation new domain objects. Even if you don't believe this is business logic, it is reusable logic that has been coupled to specific technologies (Struts & HTTP). Porting this application to another channel, for example portals, would require duplicating the action code in the portlet.

    I've found that the "disconnected object graph" type architecture works fine for simple UI's and read only data but breaks down when dealing with more complex UI's. Consequently, our apps use the architecture prescribed in Mark's article where possible, but a "model" (DTO) string object that implements a Editable interface for editable domain objs. The model object knows if its new, deleted or changed (Editable interface) and how to create itself from a domain obj.

    btw, this was a really GREAT article.

    Jeff
  75. sites using Spring[ Go to top ]

    We currently testing Webwork, Spring to be used as framework for our site. Is there a list of sites using Spring?