I just got finished reading the J2EE blueprints and walking through the EJB petstore example application. It's amazing how far ahead the Turbine framework is on the concepts they put forth in the book! If you need to use EJBs on a project there's still a huge advantage to using Turbine because it solves over 50% of what your going to have to create from scratch ( controller, view ). And IMO Turbine is much cleaner in its approach and has a more well defined security model. If you don't believe me look at the petstore example and then compare it to how you could do the same using Turbine. At a minimum, if designed correctly, a Turbine application could scale right up to using EJBs when needed by simply placing calls to Session/Entity Beans in the screens and actions. However, There's still an advantage to using EJBs when you have a large number of tables. John McNally gave a good rule-of-thumb for this a while back on the mailing list. What's interesting though is the blueprints emphasize over and over to take into consideration the overhead of using an Enterprise Bean ( remote calls, etc... ) in otherwords, don't use them for every table if not needed. My point here is that even if using EJBs, Turbine can save you a lot of time. And depending on your data model, you could start an application using the peer model and scale up to EJBs in the future if needed ( or your manager falls prey to the EJB marketing campaign ). I'm sure this is obvious to the Turbine veterans, but I thought I throw this out anyhow for the new folks that may be on the fence between Turbine and a full-blown J2EE ( JSP-EJB ) application . -- Dave Bryson [EMAIL PROTECTED] ---------------------- ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
