Great question! The short answer is that I did not find the business logic layer practical, and I think this design is a sweet spot, simple, reusable and productive with less down sides that other designs.
The long answer is that it is a bit of a gray area: To me, the development must be simple. Complexity cold Hold you Back. It must also use Software Engineering when application reduces cost of maintenance, development of increase performance. Many theoretical improvements exist and I have tried many. 1. Some were improvements some were not practical others did not add value in my experience. I am trying to have best practices code. Also something that is better than .NET, which has ASP WebForms and disconnected ADO. So I chose MVC. To me. Beans and DAO are in persistence/model. JSP are the presentation, as thin as possible, since they are not reusable. Actions are the controller, with 0 knowledge of persistence/model. 2. There is also old debate in struts development as to if form beans should be an interface, and I think it should. So what is business objects or business logic? What about DO, VO, DTO, Collections, etc.? Again the simple answer is I do not need them. KISS! Those objects are only there to try to optimize EJBs, which I avoid for scalability reasons. Plus the more objects you have the more GC, which is not scalable. Every new must be GCed. So I only have a simple 3 objects design. (DAO, Beans and thin Actions). http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicPortal_07/src/org/commons/DAO/BaseBeanImpl.java?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup 3.Also note above that I am using validator form (not action form), and it should come from commons-validator one day, not the struts.jar. 4. I have clients using beans as SOAP. I SUPER VERY HIGHLY recommend that beans be tested and useable in a console application. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicPortal_07/src/org/apache/unitTest/UnitTestConsole.java?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup The point of MVC is that each module could be unit testable. Also, what if one day basicPortal goes JSF or something else and not Struts? So many reasons that beans should be reusable outside of web or Struts. No mater what you would have JARs you would need. One of the jars you have to deploy is going to be commons-validator. So that is the downside, you have to add an extra jar. Not a big deal if you think about it. What do you have for that? A validate () method, that uses XML for validation, so you could reuse validation anywhere. So benefit. (OT: Current JSF validation is in JSP, hence if you use that validation, you could not reuse it even if you use the same bean 2 times in an war). 5. It is open source, so you get the code and you do not have to extend the validator bean if you chose note to. (Struts does not need you to extend the form bean! In our case, it uses getters and setters for testing and as a concept, but it actual implements a collection so multi row master detail updates and validation work, but a bit more advanced, so just think of it as a java bean) 6. Counter attack: Some design patters just add complexity and are not OO or reusable and slow down performance or scalability, aka Anti Patterns. Hth, .V kaeyeh wrote: > BaseBeanImpl extends ActionForm of Structs. For other types of > interface, say ¡§web service¡¨, business logics really don¡¦t need to > depend on Structs. One implementation to remove it can be: > Class myActionForm extends ActionForm implements > myValueObject {} > > Then pass myActionForm as myValueObject to the business > logic beans. Here myValueObject implements the J2EE center ¡§Value > Object Pattern. > > Kae > > ------------------------ Yahoo! Groups Sponsor ---------------------~--> 4 DVDs Free +s&p Join Now http://us.click.yahoo.com/pt6YBB/NXiEAA/MVfIAA/NhFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _______________________________________________ MVC-Programmers mailing list [EMAIL PROTECTED] http://www.netbean.net/mailman/listinfo/mvc-programmers
