Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

brian_d_foy (44)

brian_d_foy
  brian.d.foy@gmail.com
http://www.pair.com/~comdog/

Journal of brian_d_foy (44)

Sunday October 14, 2007
01:27 AM

Does your MVC framework work when you don't control M?

[ #34673 ]

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). :)


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Does your MVC framework work when you don't control M? 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • 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

    • 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 eve

      • 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.

        • 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. :)

          • 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.

            • 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 say

              DBIx::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 tal

              • 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”

                • 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. :)
      • 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.

  • I found that I prefer to create the schema in SQL and then generate the voluminous DBIx::Class code via SQL::Translator::Producer::DBIx::Class::File [cpan.org]. Then, I just add various convenience methods to the model classes after the fact. While I'm not using this approach for a legacy database, I think it would work well.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.