We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. MVC

MVC or Micro or Middle

The factory default MVC loads heaps of services. Micro loads nothing. I ended up using a mixture of micro and an MVC config with no factory defaults, using only what I specifically need. Has anyone compared the memory usage or performance for the factory default versus a cut down services list?

Many of my Web site pages do not need the Model code. I use the following DB handler to execute some SQL. The SQL is usually simple. 'select name in abc order by name'. There is no reason to load the model code for every page.

$db = Di::getDefault()->getDb()->getInternalHandler();

Given that most of the pages on the site will be information pages, a reduced MVC is worth the effort. I call it the Middle level. The most frequently used pages will be the ones that use the least services and benefit the most from Middle.

I can see potential database access performance improvements. I have not attempted to measure memory usage or CPU usage. Is there any research into replacing Model with a cut down version or plain PDO?

2


145.0k

Keep in mind that factory default creates services only when they are accessed.

There is actually Medium/Middle Application approach in phalcon - like Micro kernel + controllers as handlers.

You can always just access db service and call methods like fetchAll fetchOne etc, it's just wrapper over PDO but without models, you will just have arrays or stdobject as result.

Memory usage will be smaller, but not very much really. Mostly about amount of php files you have. Cpu usage can be bigger difference - micro doesn't have dispatcher - so it should be faster at this point.



79.0k
Accepted
answer
in reply to Wojciech Ślawski
edited Jun '17

There is actually Medium/Middle Application approach in phalcon - like Micro kernel + controllers as handlers.

That's my approach 99% of the time with Phalcon :) Works like a charm. Flexible, efficient and very performant.

@petermoo You've done a good job, and for sure you'll end up with a more performant system. Remember, DB is always the culprit on web apps.



9.7k

"but without models, you will just have arrays or stdobject as result" I am using ->fetchAll(\PDO::FETCH_CLASS, 'abc'); to use my own classes for some data and leaving the stdObject for others.



145.0k
edited Jun '17

Yea i guess you can use it like this too. Im using models mostly for updating/creating/saving/deleting etc. For displaying i use Phalcon\Mvc\Model\Resultset::toArray anyway which a voids a lot of model hydration overhead anyway.



79.0k
edited Jun '17

@petermoo : You can also set globally PDO fetch mode. This is my approach, extending Phalcon classes:

//Resolve static PDO adapter from current scope, bind parameters bag and execute query, fetch entire result set
                $result = static::$adapter->query($sql, $criteria['bind']);

                //we need to override default DB service behaviour to always return objects
                $result->setFetchMode(\Phalcon\Db::FETCH_OBJ);

                $result = $result->fetchAll();

                return count($result) ? $result : 0x00;

Or even better globally on the db service itself: 

$dbConfig['options'] = [
        \PDO::ATTR_DEFAULT_FETCH_MODE => \PDO::FETCH_OBJ, //force object as default or any other mode
        ];

I must say that I like very much this term - Middle :) Kudos for @petermoo



9.7k

I decided that taking controll of the database is the first part of the answer to efficiency. if you know databases, you can make queries sing.

Removing the view code is the second part of my efficiency improvement because it is not adding anything for most of my Web site pages. I might use view for some pages when i am presenting a long list as a paged list. I do not see any other use.

At this stage my forms are really simple. Perhaps a multipage form could use a view. I want to acvoid multipage forms because they are messy to use. I occasionally have to fill out one and none of them work. A better approach is a checklist with a single page form for each item. You can then fill out parts and return to the rest later. I might start a separate discussion on that.



9.7k

From a security perspective, the only public faceing file is index.php containing one line:

require dirname(DIR) . '/index.php';

The second index.php file contains only one line, require DIR . '/code/index.php';

The third index.php loads Config\Adapter\Ini, Di and Loader then loads index-micro.php or index-middle.php.

index-micro.php loads Micro and Response. Images are delivered direct through response. CSS and JS go through Volt to be customised. I will eventually add a Volt bypass for generated CSS and JS.

The response time is really fast for a page with a huge dynamically generated table containing images. :-)



79.0k

I don't get why you have 3 layer FrontPageConroller in place (i.e. your index.php x 3)?



9.7k

The first one includes then code from outside the public directory. One of my security decisions based on experience of people changing the Web server settings in a way where code becomes visible. I simply include the same file from one level lower. Easy to remember.

The second index.php simply includes the code from the directory containing the code. Again an easy to remember setup. I sometimes have selection code here when there are multiple applications in the same Web site.

The third index.php file is the one that switches between the micro and middle applications. Currently it is based purely on the file suffix. I am about to split this part into three. image files will bepassed through direct. Some files will be passed to Volt and cached for repeat use. Everything else will go to the middle size application.