Re: Does basicPortal really separate the business logics and views?

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 mvc-programmers@y..., "V. Cekvenich" <vicc@u...> 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
> > 
> >