RowSet is much, much better than resultset. No memory leaks, easy to create and it auto destroys. Plus it keeps the data after the disconnected. No one should be using resultset for anything anymore. Only rowset is an interfaces.
Sun implementation of RowSet comes without source code! So when minor driver issues come up, I had to work around it. Alternatives are JDBC drivers, such as Oracle, that have a RowSet implementation. Then I found a jxUtil RowSet implementation on SourceForge. Rowset with source code; I like that. This way, if there is a driver issue, I can trace the code in a debugger. I also move away from Sun in general, for the good of Java, since they can't sell SW and have slow HW, they might not be around in a few years, like Data General or DEC, etc. See: http://messages.yahoo.com/?action=q&board=SUNW I use IBM VM, Jikes (JRockit VM, TowerJ, Kava, there are a a dozen VMs out there, some open source VMs). For HW, Linux is much faster than SlowLaris I found and www.tpc.org says. The sooner Sun goes away (with their EJB joke) the better Java can compete with .NET on an even playing field. .V kaeyeh wrote: > 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
