Re: mod_perl and MVC

I'm the author of that article. Glad to hear it got you thinking about MVC and mod_perl.

It sounds to me like you're getting confused between two different concepts. The proxy servers have nothing to do with MVC per se. They are there to help performance by handling requests for static files and by caching any pages that the app servers say can be cached (by looking at the Expires headers). They also handle sending out the result to the client, which keeps slow modem users from tying up a process on the app servers during download. The communication between the proxies and the app servers is HTTP, as you said.

The MVC stuff is all in the app servers. The model, controller, and view components are separate classes (well, technically the views are all Template Toolkit templates in this case), and they communicate to each other through standard method calls. None of the components is ever active on the proxy servers. Those are really just web serrvers with mod_proxy and mod_rewrite installed, and they don't run any Perl code.

I hope that clears it up for you. If you have more questions, ask away.

Comment on Re: mod_perl and MVC

Replies are listed 'Best First'.
Re: Re: mod_perl and MVC by krisraman (Novice) on Apr 15, 2002 at 03:13 UTC
Sir, Thanks a lot for the explanation.It really helped me to understand that the MVC is in the app.server side.You also mentioned that the business data objects like the product data is cached and if my understanding from the doc.is right,you mentioned that the caching mechanism in written in C (for performance in the app side).So the question is , are you using socket in the model layers to communicate it to the cache to fetch the data objects? If so, do we have any custom written message protocol to accomplish this. Too much of interest in your article is making me to ask these kind of foolish questions, so kindly bear with me.	[reply]
Re: Re: Re: mod_perl and MVC by perrin (Chancellor) on Apr 15, 2002 at 13:04 UTC
The caching of data objects was done using BerkeleyDB. We wrote a simple cache interface on top of it to keep track of an expiration time for each entry and only return unexpired items. These days, you could just use Cache::Cache for this. That module wasn't around when we started. The part in C was a daemon on each app server to broadcast shared data to all the other app servers. The only data we shared was the read-only product data which should be the same on any server.	[reply]