in reply to CGI::Application

What do you mean by "model"? Other responses refer to the model as the ORM library being used, but I use the term differently. For me, the model is the package where I place my business logic. It is more than just the database access component - it includes validation, data transformation and everything that doesn't simply include receiving web input or sending a new page to the user. This means my command-line interfaces use the same models as the web interfaces, and know nothing about the web.

(BTW, I use DBIx::Class with my CGI::App apps)

Replies are listed 'Best First'.
Re^2: CGI::Application
by james2vegas (Chaplain) on Aug 23, 2009 at 21:51 UTC
    That sounds like Database plus ORM to me, especially one like DBIx::Class, where you can extend default DBIC classes to add transformation and validation (beyond what your database provides), or any other business process.
[reply]
      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)
[reply]
        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]
Re^2: CGI::Application
by SilasTheMonk (Chaplain) on Aug 23, 2009 at 22:44 UTC

    I think astroboy has touched upon the problem here.

    Model means business logic encapsulated in a nice way. Typically this reduces to a series of products/clients/orders which can be modelled on a database. Hence the confusion between ORMs and models.

    I was having a different problem. There the business logic is about keeping the maintenance of the site down. The only recognizable object I can discern in the websites I'm currently looking at is the "page". I can reuse many templates across multiple templates but I was ending up with far too much code managing template parameters especially when a parameter can be used across several pages. Now what would an ORM give me? It would give me a different interface to the database (in fact another interface to learn) but it would not in itself have solved my problem.

    Edit: I am working on some modules that I am already confident solve my problems. I still need to do some work on them but the current code is in github under the repositories: cgi-application-pagelookup/cgi-application-plugin-pagelookup/cgi-application-plugin-pagelookup-sitestructure/cgi-application-pagelookup-lang.

[reply]

In Section Seekers of Perl Wisdom