Symfony: how to get started

    The more I work on my first project at work, the more I want to change it and the more I regret that before starting work I did not read the “ The Definitive Guide to Symfony ” and did not study the plugins for Symfony . Many of them would help me greatly reduce development time and, most importantly, not think about how to implement these or other things beautifully ... And one more thing - if you already have a piece of the system (as I had it) that you If you are going to rewrite using your framework (or just rewrite, because you don’t like the code) - then my advice is to take the time to design this piece on the plan of your new system, do not rush to rewrite everything right away(I confess, I did just that), because after the analysis (which, perhaps, will take you more than one day, or even more than one week), perhaps, the previous system architecture will not leave a trace.
    In general, I like to design, think over, analyze these or those solutions that I want to implement in the system (although, I admit, I have little experience in this), but how to explain to the customer that you spent a day in thought ... Eh ...
    Well, that's I got distracted. Today I want to talk about where to start when developing a system using Symfony and what rules should be followed.

    Actually, it all starts with the creation of the project (project) and applications (applications) in it. How this is done can be read in the book (the link is given above), but I would like to dwell on an explanation of what a project is and the principles for choosing applications in it - what names they should give, how to structure them, etc.

    Project


    As I understand it, in the general case, it is assumed that you will have one project on the entire site, and it will be a kind of repository of applications, configuration files and models that all applications of this project will use.

    Applications


    Unlike Django - here the application is not an atomic unit of the system that can be used in other projects ... In Symfony they are created only to logically (well, physically) distinguish between the functionality of your project. And most importantly - applications have a place to be only within the framework of one project. Those. if you uninstall one application within the project, others will not suffer from it, but transferring from one project to another application will be very problematic, because it depends on the project settings, on the project model, and so on.
    It will be useful to say that it is officially recommended (read as “proposed”) to create two applications in the project: frontend and backend (for the Russian-speaking audience, the term “admin” in this case will be more appropriate). I myself can recommend creating applications only for combining modules that set one goal. For example, the same admin panel, the user interface (that is, for example, the user profile, everything that the user can change on the site) and frontend (everything that is accessible to everyone).
    I myself use the recommendation of the book and have two applications in my project.

    I do not want to consider the pros and cons of this approach. I can only say that for me the Django’s approach is much more convenient and logical, and these projects / applications for a beginner look rather complicated and incomprehensible, in most cases, newcomers just listen to the recommendations of the book, not quite understanding what it is and why it is needed. I would think about reconsidering this approach in place of Symfony developers, especially considering that plugins in Symfony are essentially the same Django apps, but more on that later.

    Environments


    I don’t especially want to dwell on the surroundings. This is a very convenient, but at the same time very simple mechanism, providing the ability to log into the same application with different server settings. To put it simply, imagine that you have applications and a checkmark that switches its mode of operation to debug-mode and vice versa. In debug-mode, for example, all events are logged, all errors are displayed on the screen, etc. If debug-mode is turned off, all logs are turned off, and no errors will ever appear on the screen. So - in Symfony instead of the debug / non-debug flagthere are just a few different environments, each of which can be fully configured, that is, it is not the system that decides what to turn on and what to turn off, and you yourself. I would also like to note that you don’t have to delve into the settings much - by default, 3 environments are created for each application: production, development, testing (used exclusively for testing).
    In general, there is nothing to complain about - everything, in my opinion, is just perfect.

    Modules


    ... contain a controller with actions and views (i.e. MV from MVC ), as well as configuration files and, possibly, libraries that are needed only in this particular module. Everything is quite simple and clear here.

    Modules (like applications with a project) can be created automatically (and using the command line). In addition to creating a simple module, you can create (again - automatically) CRUD ( Scaffolding) for one of the tables, or the admin panel (again, for one of the tables). The admin panel differs in that you practically do not need to write any code - almost everything in it (filtering, sorting, etc.) is configured using the configuration file, which is VERY convenient (hello to the junglers, they will understand). CRUD is very useful in the initial stages of development. Example - you added a user table, now you need to: display a list of users, allow them to edit their profile and register. Instead of writing everything from the very beginning, we create a CRUD module for the user table, and then you can start writing your own code based on the already generated code. An implicit advantage of this solution is the fact that the codes of the modules are obtained similar to each other and there is less confusion.
    The last thing I would like to dwell on is ...

    Models


    All models are stored in one (or several) YAML files. You get used to writing models in 3-4 days. From YAML, a model with one command is converted to automatically generated base ORM classes ( Propel or Doctrine ). Everything is fast, simple and neat.

    Perhaps this is all that a beginner might need when studying Symfony (so that it does not seem to him some kind of complex and incomprehensible system, which it seemed to me a year ago).
    And now we will pass directly to my recommendations. But before that I will tell you about ...

    Plugins


    Plugins are, in fact, that code which can be used several times in different projects and applications. Plugins may contain:
    • configuration files, including their models (!!!)
    • modules
    • libraries

    I may be wrong, but it seems to me that plugins are such mini-projects, “all in themselves”, which compares favorably with Symfony applications. In my opinion, the bet should be made primarily on them - to remove applications, and instead install plugins and create some kind of tool that would allow these plugins to communicate with each other.

    My recommendations


    • First of all - design. Do not skimp on this step, analyze and clarify incomprehensible points with the customer.
    • Seeing in front of you (yes, even in your mind) the layout of the system - think over what parts of the system can be divided.
    • Look for such parts among existing plugins ( required ). I used the following plugins in my project:


    • Use automatically generated CRUD modules and admin modules in your work


    Related Links




    That's probably all for today. Waiting for your comments.

    Crosspost on my blog.

    Also popular now: