A few questions about model objects in a MVC

1. Yes, this wastes memory. However, consider this: typical virtual server for a small web site has a few hundred megabytes of RAM allocated to it; for a larger site that might be upgraded to a handful of gigabytes. A typical model object might use up a few kilobytes and have a lifespan of less than a tenth of a second. Now work out how many requests per.second you’ll need to be handling before it makes a noticeable difference.

2. No. The usual practice is to entirely separate your model from database access. You have a Data Access Layer that fetches and stores model objects, and the model objects know nothing about how this is done.

3. Database access in the controller is better than in the model, but is still along way from ideal – really, you should be able to run unit tests on your controller, and if it talks directly to the database you’ll find that very hard to achieve. You should have a data access layer that is separate from either and which is passed to your controller through dependency injection – this way, you can give the controller a fake version (a test stub, sometimes called a mock, although really that name means something subtly different) to provide data for test purposes.

4. I’ll have to defer to somebody with more understanding of php internals than I do to answer this. My gut instinct is no, but sometimes a language can surprise you (and php has a history of surprising me).

5. Of all the performance implications of the things you’ve talked about, you’ve probably missed the most important – if your model is too course grained, such that your queries to the database return large quantities of unwanted data, this can become an issue. It is important to avoid making queries for large data items (especially blobs, like images or large quantities of text) when they won’t be needed. But it is also important to avoid making too many small queries, too. But before attempting to optimize, implement the simplest way and check to see if it’s good enough. It usually is.

1.When I only need a few variables set, isn’t it memory consuming to create an entire object? E.g. an entire site_object just to pass on site_id’s and site_names?

Yes, because for every object you create from the model, that consumes memory, and is not garbage collected into the CLR(C#/.NET) does so. Though if you are reusing that model within the application this likely outweighs the loss of memory from creating an entire new object (When using classes to create objects.). Also, good practice would say that to work with a model, the model is created for the purpose of be instantiated and used to query, insert, or do some other type of database manipulation.

2.Is it considered to be good practice to put all the database queries inside my model object or is it better to design a second model object for it?

Typically, you want to query the data in the controller, not the model, though not always. So design every model with an object that will be queried with the members in the model(object per business entity) in mind, using scripts.

Most will perform some sort of communication with the database
although some may not. Data is passed into and out of these objects as
standard PHP arrays. In this way an object can deal with any number of
database occurrences both as input or output. ◦It calls the relevant
view object to create output in either HTML, PDF or CSV.

3.If the question above is answered false, is putting the queries in the controller a good alternative?

Yes, if you put the component scripts in the controller, you allow for “separation of concern” and make the application more scalable and easier to maintain. You can use the HTTP GET method to make a call to database within the controller.

> •the model manages the behavior and data of the application domain,

4.If I have created multiple instances of model objects, and I store my query functions in the same model, do all these functions get loaded into memory multiple times?

No, because the query functions will load with the model, however this is not consider good practice, queries should not be in the model.

Model Component

This ensures
that all the common code is defined in one place but can be shared by
many objects.

5.Isn’t the question above bad for performance?

Yes, because likely the objects are being created and queried each time the model object is instantiated. Though consider that if you only used the object once per the purpose it is made for this will shrink that amount of objects you’ll most likely have to create.

Hope that helps!

More information at: http://www.tonymarston.net/php-mysql/model-view-controller.html#model