I am using CodeIgniter and doctrine for my project. When I enabled CodeIgniter profiling I got know My one request is taking 18MB of memory. I created test project with simple CI and Doctrine libraries. On test project CRUD operation takes 6 to 7 MB memory per request. After digging into to application I got to know included models are taking too much memory.
Earlier I loaded model into constructor method. But it consumes too much memory.
I decided to load models into every method which are required to particular method.
Is that good approach?
Please give me suggestions.
No you should not load model in every method. instead try load the model in contructor of each controller file. Hope you understand my answer.
Definitely, we should load models conditionally.
1) You should write certain conditions in the construction function for loading models.
2) Also, only required/dependent models should be included in any controller.
3) Including model in every method load the page faster. But, its not the best practice.
4) Rather you should dig into your model codes and find out why do its taking this much amount of time to load.
Your approach is right.
Use autoload.php to load models its makes to fully utilize the frameworks benefits
Related
I'm learning Laravel and I'm watching many tutorials, but I dont really get it, what's the difference between the controller and model, because you can put in both a function.
Controllers in Laravel are used to determine how to handle http requests.
When you have anything to do with the DB, its better to place those function in the model, and call them from the controller.
In clear terms:
Model performs all operations on data from DB.
Controller call necessary model methods and ready the data.
View take care of displaying the data.
I hope this is clear enough.
You will be familiar with all of this soon.
model methods is for relationships mainly , or to make some thing for every object of this model (database table) every column in db is an object and every table is a model.
but in controller you set your app functionality that you want , and its an intermediator between model and view .
i hop this makes you good in this point.
good luck
You can write functions anywhere, you are perfectly right.
But is not an efficient way to do things.
The answers for those questions can be easily find out. Search about MVC pattern. In few words, remember brief:
MODEL => working with relational databases / storing the data
CONTROLLER => working with the logic(taking inputs, calculus etc) / general functionalities
Combining them is more efficient than working with those together, that is the reason why using a pattern is more great than writing code in a old style mode reinventing the wheel again.
I'm currently using Symfony2 and and I'm trying to divide my code into different controller (like an Ajax Controller, a User Controller etc...) but I don't really know when I should use a create a new One.
For example my DefaultController is starting to be quite big (~800 lines) and I was wondering if having a too long controller could impact the website's performance? (Longer loading time...)
And, if it does, when should I split the controller into smaller ones ?
I would say that you should group your actions by which operate on the same data (entities) or operate within a well defined responsibility. E.g. UserController for users, PostController for blog posts, etc. This means that if you want to create an action which role is different than the rest of the actions, put it in a separate controller.
Symfony is caching almost everything so I don't think that huge controllers would cause an impact to the perfomance but if you have a thousands lines long controller, I'm not sure that it does only one thing.
The controller's size can be a warning sign too for the misplaced queries and business logic. You should separate QueryBuilder calls into Repository classes and other logic to services and event handlers. You can save more lines by using annotations instead of PHP code.
I think it's a good idea to start with a controller for each relevant model, with a CRUD structure.
Of course it depends on your needs, but if you have a model "Post", you probably will need a PostController with CRUD routes and methods, like : index (/posts), new, update, create, delete...
Depending what you need you can delete or add some method relative to a
Post from this base structure.
Try to detect what is realy relative to a specific model in your defaultController and create a controller for it.
Good luck.
What #riska and #Yoann said all holds true.
In addition, I prefer not to create separate controller if I'm sure that it hold only that one method. In that case, I just put it into DefaultController.
From my experience, controllers are the part of UI layer. If you care a lot about keeping your controllers small, let me give you the best scenario you can make what a controller must do:
1.Call the appropriate service
2.Return the response
That is 2 lines of code for each controller action, or you can even make it in one line.
Like person above said, controllers are usually separated by what type of entities / services they operate on. If you for example have an entity - lets say User, the following actions are most likely to be in there: createAction, editAction, removeAction, registerAction, activateAction, loginAction, logoutAction and so on...
It does not have any impact on performance if your controllers are thin or fat. The code will be executed in the similar flow, and all classes are being cached in the production environment.
I'm developing an application in Cake that heavily interacts with the filesystem. The basic idea is to monitor and index a folder and it's subfolders and files and save meta data for each file in the database. It's working fine so far, but now I got kind of a problem in understanding the MVC mechanics.
I got this heavy FilesController with a lot of functions checking if a file is up-to-date or if it has moved, updating the database entries and so on... Now I want to call some of this actions from a shell/cronjob and I want to call them in the browser too.
I've heard a lot of people complaining about importing controllers in shells and I think I got the idea why this is a bad idea. But now I want to use the same code that interacts with the FileModel directly in a shell and in a controller. Where to put it? What is best practice in this situation? In a component, loading the model? In the controller, importing it in the shell?
Thanks for your help in advance <3
I got this heavy FilesController with a lot of functions checking if a
file is up-to-date or if it has moved,
Wrong place, heavy controllers are definitely wrong. You want fat models, skinny controllers. If there is logic that extracts meta data I probably would put it into app/Utility/FileMetaData or app/Lib/FileMetaData.php and make it a new class. Depending on what it does you might extend the core class Folder or File.
The processing logic for the meta data and reading the folder should go into a model. The model can be used from the shell like in a controller by using the $uses property with an array of models.
To instanitate that class I would use a helper method (I don't mean a view helper by this!) in the model like getMetaDataReader() that returns the instance. The reason for this is to be able to mock the result of that method call in an unit test. Also, if you ever change the class or constructor args you'll have to change only a single place.
Controllers are clearly wrong in shells. There is no request to deal with. Sure technically you can do the stunt and instantiate them there but it is just wrong and doesn't make any sense. If you think you have to or "need" to do so, something is wrong with your application architecture.
You might want to take a look at my FileStorage plugin as well. You can implement an event listener there and when storing a file have the listener automatically process the the meta data.
I have a very big AppController. Nearly 75 functions and 130 kilobytes. It seems like that slows my system. Therefore I need to put those functions inside another file, and include that file, when some other controller needs it.
Options are creating a new controller or a new component. I'm trying to make a selection. What would be the advantages or disadvantages?
My points are:
I don't plan to use these functions inside another project. These functions will only be used by this project.
Inside my AppController I use these files, models, components. So they should be accessible by new structure.
App::import('Vendor', 'MyFancyVendor', array('file' => 'MyFancyVendor.php'));
App::uses('CakeEmail', 'Network/Email');
public $uses = array('Mytable1', 'Mytable2', 'Mytable3', 'Mytable4');
public $components = array('Session');
public $helpers = array('Session','Html');
Edit: Although using a huge new controller/component seems like the same with the old structure, difference is: Say it MyController12 and MyController13 doesn't use the methods of these huge functions inside AppController. But because of MyController12 is created from AppController it loads models, components and other things that it doesn't need. If I put of these logic out of my AppController, MyController12 will not load all that logic.
Follow this pattern:
Gather all related functionality in libraries.
Move all the data logic in the models.
Move all the view logic int the views (remember views are not templates)
For whatever else left, create some helpers
This will make your controller thinner. Creating other controllers should be your last chance, considering that you really don't want to use these kind of functionality in any other projects or part of the website.
The number of functions and the size of the files has absolutely no impact on the time code takes to execute.
Example: this has over 50 plugins loaded, 100ish controllers, 84k lines of code and the pages load reasonably fast.
You need to look at the queries being run. I suspect you are using queries with recursive set to 1 or 2. You should use containable at the very least.
Also look at the explain for your selects. If you are using mysql check that, or what ever is similar for your engine.
You can also install debug kit which displays a lot about what is taking time and can be sped up.
From what i can read, maybe its best that you think about dividing your AppController into multiple different files. Without seeing what your AppController it seems like it is assuming a lot of different roles.
Maybe its better to use different controllers for Mytable1, MyTable2, Mytable3, Mytable4, and use Components to share any information between them.
To answer your question, it is to use BOTH, and also to use Libs, and Helpers. Controllers where necessary, and Components where necessary. There's no point in changing your huge AppController into a huge Component. Split your files where you see something in common. Such as a ImageController, or Postcontroller, both however will use the Session Component.
Edit: What about changing the $helpers, $components, and $uses, from the AppController to the Individual controllers? Use relationships so that CakePHP can find the models. And make sure controllers aren't loading extra models / classes, as i doubt a big controller would cause sluggishness ( unless its your code )
I have been using a controller method post directly to perform some db and social network operations but im finding a few points of failure between it and the hardware — so I came up with the idea of storing all the request in a db table to be used as a queuing system instead so I can process them in my own time rather than real time
The thing I'm struggling with now is handling my requests . I know this isn't very MVC — but its quick fix.
How do I call another controller's method from within my process queue method? I have tried including the file and instantiating it — then passing it the variables i would have done from the web.
function process(){
$result = $this->mque->get_all();
include('post.php');
$get = new post();
foreach($result->result_array() as $item){
$get->index($item['rfid'],$item['station_id'],$item['item']);
}
}
but i get an error- when i call the normal index method- it runs fine but i get an undefined method error when call it through the instantiated class method- (this is my problem)
Message: Undefined property: post::$db
The why
I am setting the process queue method to run based on a cron job running at a set interval of time.
Originally everything ran to index method of post — but since post::index() can take 10-15 seconds to run and the reader is not multi threaded — someone could use the reader within 7 seconds and the script wouldn't have run completely.
Is there a better way of doing this rather than using my current process method?
update
there is two ways to do this- either use php to fopen/get from the web
or do it sprogramming using $class->method()- i would prefer to do this the first method but dont really see any option with the error i mentioned before
That's easy: you don't have one controller call another. As a rule, if you need something to exist in two different places, you have two options:
Have them both subclass the same object
pro: That way the method is already there
con: You can only subclass one thing, and you have to build your own class loading system (NOT GOOD)
Have a library (or model) which they both share
pro: The method can then be tested better (it is (or it was at one point) easier to unit test models than it is to test controllers), the code can be shared without a custom class-loading syntax.
con: This may involve a little refactoring (but it should be as easy as moving the code from the controller's method to a library's method and then simply calling the library in the public controller method).
Either one of those would solve your particular problem. Personally, because of how CI loads controllers, my preference is to create libraries.
CodeIgniter: Load controller within controller
Is this something that could help you out quickly? Check the bottom reply.