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

PIDZB
  • 223
  • 1
  • 7
  • 1. No. The organizing value of the object always trumps the small amount of memory it uses. – Robert Harvey Jun 06 '16 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. – Robert Harvey Jun 06 '16 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. – Robert Harvey Jun 06 '16 at 20:20
  • @RobertHarvey Thanks, I really needed to hear that from someone! – PIDZB Jun 06 '16 at 20:28
  • ...at least with respect to the architecture. – Robert Harvey Jun 06 '16 at 20:50

2 Answers2

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.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
Jules
  • 17,614
  • 2
  • 33
  • 63
  • Thank you very much Jules! Finally some designations I can use Google on! Youve made it a lot clearer for me :D – PIDZB Jun 06 '16 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

  • 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. – Adam Zuckerman Jun 06 '16 at 20:26
  • Ahh, my mistake, please disregard my answers, until I research PHP. – Juan Davila Jun 06 '16 at 20:27
  • http://programmers.stackexchange.com/a/234117/78905 – Adam Zuckerman Jun 06 '16 at 20:27
  • 1
    Most of your answer is wrong, even for C#. – Robert Harvey Jun 06 '16 at 20:34
  • Please explain where it is wrong and provide research. – Juan Davila Jun 06 '16 at 20:51
  • For information regarding MVC with C# visit this link: http://www.asp.net/mvc – Juan Davila Jun 06 '16 at 20:52
  • 3
    Uh, no. Do your own research. – Robert Harvey Jun 06 '16 at 20:55
  • Okay, did already, just needed to verify what you say is valid. Thanks. – Juan Davila Jun 06 '16 at 20:56
  • Database logic should in no way ever be in the controller. The controller is for presentation logic and should be as far away as possible from data access. – Alternatex Jun 07 '16 at 06:16
  • @Alternatex If by presentation logic you mean how data is displayed, then even that statement is incorrect. Controllers should only be used to retrieve data and pass it to views, controllers should be very thin, their main responsibility is routing, which they should do based on the operation results of underlying layers (the Model in MVC). – Andy Jun 07 '16 at 07:10
  • @DavidPacker Maybe you misunderstood me. [The controller does have presentation responsibility.](http://stackoverflow.com/questions/12429729/controller-belongs-to-the-presentation-layer) It decides the view and data to be shown. It's also the ground where the view-model mapping happens (most of the time). Although you're correct that their main responsibility is routing and that they should be thin with very little logic, that doesn't take away from the fact that controllers are inherently coupled to the views they return. – Alternatex Jun 07 '16 at 07:40
  • I know you put a link to Tony's article at the end but you might want to go back in to you answer and make it clear that most of it was copied/pasted directly from his article. There are various formatting options for this. – Cerad Jun 07 '16 at 12:42
  • I do know that model delegates how the view is going to be displayed in design terms, though does not necessary control the logic. I think I mentioned that in the answer when considering PHP. Sorry, my strong suite is not PHP, so I just tried to post the MVC concepts via Tom's website. – Juan Davila Jun 07 '16 at 15:45
  • @Cerad Thanks, I added formatting for clarity. My answer may not be accurate considering code, can be case by case. Though I posted research via Tom's website for PHP, if there is any confusion. – Juan Davila Jun 07 '16 at 15:51
  • @JuanDavila - My original point is that you are basically guilty of plagiarism. You have copied/pasted a bunch of someone else's stuff without attribution. That is considered to be a bad thing. The stuff you added is kind of silly and mostly off topic but that's okay. – Cerad Jun 07 '16 at 19:33
  • @Cerad I showed my source, that is not palagrism if am referencing my sources, I am not taking credit for his work... Please read and look at the bottom of the answer. – Juan Davila Jun 08 '16 at 17:06
  • In case, I get accused of something else again, this describes plagiarism: http://www.plagiarism.org/plagiarism-101/what-is-plagiarism – Juan Davila Jun 08 '16 at 17:11
  • Also, I inherently, taking most of these comments as a joke, as nothing so far has been, accurate to what am seeing people say, please back your findings. Am thinking this is confusing the readers. – Juan Davila Jun 08 '16 at 17:12
  • I will, however, remove some of the wording in the quotes, as that is consider plagiarism according to the website I found. Though, this probably moot at this point since, I know most of what is written in these quotes. – Juan Davila Jun 08 '16 at 17:16
  • 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 08 '16 at 17:35
  • I am not a PHP programmer, the website I posted eariler I found seems to have more information about MVC with PHP, though am just trying to use some general MVC concepts. I would down vote my answer if I could. What am trying to describe is the model is essentially a class that has members that can be used in a query. This link is for ASP.NET, though the design concept or pattern should flow through everything else (other languages), my sources: http://www.w3schools.com/aspnet/mvc_models.asp – Juan Davila Jun 08 '16 at 17:45
  • Oh, here is another link as well: http://stackoverflow.com/questions/5093880/what-is-the-usage-of-model-in-mvc-is-it-actually-useful – Juan Davila Jun 08 '16 at 17:51