When you already have the M, how well does your MVC framework do? O'Reilly editor Andy Oram points out in MVC frameworks and the power of legacy databases how existing databases are a big problem for frameworks that want to make the schema decisions for you.
I've always kinda wondered about how people did real problems. It's a tough thing to show real problems in a demo, so people make toy applications from scratch where they get to decide how things get stored and how they get their data. How does that ORM stand up when you have to get data from multiple sources in different way, such as screen scraping a mainframe for some data but hitting a database server for the other parts? That's a situation I've actually had to program around. Or how about fetching records through a web service as part of the model? When you play with big things, you often start in the middle of a problem after other people, perhaps years earlier, designed something.
That's one of the reasons CGI::Prototype exists. It gives you almost nothing. You can use something like DBIx::Class, but CGIP knows that real work is often complicated enough that you end up overriding lots of any framework, so it doesn't give you much to override. "Default over configuration" might be fine when you can accept defaults, and configuration might be fine when you just need to set-up something, but neither really work for strange problems (and anything interesting seems to be strange). CGIP gives you hooks to fill in any way you like. It's certainly work, but not more work than wrestling with a framework that wants to put your square peg in its round hole.
However, anyone who tells you which framework to use before they even know what you are doing has no real idea which framework might work for you (and should STFU). :)
Catalyst is pretty strongly focussed on the C part of MVC. You can drop in pretty much any M you want. The commonly preferred way to talk to an SQL database is DBIx::Class, but you don’t have to talk to a database at all, and if you do, you don’t have to use DBIx::Class. However, DBIx::Class is very good at mapping out any existing schema you throw at it – it doesn’t place any constraints on how you structure your database. (Oh yeah, and you can use any template engine you want – say, if you already have a pile of templates written.)
So Catalyst and DBIx::Class generally do a very good job of adapting to existing applications.
Re:Catalyst and DBIx::Class: a breed apart :)
brian_d_foy on 2007-10-14T17:06:13
Does DBIx::Class handle the situations I mentioned? How does it deal with data sources that don't understand SQL? Or multiple, disparate data sources (including things that DBI doesn't understand) that the Model needs to merge?
It's not that it's technically impossible to use DBIx::Class in really weird situations, but you end up having to write your own DBD for DBI and maybe some plugins for DBIx::Class, which brings you back to CGIP's idea that if you're going to be overriding most of the stuff, so why even start with it?:) Re:Catalyst and DBIx::Class: a breed apart :)
Aristotle on 2007-10-14T17:50:56
Quoting myself:
The commonly preferred way to talk to an SQL database is DBIx::Class, but you don’t have to talk to a database at all, and if you do, you don’t have to use DBIx::Class.
Re:Catalyst and DBIx::Class: a breed apart :)
brian_d_foy on 2007-10-14T18:25:10
Quoting you:However, DBIx::Class is very good at mapping out any existing schema you throw at it – it doesn’t place any constraints on how you structure your database.
It places a lot of contraints on you. You can't at once say it doesn't restrict you and that if you don't like its restrictions, don't use it. One of those statements has to go. You can quote a single sentence from your post, but I read the whole post and responded to the whole post.:) Re:Catalyst and DBIx::Class: a breed apart :)
Aristotle on 2007-10-14T18:47:39
Are you intent on misunderstanding?
- Catalyst doesn’t tie you to DBIx::Class, so if you prefer a different ORM or don’t have an SQL database at all, you don’t have to use it.
- DBIx::Class places no constraints on how you design your SQL schema, unlike other ORMs, so if you do have an SQL database, it is a good choice that will not limit you.
That is what I said in my first comment.
There is no contradiction in any of these sentences.
Re:Catalyst and DBIx::Class: a breed apart :)
brian_d_foy on 2007-10-14T20:10:01
It's not what you said in the first comment. You said:However, DBIx::Class is very good at mapping out any existing schema you throw at it – it doesn’t place any constraints on how you structure your database.
Now you sayDBIx::Class places no constraints on how you design your SQL schema...
That second statement has a qualifier for schema that's missing in the first. I'm specifically talking about things that aren't SQL, but you keep talking about SQL. That's a problem I often see with people talking about web frameworks: they immediately assume constraints (like a server that understands SQL) that aren't necessarily there.
Just admit that you agree with me: you should to think about the model and the right tool for it. I think you do agree with that, even though you immediately start talking about SQL again.
There's no need for your personal attack on me. Just don't push a particular solution outside of any context when we're agreeing that people should use the right tool for the job.:) (Hey, look at that, a smiley. I think you missed them in all of my previous comments). :) Re:Catalyst and DBIx::Class: a breed apart :)
Aristotle on 2007-10-14T22:33:02
That second statement has a qualifier for schema that’s missing in the first.
How is “schema you throw at DBIx::Class” any less precise than “SQL schema”? What other kind of schema would you throw at it? What other kinds of schemata do you write? Schemata for your cache file path layouts? Or for your IMAP folders?
I think you do agree with that, even though you immediately start talking about SQL again.
I don’t “immediately start talking about SQL again” or anything of the sort. It was Andy Oram whom you quoted who started this stuff about legacy databases and frameworks that make schema decisions for you. But unlike the way you portrayed his statement, his own wording was a blanket assertion that all modern web frameworks work that way. I piped up to say that DBIx::Class doesn’t do anything like that, and that Catalyst is even only loosely coupled to it to begin with.
Catalyst and DBIx::Class, being explicitly non-opinionated, therefore do not suffer the problems that Rails and ActiveRecord have with legacy systems that Andy Oram’s pointed out.
So yeah, in a sense I agree with the exact point. But I disagree with the larger point. I posit that you don’t need to examine every problem up front and then evaluate each framework from scratch. Catalyst is agnostic yet convenient enough that you can settle on it as the default choice, only re-evaluating it if there does indeed turn out to be significant mismatch.
Re:Catalyst and DBIx::Class: a breed apart :)
brian_d_foy on 2007-10-14T23:07:45
Huh. You're talking about CAtalyst again. I just said that we didnt' disagree there.
As for other sorts of schema, I'm using it in the general sense of the word, and your using it in the more limited sense of things that handle SQL. SQL is just a language. Not everything talks SQL, but things that don't talk SQL can still have a schema. But, that's what I've been saying all along.
So, like I said before, if you stop limiting yourself to thinking about SQL, you'll see that we agree.:) Re:Catalyst and DBIx::Class: a breed apart :)
kaare on 2007-10-16T09:35:42
No, you will use DBIx::Class where it fits. Or you will use another ORM, if you like, for SQL like data.
But what Aristotle says is that you will use another M for data that DBIx::Class isn't suited for. There is for example a Catalyst::Model::LDAP (just a wrapper around Net::LDAP).
If your data source is weird enough, you can write your very own Model. Catalyst is happy to let you use any Model Class you include.
