Page 1 of 2

MVC model

Posted: Fri Feb 29, 2008 2:28 pm
by Scrumpy.Gums
Hi,
Quite a basic question about MVC (I hope) using ZF...
Where should the execution of DB queries go? In the model or the controller?

At the moment, I'm using the Zend_Db_Table_Abstract as follows in the model (taken from the documentation here):

Code: Select all

class Bugs extends Zend_Db_Table_Abstract
{
    protected $_name = 'bugs';
}
and then calling and using that from a controller. Is this the right thing to do?

Problem is, I keep reading that this kind of thing should go in the model and the controller should only be concerned with user interaction.

thanks in advance.

P.S not sure if this should go in theory and design :?

Re: MVC model

Posted: Fri Feb 29, 2008 3:37 pm
by hawkenterprises
I think a better question to ask is why are you using MVC if you don't fully understand it. I'm not trying to be harsh I just find that there are waaaay too many people thinking that MVC is going to be the end of solution to there problems when most of the time it's the root of all that is evil.


Now that is out of the way, you should put your controlling statements in the controller. So to answer your question about the queries you will need to figure out what queries qualify, I would think INSERT, UPDATE, ALTER, DELETE all qualify for controller, where as SELECT, DESCRIBE etc perhaps will be pre generated in the Views.

Rasmus has a good rant about MVC
http://toys.lerdorf.com/archives/38-The ... ework.html

Re: MVC model

Posted: Fri Feb 29, 2008 5:26 pm
by Scrumpy.Gums
I just want to learn about MVC :oops: Learning about it can't hurt, surely?

Anyway...it's a non-simple query which selects and formats some dates and does a join. I'll look into pre-generating in the views

Thanks. :)

Re: MVC model

Posted: Fri Feb 29, 2008 6:19 pm
by alex.barylski
hawkenterprises wrote:I think a better question to ask is why are you using MVC if you don't fully understand it. I'm not trying to be harsh I just find that there are waaaay too many people thinking that MVC is going to be the end of solution to there problems when most of the time it's the root of all that is evil.
Nonsense. We all start somewhere. Besides...software design and architecture are moving targets -- they are constantly improving and adapting to their environments.

They are design 'patterns' after all...not design 'solutions' ;)

To answer the OP:

Execution of DB queries can go in one of two places in my experience:

1) Data Access Layer - Table Data Gateway (provides a low-level API to manipulate data store)
2) Model

I have used a data access layer in the past, so that my data stores may change easily. If the DAL provides an API such like:

Code: Select all

createMember($fname, $lname, $age);
The implementation can be anything and the data store can change as well (RDBMS, XML, CSV, Web Services, etc).

The model the manipulates the DAL (TDG) and provides the business logic, such as checking for duplicates, checking format, etc.

Note: DAL is somewhat Mircosoft -centric and not common around PHP or Java communities, but it forms the basis (beginnings) of my own understanding of MVC and software architecture and old habits die hard -- plus it's easier to pronounce than TDG. :P

Table Data Gateway is Martin Fowler's description of a solution which solves a very similar problem. Although he seems to feel it's simply a API for SQL code, the DAL can provide a wrapper API around any data store.

p.s-As for Rasmus and MVC...
I don't have much of a problem with MVC itself. It's the framework baggage that usually comes along with it that I avoid
It's only baggage if it's not doing anything. A well crafted MVC framework/application should never exceed more than 5% waste in the executing context in terms of SLOC, resources, clock cycles, etc...

I have dealt with this issues zelously in my own framework/application(s) and I can say in confidence I seldomly go above 2%. That is, if request requires 30 files at 4500 lines. There is maybe a single function, about 90-100 lines of code which is never actually executed, but just goes along for the ride.

Cheers :)

Re: MVC model

Posted: Fri Feb 29, 2008 7:13 pm
by Christopher
Scrumpy.Gums wrote:Where should the execution of DB queries go? In the model or the controller?
Definitely in the Model if you can.
Scrumpy.Gums wrote:and then calling and using that from a controller. Is this the right thing to do?

Problem is, I keep reading that this kind of thing should go in the model and the controller should only be concerned with user interaction.
The View is the thing that actually uses the Model, but as the Controller's job is figuring out what to do it may access the Model, or just pass it to the View.
hawkenterprises wrote:So to answer your question about the queries you will need to figure out what queries qualify, I would think INSERT, UPDATE, ALTER, DELETE all qualify for controller, where as SELECT, DESCRIBE etc perhaps will be pre generated in the Views.
I think you are mistaking types of domain operations from the layer separation between the domain and the presentation. I honestly have never heard of putting readers one place and writers another. That's wacky.
hawkenterprises wrote:Rasmus has a good rant about MVC
http://toys.lerdorf.com/archives/38-The ... ework.html
Actually, yours was a rant -- Rasmus' (2 year old) article if very supportive of MVC. He shows a nice, lightweight implementation that still supports clean separations. And it is the separations that the MVC pattern is all about.

Re: MVC model

