Re^3: Transferring a Catalyst installation

The other reason is that I think the strict MVC model is not consistent with a good object oriented design . Not my own idea, there was a nice article that convinced me (it may have been the paper talked about here UPDATE: No, it was a different one, but making a similar point).

Now I have not much practice in OO programming and none in web programming, so don't listen to me. But the paper makes some very good points.

Also the data of my web project is very "departmentalized" (i.e. one web page would usually access two and write to one small part of the whole information), this makes files instead of a database possible and quite frankly I loathe databases when it comes to maintenance and debugging

Catalyst seems to adhere more strictly to the MVC design, with separation strictness and its reliance on a database, so that CGI::Application may be a better fit for me even though I also spotted some things I don't like there too.

I really haven't decided yet. For example catalyst seems to depend on database use, only the older of two books about Catalyst mentions how to avoid a database, but it still seems possible to do. Same with object handling. Maybe I have to do a prototype first to help me decide

Comment on Re^3: Transferring a Catalyst installation

Replies are listed 'Best First'.
Re^4: Transferring a Catalyst installation by Your Mother (Archbishop) on Nov 02, 2010 at 17:02 UTC
Catalyst has no dependence nor restriction on any data or view layer at all. No data layer? Fine. 100 data layers including 10 DBs, 5 caches, file maps, webservice calls, parsers, random generators, also fine. No view, fine (but stupid because it means the controller has to do output). 100 views coexisting -- TT to Mason to JSON to XML to LaTeX to PDF -- also fine. The M doesn't mean RDBMS any more than the V means HTML.	[reply]

Replies are listed 'Best First'.

Re^4: Transferring a Catalyst installation
by Your Mother (Archbishop) on Nov 02, 2010 at 17:02 UTC

Catalyst has no dependence nor restriction on any data or view layer at all. No data layer? Fine. 100 data layers including 10 DBs, 5 caches, file maps, webservice calls, parsers, random generators, also fine. No view, fine (but stupid because it means the controller has to do output). 100 views coexisting -- TT to Mason to JSON to XML to LaTeX to PDF -- also fine. The M doesn't mean RDBMS any more than the V means HTML.

[reply]