I would like to try Silex but i've some questions.
I know to use Symfony2 and i would like to know if Silex is very different of Symfony or it's the same thing (same operation, same code... ) ?
Moreover, Silex is recommanded for small PHP projects and Symfony for medium or big projects , it's true ?
A few things worth noting:
Silex is based on the Symfony2 components, just like the Symfony2 framework is. As such, it can be considered an alternative user interface to the components (the user being a web developer).
Since they use the same basis, migration between them should be relatively easy.
Just like Symfony2, Silex is mostly a controller framework. It provides you with some structure, but the model and view parts are handled by third-party libraries (such as Twig or Doctrine).
Since your business logic should not be in your controllers anyway, if you separate that code out and keep your controllers light, the limiting factor in terms of project size will only be the amount of routes you have.
That said, Silex will not give you the bundles that Symfony2 has.
Here are some interesting thoughts on when to use Silex (especially in the comments):
https://web.archive.org/web/20160131151109/http://www.testically.org/2011/10/11/is-there-a-specific-situation-when-to-use-a-php-micro-framework-like-silex/
Silex itself is pretty bare, which means that if you want more then just routing and tests you will need to add specific features (DB, Twig ...) in form of Services.
I recommend to take a look at some readymade Plates that provide you with this:
https://github.com/lyrixx/Silex-Kitchen-Edition
or
https://github.com/ivoba/superleansilexplate (thats mine :))
Another point is that Silex has a probably lighter footprint than Symfony2, so if you need a smaller & faster site, Silex is worth a consideration.
(UPDATE) Since Symfony 2.8 You can use symfony 2 as a microframework with a micro kernel controller. See short description here: symfony.com/blog/new-in-symfony-2-8-symfony-as-a-microframework. Now Symfony gives us more control over the structure and architecture. Good alternative to Silex if You prefer the Symfony 2 style.
Comparing Silex to Symfony before 2.8 release
Silex microframework is based on Symfony but it's not exactly the same thing. Using a full-stack framework such as Symfony for a small project is simply overkilling the project.
In a microframework, you have more flexibility to choose the tools you want to use. You can make more decisions about application architecture and logic.
In a full-stack framework with some extend you would have an architecture and a logic already predefined with restrictions and limitations to its configuration.
Silex was designed to build up the tool rather than get the set tools that you might not need. I would say that for small projects in Symfony you would have to remove features - were in Silex you would have to add them.
It is also not true that Silex isn't fit for larger projects. Silex can be used with success for larger projects but remember that you would have to build up your tools to fit your requirements (if you need to customize the architecture and logic - perhaps this is the right way to go). Other than that, I would consider using Symfony instead, because Symfony already has bunch of tools available out of the box.
Bear in mind that:
To conclude, Silex is good for smaller applications and for those, it can surely replace Symfony. Silex can also be used for larger projects (but for larger applications I would recommend to use full-stack framework instead, like Symfony).
Reference for slides at: http://www.slideshare.net/dustin.whittle/silex-from-micro-to-full-stack . If you feel like it, go ahead and read some more about the Silex framework.
I also recommend watching this intro comparing Silex to Symfony: https://www.youtube.com/watch?v=RDVtnsoOysE.
Again, a few Pro for using Silex coming from people who actually use it: https://www.youtube.com/watch?v=OJcdHGJFfLU
Silex is good for small projects, but it can be used for big projects as well. What I like the most of Silex is that I have complete control over my project structure but it's my responsibility if my project is well organized or not.
Also I recommend it over symfony if like me, you moved your application logic to the client side using a JS framework. For me it feels an overkill to use symfony only to serve a few json requests.
Silex is based on the independent Symfony2 components and isn't truly considered a full-stack web application framework like Symfony is. You should only use it for very small projects that only require a few files, or you'll outgrow it pretty quickly.
Silex is a great framework for small as well as big applications. Giving structure to the project is your responsibility in Silex. As the project becomes larger, you can nicely integrate symfony components into it although the documentation for the symfony provider is not so good especially for symfony security component.
Silex is great for prototyping projects. If you know you will be using most of the symfony components then go for symfony because you will end up with integrating almost all symfony components into silex.
In my case I needed speed right out of the box and silex provided me with the speed and although I am using most of the symfony components, it is a lot faster than symfony out of the box.
At the moment I write this, Silex is in maintenance mode and it's end of life occured in June 2018.
Which means you shouldn't use it anymore for new projects.
They recommend you to use Symfony 4 instead.
Silex was really good and fast (maybe faster than symfony 4 for simple requests/requirements), but SF4 may bring some new stack and benefits to our applications.
Update: However, in all of my attempts on migrating from Silex to Symfony 4, the simple services took 4x times more to respond no matter what I do. Silex seems to do a much better job for simple micro services.
Silex is a PHP microframework. It is use for the small project.The coding style of the symfony and the silex is almost similar to the symfony.But the symfony is use for the large projects
Related
I have a couple backends written as single-file Silex applications - basically the example from https://silex.symfony.com/ just with a couple more routes. No classes, no frills.
Is there any way to replicate this tiny low effort structure in Symfony 4 or do I really have to blow each backend up to the full Symfony structure in the Symfony way?
You should look at the Symfony 4 MicroKernelTrait. This is going to be very similar to the single-file-app Silex model.
It is a bit more verbose than Silex but it will allow you to migrate up easily if you decide you need more of the framework.
Problem:
I’m unsure how to set up multi client application for Symfony so that we would not violate Symfony's best practices and work against the framework.
I would like to have one main Core namespace which would contain all the base model classes. Right next to the core I would like to set up client specific namespaces which would be used, based on client regional setting. For example LocalUS for US market, LocalUK, for UK market etc.
The Local* namespaces should take first priority for including twig templates, and as a fallback use core common shared views (as I understand, this is solvable via twig namespaces). Same goes for controllers and models - these are probably solvable via extending the Core namespaced classes? Is this all solvable via routing and providing paths for these Local* controllers?
I was looking up on github to see if there are any project that have similar setup but I couldn’t find anything.
A little background:
We have an older legacy PHP Application which was built in-house from ground up using plain PHP. As the application has grown over time, it has become hard to maintain good code quality and standards. It’s also very time consuming to teach new developers our application logic, since the application basically follows no standard design patterns and just does it’s own thing. A lot of the underlying code which handles routes, controllers etc seems to work like “magic” that nobody really dares to touch.
It is because of that we would like to migrate our application to Symfony3 framework. I’ve read some articles about the overall process of migrating legacy applications to symfony, and managed to do it with silex pretty well. Silex, however is a bit too lightweight, I found that the assetic service provider had a lot of functionality missing (twig namespacing etc), and decided it would be best if we could move to a full stack symfony framework instead.
Look into Symfony bundles - they do exactly what you need. You create a "base" bundle, than extend it with other bundles. That's how FOSUserBundle works - it provides everything you need, than you extend it and overwrite it.
I'm wondering if ZF2 is based entierly on MOVE instead of the classic MVC.
Somewhere I read that is really bases on MOVE (http://cirw.in/blog/time-to-move-on) but e.g. in the "getting started tutorial" (http://zf2.readthedocs.org/en/latest/user-guide/overview.html) they are saying "creating a simple database driven application using the Model-View-Controller paradigm".
So, what is it now based on? Does it support both?
I'm a bit confused. What are the difference at MVC between ZF1 and ZF2?
Thanks
MOVE (Models, Operations, Views and Events)
MVC (Models, Views, Controllers)
The problem with MVC is that you end up stuffing too much code into controllers,
to overcome this problem MOVE is another possible option to choose in zf2 projects,
Because in this architecture you can split your controller into Events and Operations.
Question: Is ZF2 based entirely on the MOVE architecture?
I don't think ZF2 is designed entirely on MOVE architecture.
ZF2 follows the SOLID object oriented design principle with loosely coupled MVC architecture which provide more flexibility in terms of usability.
Question: Can I develop my projects using the MOVE architecture in ZF2?
Yes ZF2 provides you with everything to support both architectures (MOVE, MVC).
It provides Models, Views, Controllers(Operations), Events.
It is up to the developer which architecture he would like to use.
ZF1 and ZF2 is compared in another thread.
MVC or MOVE
SOLID Object Oriented Programing
I am still a beginner in zf2, I am writing here since I had ported my zf1 code entirely to new zf2 framework. I could only say the new framework have lot of advantages and once you get certain new concepts and feature. you can save lot of time developing new project by reusing of modules/components etc.
In zf2 most of the library components are designed to be standalone, i.e loosely coupled, as said it gives more flexibility and a task can be done in many ways (just like PHP is). The main advantage I see is modules, I can split my project to many modules with ease and test individually and integrate very easily without any additional codes. Even I had all my resources like images, css and JavaScript files inside my module folders and access it without any problem (off course with a small code in index.php)
for me ZF1 has fixed rules, flows, etc, and zf2 have liberated flow and rules with new addition of events namespace, configuration and lazy loading, assemble objects, inject dependencies with servicemanger. in zf1 routes are automatic(programmatic), where as in zf2 we need route definition, in zf1 controllers are automatically choosen, where as in zf2 we need to define controllers as invokables, this are few things that take some time to get in once you get the idea you will feel the comfort of using the new zf2 framework
to start with you can do this steps
Learn Service Manager
How Configuration works
How events work
Components wise more or less it works the same as in zf1 (at least in my case)
below are the following advantage I had benefited
Full feel of OOP
Modular application development
Design and then develop to PHP application
Web Application(RIA) platform
I've got a huge site that has been written (in a very bad way) in symfony 1.4
now, I've been asked to make some substantial changes to the navigation flow, add some features and so on..
considering the effort, I was wondering if it would be better to take the radical decision to port the entire website to symfony 2.0, but I'm not sure how hard that it could be.
Has anybody ever done this before?
Do you have any suggestion to make for patterns to follow, or tutorials or doc or whatever?
You may wrap your legacy project in a brand new sf2 project, by using this bundle. This way, you'll be able to migrate your project one piece at a time, and new functionalities may be developed with sf2 as soon as you get the wrapper to work.
You may be interested by this post about migrating
Here's how I would go about it:
You need to learn and study some things first:
HTTP fundamentals
PHP namespaces, which are heavily used
Symfony2 documentation
Symfony2 documentation
Symfony2 documentation
PHPUnit documentation
Then when you get the hang of Symfony2, you need to find out what to reuse from your old project:
Models, business logic?
Did you use Doctrine in symfony? If yes, look at how to port your entities to Doctrine2, and learn about the differences. If you used Propel, I would look at switching to Doctrine2 and not use the PropelBundle, atleast until you get used to Symfony2. You can find better documentation and sample code out there for Doctrine2.
You also need to convert your old helpers classes to Symfony2 services.
Views?
Symfony2 uses Twig as templating engine, but you could go with pure PHP.
Controllers?
This should feel somewhat similar to symfony. The flow of Symfony2 matches the HTTP flow, meaning you get a Request object and must reurn a Response object.
It really depends on how well structured our old project is. Symfony2 is an entirely different beast than 1.0-1.4. I would probably not call it a port, but a rewrite - however, if your old project is well structured you could probably reuse quite a bit.
Without actually seeing your code, it's impossible to give a good answer on how hard it would be. It's very much doable, but there is no easy route. Symfony2 is, IMHO, the way of the future for PHP projects and in the end you will get a project that is much easier to maintain and support.
I'm not sure if this is possible, but let's say you want to build a CMS, but you're torn between 2 frameworks because each has some features that you like. Is it possible to create the CMS with both framewoks? Does this approach have merits or pitfalls?
Speaking strictly about the Zend Framework (ZF) I would say yes. ZF components are written to be as independent from other components as possible. I would say that it would not be very difficult (It may actually be quite common) to integrate libraries of ZF into other frameworks like Cake, Symfony, or Codeigniter.
Is it possible to create the CMS with both framewoks?
While it's possible to use components from the Zend Framework inside other Frameworks / CMSs - this may be the case with other component libraries as well, but Zend's the most modular one that I know - It's usually not a good idea to mix two full-blown Frameworks.
Many central functions like MVC structures, URL routing, the database layer, Unit testing, error management and so on are by nature unable to be served by two frameworks at once without massive friction. Also, you're likely to get problems when one of the frameworks needs to be updated.
I would recommend to pick the framework that covers most of what you need, and try and add the missing features using plug-ins or own modifications.
Your question is too abstract.
For instance Zend Framework is more to be a library of specific functionalities ready-to-be-include into Your codebase then some closed development environment like for instance Symfony framework.
Thanks to it can be ZF simply included into your codebase (and Symfony too).
Symfony Framework compared to it is closed solution depending on front server environment so you cannot use it like some other framewor's slave.
It would really depend on which things you liked about both...
Zend Frameowrk is more like a library, so you can pick and choose components from it. Symfony also has some re-usable components you can use.
Really, you can do anything... it just depends how much work you want to do, and how willing you are to modify the framework code. Note: most other PHP frameworks are not nearly as flexible as Zend Framework (next up probably being Symfony).
This sounds very messy, so I'd advise against it, unless you use it in the fashion I've described above. It's easy to pull ZF or Symfony components into other frameworks, but not the other way around.
Hope this helps.
The composability of most frameworks is such that that is most likely to give you all the disadvantages of both, while simultaneously eliminating most of the individual advantages of both.
It seems to me like one framework will for serve as the core - bootstrapping, MVC stack, routing - while the other will be used to pull in specific functionality - like classes for forms or filtering or interacting with web services, etc.
As much as I prefer Zend Framework for the core - and most everything else - its use-at-will architecture argues for making the other framework the core and pulling in ZF components where you need them.
As #Adrian notes, it's easy to pull in ZF components into a project built primarily on another framework, since ZF is designed with that flexibility in mind. Other frameworks are less accommodating in this regard.
You can do it. Most modern frameworks (Zend, symfony, flow) is capable to use parts of other frameworks. Symfony 2 uses Zend Logger, flow3 uses sfYaml... It is possible tu interchange some components.
But, imho, you should stick to one framework as a core, and use second only to relatively isolated subsystems. Adapter and Facade design patterns can help you to mix them together - some components / clases demands some wrapping before use in non-native environment.
For further reading: http://www.symfony-project.org/book/1_2/17-Extending-Symfony#chapter_17_integrating_with_other_framework_s_components
Of course it is possible and I don't see something wrong with it. For example I used CakePHP and Zend on a relatively large Project which was kind of a cms. CakePHP for the core (Routing, MVC) and Zend for some "Modules". Mainly for PDF, E-Mail (smtp), FTP and a few others that CakePHP was not that good at. With Cake it was fairly easy to use ZF components and didn't feel hacky at all.
In fact, ZF was written to be as independent as possible, so that you can use any component at any time anywhere. Yet, it would not work the other way round (Using ZF as core, and Cake components). Surely it is possible, but a real pain with no benefits. So ZF could be used propably inside of pretty much any other framework and nothing would be wrong with it, imho.