MVC frameworks such as Rails are great for new projects, but they’re hard to integrate with existing databases. Their design reflects more interest in the V than the M. If you have existing data in a relational database that you want to expose to a wider audience, you’re left with the choice of:
- Using your MVC framework to create a new schema (which is designed for simple CRUD access, and probably less well-suited to your data than your hand-crafted schema) and laboriously load the old data, or
- Write a tangled gateway script to translate between the framework’s schema and your schema, perhaps through a batch job (which would kind of ruin the vision of consistent, current data).
I heard this perspective from a veteran Perl hacker in the finance industry at today’s Ubuntu Massachusetts InstallFest. It was a nice, low-key event, by the way, attracting several college students who were new to Linux when I was there, along with a couple teenagers. While veterans played with Beryl-driven graphics or tried at an OLPC system, my colleague laid out the general framework problem and described his difficulty adding a modern web interface for naive users to a useful little scheduling application he developed some time ago.
Given that web mash-ups and visualizations of existing data are of growing interest, and that there’s a movement for more access to public and government data, we need to learn ways not just to develop green-field services with new data, but to reflect the richness of existing relational data.
I whole heartedly agree with this assessment. I developed Dataface (http://weblite.ca/dataface) for this purpose. It is a framework though it allows for development from scratch, one of the primary requirements for it to be able to sit on top of a legacy database and provide a powerful yet simple user interface for the users of the system.
This isn't the case with all frameworks, though it is for "frameworks such as Rails". In the Perl world, there are a various full stack frameworks out there, including Catalyst and Jifty.
Jifty is like Rails, in the sense that you have to play by its rules or rewrite lots of bits yourself. Catalyst is almost more of a framework toolkit, and is pretty agnostic about what model you use, though it has hooks for working with various ORM tools on CPAN.
There's also other MVC frameworks on CPAN, and of course you can always build your own from a dispatcher/controller (say, CGI::Application), templating system (Mason, TT2, etc) and ORM (DBIx::Class, Rose::DB, etc).
I know there are similar ranges of "do it my way"-ness in Python frameworks. I think the fact that Rails has gotten so much attention may confuse people who don't know that there are lots of good frameworks that let you use a legacy database quite easily.
For my own part, I'm in the midst of porting an existing site to use Catalyst, and one of the great things about it is that I can use it's controller bits and plugins, while still using my existing model classes. Since the model classes represent a good 50% of the app, this has made porting feasible, whereas a rewrite would have been out of the question.
Enterprise Objects Framework (the M layer for WebObjects) provides the ability to reverse-engineer the existing database schema to use in the web application, obviating either of those bullet points.
Andy,
I see brian d foy has put a nice response on use.perl.org already (http://use.perl.org/~brian_d_foy/journal/34673).
As brian says, any interesting application has data constraints beyond the Relational model which the M-layer must implement if the DB doesn't.
The update with SQL "scheduling app" that so far only has graphics from Perl is ema.arrl.org/fd . The comments on Catalyst's M-agnosticism (or polytheism?) continue to be such that it may be the right tool for this task and many other ""Legacy needs a web gui", unlike the "the DB is mine" attitude of the many "just like Rails" frameworks.
Thanks to Dave and Steve for useful comments here - I hadn't run across dataface, that may be an easier solution to my .org problem, if not for my $DayJob legacy mountain.
Bill Ricker
use.perl.org/~n1vux
I wholeheartedly agree that there is a great need for simple, intuitive relational database interfaces, especially on the web. In most of my experience, MVC, CMS suites, etc, are generally overblown and make simple problems a lot more complicated than they need to be. In my own work with legacy databases, I have focused on migrating data to a moderns RDBMS (MySQL) from legacy systems and building an intuitive web interface. In my work I've developed a framework for developing web interfaces for a custom relational schema: the FiForms Framework (http://www.fiforms.org). Unlike other PHP frameworks, it uses XML user interface definitions, simplifying development and maintenance.
Daniel McFeeters
http://www.fiforms.org
The problems you mention were the first mental snag we ran into with Rails and other frameworks. How to make a framework work to extend an existing system has been very much an afterthought for not just Rails, but many other web and ORM frameworks written in Java, Python, and Perl. Every existing database has a good test case. Mine has a stored procedure named J1641535. That's been the ultimate test so far for me.
I call the article bull - actually, inaccurate to use a much better word. I've been working with an MVC framework I wrote myself, and it works wonders. It uses PHP and MySQL, but can be switched to other databases like MSSQL. I've developed all of our systems using this framework, and I've never needed to "upgrade" to CakePHP or rails or the like. The basis for my framework? phplib's db_mysql.inc and the Savant template engine.
Schemas are ONE approach to MVC, but not the only one.
So are these legacy databases not normalized, or...? IME all my "upgrade" projects that convert to e.g. Rails work fine because they were designed to a high normal form and generally fit well with CRUDdy frameworks. Once in a while there's a wacky relation table but usually it's pretty easy.