Posted: Sat Mar 01, 2008 1:19 pm
by Scrumpy.Gums
Hockey wrote: The model the manipulates the DAL (TDG) and provides the business logic, such as checking for duplicates, checking format, etc.
I think this is where I was getting confused. Thanks for the clarification.
arborint wrote: The View is the thing that actually uses the Model, but as the Controller's job is figuring out what to do it may access the Model, or just pass it to the View.
So, every query must go through the controller, which then decides if it needs to change the model or the view. Is that right?

My problem now, is that I'm creating a DB object in my bootstrap file as follows: (After following Akra's Zend tutorial).

Code: Select all

$db = Zend_Db::factory($config->db->adapter, $config->db->config->toArray());
Zend_Db_Table::setDefaultAdapter($db);
How do I pass this object to the model? In fact, should I be passing this object to the model? I didn't need to worry about this before when I used Zend_Db_Table as everything was done automatically.

Hope that makes sense. :P

Many thanks again for the responses. :)

Re: MVC model

Posted: Sat Mar 01, 2008 2:25 pm
by Scrumpy.Gums
For the moment I've got rid of...

Code: Select all

Zend_Db_Table::setDefaultAdapter($db);
and put the DB object into the registry. Is there a better way to do this? It seems quite elegant doing it this way to me :|

Re: MVC model

Posted: Sat Mar 01, 2008 2:55 pm
by Christopher
I think putting it in the registry is best because the you control access explicitly rather than using globals (disguised or otherwise).

Re: MVC model

Posted: Sun Mar 02, 2008 6:55 pm
by hawkenterprises
Alright here is my beef with MVC. MVC, and other frameworks etc are a means of RAD, rapid application development. They are meant to be used for drafting out implementation ideas some where along the lines these frameworks such as cake and others have come along and new developers grab them thinking they are going to build these megalithic applications and be able to scale and move with demand. Using them as a final software platform is a bad idea. All it is, is another means to bloat and slow your code.

Re: MVC model

Posted: Sun Mar 02, 2008 7:06 pm
by alex.barylski
I have to disagree -- especially in the context of PHP.

I don't think you actually mean MVC is bad -- but rather the specific implementations of some frameworks. CakePHP is slower than other frameworks -- thats just a poor implementation of MVC.

Zend would likely do a little better -- but I personally found their implementations bloated with un-nessecary abstraction -- which is what you get when you try and solve everyones problems with a single tool.

A well crafted MVC powered application will typically run more efficiently than an adhoc design -- atleast in my experience they do.

Re: MVC model

Posted: Sun Mar 02, 2008 7:11 pm
by hawkenterprises
I would agree on that point, but I also haven't seen a MVC model that works. Your right, the "theory" behind everyone of these models is fantastic. Its the implementations that I've seen fall short.

Regardless I don't think learning a application design model is a way to go for a new developer. Standard procedural programming I think is still the best way to learn, from there then decide if you want to get OOPY or down with the frameworks.

Re: MVC model

Posted: Sun Mar 02, 2008 7:37 pm
by Christopher
I think you are conflating the MVC pattern with frameworks that may implement the MVC pattern and even with frameworks in general. The MVC pattern is very simple on its face, but very sophisticated in its meaning. I think the only disagreement a modern programmer would have with MVC would be how explicit to be about the VC separation and where to draw the line. As a practical matter, no one ever said that you have to follow any pattern exactly or throughout your entire application. Certainly the attitude that people have toward MVC implies it is all or nothing at all -- which no other pattern seem to suffer from.

However, I get the impression from people who don't like frameworks in general that their main problem is that the don't think that others code could ever match up to theirs in performance or quality.

Re: MVC model

Posted: Sun Mar 02, 2008 7:54 pm
by hawkenterprises
I really don't see a problem in being arrogant if you can back it up. I just have a problem with people talking that don't have any merit or idea what they are talking about. If you are still working 40-60 hour weeks scrounging over table scraps in the IT field then don't talk to me about how good frameworks have been to you.

Re: MVC model

Posted: Sun Mar 02, 2008 7:55 pm
by Christopher
I agree.

Re: MVC model

Posted: Sun Mar 02, 2008 11:00 pm
by RobertGonzalez
To kind of steer this thread back in the original direction, DB interfacing goes into the model. The model methods return datasets/objects that are called from the controllers (based on the controllers assessment of the current request) and passed to the view for presentation.

As for MVC, it is an excellent design pattern for those that know what it is and how it is used. And it is just that: a design pattern. It is not more to be squawked at than a strategy pattern, a factory pattern or a singleton pattern. Patterns are just a potential code style to achieve a particular object oriented objective.

Frameworks have, as the current batch of frameworks makes painfully clear, tried to use the MVC moniker as some sort of marketing platform. Personally, if a framework is cleanly coded, secure, fast and easy to implement it has my vote. If it is MVC based all the better. This is one of the reasons I love the Solar framework so much. And why I attempt to copy its layout so much. I think it does it right.

But that is just my rant as it relates to MVC in terms of frameworks. To the original poster, the model is essentially where the data interaction goes. The controllers fetch information from it to pass to the view for presentation. Generally, anyway.