|
in reply to Re^2: CGI::Application
in thread CGI::Application
Not all of your business logic (model) is necessarily DB related or should be part of your ORM. You might have to do things like FTP files, perform LDAP lookups and a myriad of other things. If you simply use your ORM in your controller (and a lot of web apps do this), then you've lost the ability to reuse your code outside of your CGI::App controller. (e.g. your boss or marketing dept now decide you need a batch or a SOAP interface to the same business logic, but your existing logic isn't reusable because it's all in the controller) |
Re^4: CGI::Application
by james2vegas (Chaplain) on Aug 23, 2009 at 22:40 UTC
|
A model should only be the representation of the data and domain logic, the view should only be a rendering of the model data and the controller should respond to events and trigger changes in the model. Given that, sometimes a thin extension over the ORM is sufficient for a model, sometimes you need much more, but CGI::Application doesn't force you to a specific model system, and that is a good thing. | [reply] |
|
|
I absolutely agree it does not force you to use a specific model and that that is a good thing. But neither does it provide an off the shelf solution (let alone two or three) for the model space. There are also many modules which can be optionally used with CGI::Application but the data about whether they are any good is rather thin. That was my original point.
| [reply] |
|
|
I agree, though if as astroboy states, you should be able to keep your same models if you move between desktop GUI, CLI or Web apps, how would a cgi-app solution for the model space help in that?
Anyway, as to CPAN rating, I am now looking to review the cgi-app modules I use.
| [reply] |
|
