I have the same question about my current project.
Project type: Something like shopping cart SDK.
Models: 30+ (with extensions)
Extensions: 15+
Tables: 47
Relations: every model have 3+ relations
The most performance demanding part processing: 300ms
On start, I have 10 models with relations, that's why I choose Laravel as Framework, and I do not think about growing.
Now, I have 40 models with a lot of extensions and Laravel work fine.
My project is growing fast.
Now It's a big SDK with a lot of tables, relations, and extensions.
I need advice from experienced developers.
Do I need to switch Laravel to Symfony, to reduce future problems with
performance?
I would be glad if you can advise me on this.
P.S.: I understand complexity with migration from Laravel to Symfony,
Performance-wise there is no big difference between frameworks. If you are coding right - they are all just the same.
But the problem is in this part "if you are coding right".
You must always think about design, about responsibilities, about service layers, and to be consistent with your approaches.
And for this Symfony is much better. It's just a more convenient framework to go with SOLID. And it makes you think in a right direction.
TL;DR: There is no any reason to change Laravel to Symfony.
Symfony has no layer for models handling. It's ORM library's responsibilities (usually we can use Doctrine in Symfony -- but it's possible to use another ORM libraries for that -- even Eloquent). And also it's not a big deal to use Doctrine for Laravel.
But obviously changing framework won't decrease the number of models -- so 40 models in Laravel still will be 40 models in Symfony. Because of this, there is no any advantage for decreasing of complexity.
Also there is no explicit dependency between framework and performance (generally, the DB is bottle neck).
Despite of opinion that Symfony automatically (and magically) increases programming skills -- it's wrong. So if someone able follow to SOLID principles, able to reduce cyclomatic complexity of the code, able to provide strong cohesion and loose coopling for the classes -- it doesn't sense what exact framework could be used. Actually Symfony doesn't force to use the best practices.
Therefore Symfony provides a lot of excellent components. But most of them can be used easily (and actually used) in Laravel.
Laravel is good for medium websites. For big app i would always use symfony or zend.
Related
Maintaining database views in mysql is sometimes cumbersome. When you change a referred table you have to alter the table and there is no clean way to do that in migrations (DB::unprepared()). I guess using query scopes in models is more maintainable. Isn't it? Does it has negative effect on the performance.
I don't know how big your project is and I don't have many elements to judge this situation perfectly.
However, working with views means depending on the underlying database system. Obviously it has its pros and cons, but I would prefer to decouple my software components.
What if you change, in the future, switching from MySQL to MongoDB?
Maybe, you could use a cache system, like Redis or Memcached (and Laravel already has a ready-to-use service for it).
As I told you before, I am making this suggestion basically because I think about the software scalability and components decoupling.
Here you can learn about the basic use of the Cache Service: http://laravel.com/docs/5.1/cache
Also, if you have some confidence with design patterns, you can implement a really elegant solution using some stacked repositories alongside the decorator pattern.
You can find some interesting articles about the topic here:
http://culttt.com/2014/02/03/laravel-4-cache-service/
http://culttt.com/2014/04/23/decorator-pattern/
Yes, they're about Laravel 4 but the concept can be easily adopted in a Laravel 5.* project.
Hope it was useful!
EDIT: as I told in the following comments, if you don't want to start with something like Redis or Memcached, you can always use the filesystem-based Cache.
I have an application with a custom framework, it's very old 7 years ago using old techniques and design patterns.
We are facing problems.
We are using DAO Layer to access the Data objects and by the business need things getting so complicated and DAO is no longer being able to serve the business needs, we are thinking to use Symmfony2 and Doctrine2.
But the problem is :
THE APPLICATION IS REALLY BIG.
More than 7 years development and adding features.
About 11.500 Files and File Avg 1500 Line.
I know it's not an easy job, but i'm sure there's a way to migrate or at least use Doctrine for now without hurting the legacy code.
Please Advice.
Thank you.
There is no easy answer to your problems. Dealing with legacy code is always hard.
You should wrap Symfony around your application if possible. Implement a Command or Facade pattern around your app, and make the Symfony controllers call those classes.
Try to separate your DAO access layers by using the repository pattern. Not the Doctrine repositories, but custom ones, specific to your app. When you have repositories separated with interfaces from your app, you can do doctrine implementations of them one by one.
It would be worth thinking about decoupling your application from Symfony so you don't face these kind of problems in the future.
Also, if you can, try to write as many tests as possible, this will make it much easier for you to refactor in the future.
I wrote a blog post with some tips on how to separate from the framework here. The same pattern applies for repositories.
We have pretty big application which has about 8 modules (big modules) written using Zend framework 1 and it has been developed for more than 3 years by couple of developers. Also it has a high traffic everyday. We use Amozon s3, Sphinx, Memcache, and some other third party services as well.
Is it a good idea to migrate it to Zend framework 2 ? Because as we went through the doc briefly, it seems Zend framework 2 has been re-written completely. Therefore we think we won't be able to migrate the application easily rather than re-writing the application according to ZF 2.
Valuable ideas would be highly appreciated.
You are correct that ZF2 is a completely different animal. So different, in fact, that there's no one-size-fits-all migration plan/strategy.
However, I recently did a similar migration. It's a fairly complex line-of-business application originally written over approximately 18 months, with a bunch of varied functionality. The main drivers for the decision were the improvements in the module and event systems.
In our case, it turned into a major point release for the product, which ended up including a bunch of UI changes along with all the plumbing.
Assuming you liked ZF1, the good news is that ZF2 is much better framework (as a framework). The ModuleManager, EventManager, Di, and ServiceManager components (and the general MVC-related stuff) are really great, once you grok them. The bad news is that they're a complete departure from ZF1. So you're at the very least signing up to completely overhaul your dispatch and routing, you'll be saying goodbye to Zend_Registry (ServiceManager/ServiceLocator are a huge improvement).
The other bit of good news is that you can almost certainly keep all the old ZF1-type components around for as long as you need them. So if you're relying on Zend_Cache, Zend_Log, Zend_Mail, etc, a little bit of fiddling with autoloader configs should make that possible.
What I'm suggesting is that if you do take the plunge, consider just migrating to ZF2-as-a-framework first, and worry about ZF2-as-a-component-library later.
If you've stuck with the fat-model/skinny-controller paradigm, it's probably feasible to just replace the Controllers, Front-Controller, Zend_Application stuff in a fairly straight-forward way. Once you get that into production, you can then work on removing dependencies on ZF1 components as time permits. In my case, there wasn't much of that, as things were pretty well factored and wrapped (so, for example, moving from Zend_Cache to Zend\Cache was trivial)
Finally, you should know up-front that View-layer stuff (mostly the helper-related stuff) is different too. If you have a bunch of complicated view-related stuff (partials, custom view-helpers, etc) all over the place, you need to anticipate either rewriting them, or finding a way to use the old Zend_View stuff in ZF2 so you can migrate piecemeal. I didn't really deal with this because our interfaces were fairly simple and we took it as an opportunity to overhaul the UI.
Just my $0.02, but I hope it helps.
There is no quick and easy way to migrate because ZF2 is very different from ZF1.
Related: Step by step migration from Zend Framework 1 to 2
I'm currently building a web application using Zend framework 1.11.11 and Doctrine 2.2. I searched a lot for the best ways and hacks to optimize the frameworks used.
During my search for Zend framework optimization I stumbled upon this post:
Optimising the Zend Framework
What was interesting about it is that it mentioned few optimization techniques that emerged from the usage of the framework itself and wasn't covered in the manual itself such as:
disable viewRenderer and take care of view rendering yourself.
Now I'm looking for similar techniques that could be applied to Doctrine 2 other than the ones mentioned here in the manual.
Note
I know many will mention profiling the queries, caching and finding the bottle neck of the app, but that's not um looking for :) I am looking for practical enhancements discovered during Doctrine 2 usage.
Thanks ;)
Well, optimizing and hacking Doctrine 2 will not be an easy task. I can only advise you to follow the official "best practice":
Use Query Cache
Use Metadata Cache
Pre-generate proxies
Avoid listeners (or merge them by event type (flush, update), it will avoid the lookup time and the loop for subscribed events)
Use lazy-loading whenever it is possible
Make sure your relationships or inheritance are not messed up
(Note that I didn't mentioned Result cache which should not be a way to optimize an application)
From my use, the most important part I had to optimize was not Doctrine itself (while there are optimizations to do to the core) but the generated Query, as always, I EXPLAINed the queries and optimized indexes.
Doctrine 2 can be high memory consuming so loading a lot of entities at once may slow down your application, you may find it useful to known about clear(), detach(), iterate() methods.
Despite the fact Doctrine 2 can sometimes be slow, I mostly noticed that I was able to optimize application somewhere else, within the Zend Framework or PHP themselves.
Let's say, Doctrine 2 takes 100ms where Zend Framework takes 300ms for a total of 450ms (I/O stuffs, PHP internal functions, etc..)
If you can divide easily by two the time taken by Zend Framework, optimizing Doctrine 2 to gain like 10% will not increase notably the speed of your application. Think about it twice.
Here are a few tips:
Create your own view instead of using View Helpers (avoid the helper lookup)
Cache your Zend_Config object (really heavy load)
Avoid Regex routes whenever possible (ZF routes are a big bottleneck)
Use a ClassMap autoloader instead of the native Zend_Loader_Autoloader
There are tons of optimization to do, some have a real impact while others don't.
Make sure to find them by profiling your application, an easy and cross-platform is to use webgrind.
I've recently come on board with a PHP application. There has not been much design put into the app - there is a front controller, however, view, model and controller code is usually mixed together.
I would like to slowly start refactoring the code beginning with moving all the SQL queries into appropriate models. Having looked at a few frameworks, it seems that most frameworks are setup with the assumption that an app will be developed from scratch using that framework.
Is there a good framework that I can just kind of plug-in so that I can use the model libraries and then perhaps later on, integrate more of the app into the framework? Would Doctrine be a good tool for something like this? Or should I just setup my own models without relying on third-party libraries?
If you have an existing php application, then there is no point to migrate it to some framework. Frameworks help you to develop project faster - you already have one. At this point adding framework on top of what you have will only make your application more complex and, most likely, slower.
Instead of trying to find some magical framework, you should invest in refactoring (apply some OOP principles, like SOLID) and documenting the existing code. Maybe start incrementally add some unit-tests.
P.S. Doctrine is an ORM ( 1.x implements activerectord , 2.x - something like a datamapper ). ORMs are for people who are extremely lazy, misguided or do not understand SQL. By moving your existing SQL queries to ORMs code you will make it all only slower. Additionally, you will encounter problems when migrating complicated queries. Just dont do it.
I've just started rewriting a site in Kohana, and I'm quite happy with it. It seems flexible and powerful. It's very similar to CodeIgniter, but a little more modern (more of the latest PHP features are used).
If you want only MVC (not HMVC or more difficult) frameworks for simple adoptation with existing application you should touch CodeIgniter. ActiveRecords is very easy for refactoring from existing sql-queries. You even can use default or hand made functions or classes for building queries in its models.
But default, Codeigniter isn't enough flexible for difficult or multi-namespacing applications.
Im migrating a site using Zend and Doctrine2.
The site wasn't OOP in any sense but it was divided between logic view and dal. The migration is still in process (new features are coded with framework, existing feature gets migrated only when big changes are needed).
Both frameworks are non intrusive, and the most valuable thing you get for me is to standarize things.