I would say this is reasonable. I get the impression this is the
general approach currently being taken by most Struts developers. There
are two drawbacks I can think of to consider before coming to a final
decision:
1) Unless the code is being generated, there is more manual
labour
I would argue that it is quite easy to reuse your regular classes
as struts form beans. This strategy may involve putting code
into your so-called 'business' classes who's purpose is to help
with certain kinds of 'presentation' level logic. The real question
is, do you want a 2-tier architecture
There is one problem/issue with the EmployeeForm objects. It is likely
the attributes for EmployeeForm will have to be all Strings
after all. The reason is as follows: Let's say you have a web form
where you enter new employee information. This form has a numeric
field. Let's say it's something
3 matches
Mail list logo