Vic, Thanks for the comments; I see your points now. Our client just want to have a quick way to check if we've been a good citizen, so they can just take the "model" part in the future and reuse it without any of the view and controller. I also appreciate your ¡§anti-pattern¡¨ thoughts, but I see your ¡§simple 3 object design¡¨ is an excellent pattern itself. Isn't that the MVC (as in mvc-programmers) a well known pattern?:) I think nothing wrong with patterns. It is the people using them make bad decisions. BTW, can you elaborate on what makes you move away from Sun¡¦s cached rowset? Is there any missing features? (I havn't used rowset before)
Regards, Kae --- In [EMAIL PROTECTED], "V. Cekvenich" <[EMAIL PROTECTED]> wrote: > 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/BaseBea nImpl.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/Uni tTestConsole.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 ---------------------~--> Sell a Home with Ease! http://us.click.yahoo.com/SrPZMC/kTmEAA/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
