0

I have a few questions about how to implement models and what the results are of those implementations:

  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?

  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?

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

  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?

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

Thank you in advance for your time :D

5
  • 1. No. The organizing value of the object always trumps the small amount of memory it uses. Jun 6, 2016 at 20:14
  • 5. Your database queries (and Internet latencies) will almost certainly take longer (by at least an order of magnitude) than any performance differences that occur due to architectural intricacies, unless you plan on creating some overblown architecture like ASP.NET or Java Server Faces. Jun 6, 2016 at 20:18
  • 1
    In short, you're probably worrying about the wrong thing. Focus instead on good architectural organization and structure, and stop worrying about performance. Jun 6, 2016 at 20:20
  • @RobertHarvey Thanks, I really needed to hear that from someone!
    – PIDZB
    Jun 6, 2016 at 20:28
  • ...at least with respect to the architecture. Jun 6, 2016 at 20:50

2 Answers 2

2
  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
  • Thank you very much Jules! Finally some designations I can use Google on! Youve made it a lot clearer for me :D
    – PIDZB
    Jun 6, 2016 at 21:18
-5

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

22
  • 1
    You are making an incorrect assumption that the OP is using C#. The tag below the question shows the question is related to PHP. Your answers for 2, 3, and 4 are backwards for PHP. Jun 6, 2016 at 20:26
  • Ahh, my mistake, please disregard my answers, until I research PHP. Jun 6, 2016 at 20:27
  • 1
    Most of your answer is wrong, even for C#. Jun 6, 2016 at 20:34
  • 3
    Uh, no. Do your own research. Jun 6, 2016 at 20:55
  • 1
    I have been programming in PHP for over a decade and I have no clue what you mean by 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., that itself is a reason why I don't think your answer is very good.
    – Andy
    Jun 8, 2016 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.