Apart from violating the design pattern there is nothing fundamently wrong with this,
Yes. However, what does violating the design pattern mean to the state of the application and how difficult it will be to adapt to new technologies and API.
Speaking only in academic and theory terms, this is no big deal.
But, in commercial settings where you have serious money at stake and a need to be agile, this matters a lot. And violating the pattern means a lot.
For example, say you write an application with 247 Struts Action sub-classes that deal with persistent objects and contain Hibernate persistence logic mixed in with the processing and business logic.
Two years pass.
Your competitor comes out with a new product with a series of fancy Ajax/Flash/WAP interfaces for web browsers, cell phones and the new biometric eye plug GUI.
You now have 400 Struts Action sub-classes in your application.
How much time will it take you to develop a new interface for your application using
Java Server Faces?
How much will violating the MVC design pattern cost your company?
Hibernate code should not be in Struts Action sub-classes. The examples you see are bad examples, but they are just examples. Examples in books/web pages and code in the real business world are two different things.
[ July 09, 2008: Message edited by: James Clark ]