EJB 2.0 best practices suggested a design pattern where data and behavior were were treated as independent concerns. Stone Age Development (SAD) using structs and procedural programming sounded bad so they were dubbed Transfer or Value Objects, emphasis on "Object".
My EJB 3.0 entities are now full-fledged objects versus SAD artifacts but I'm worried that I have too many @Transient methods. I get this nagging feeling that perhaps I'm violating some principal in not keeping the transient state in some other wrapper class. Is there a rational basis for my concern? I think it is just a regurgitated EJB 2.0 feeling that I should ignore. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3945904#3945904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3945904 ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
