Is there a(n easy) way to avoid this scenario ?
in reply to avoiding excessive number of methods in CGI::Application and DBI modules
Yes - don't design your application in a way that sucks.
You're thinking as a DBA / programmer, not as a systems analyst. Think about how your application is going to be used. CGI::Application (and similar frameworks) provide user-level mapping to business-level concepts. I had an application that would CRUD over 40 tables. But, because there were only 7 different screens (with options), I had 7 runmodes. Now, based on those options, different things would happen.
Here's another way to look at it - to run reports, I need 2 runmodes - PickReport() and RunReport(). However, I will probably want:
- A class for each report
- One or more base classes for those reports
- A class for each parameter
- One or more base classes for those parameters
- One or more templates for each report (We had 3 - HTML, PDF, and XLS)
- Internationalization support
- Database layering
- Images for look'n'feel
In total, I think we ended up with some 250 files supporting 70 reports. Still only 2 runmodes, though ...
The Perfect is the Enemy of the Good.