I'm starting to use Laravel 5.1, I got knowledge in php, js, angular, express, node, apache, mysql, sqlserver, and some other things.
In Angular I like that everything is built as singletons, so that the main concepts are: modules, controllers, services, factories, directives, routes, views, scopes, etc...
I'd like to know what concepts do I need to understand when building an app under laravel?
Basically all you need to know is very well documented at the official documentation, Taylor Otwell made a huge effort doing the documentation to make the framwork more comprenhensible.
The basic concepts are:
Routing
Controllers
Views
Blade templating
Requests and Responses
Models & Migrations
After that keep an eye to in the Middleware concept, also there's a plenty of built-in services as: Auth, Pagination, Encryption, etc... check them out.
Something you'll love is Eloquent ORM, it simplifies the interaction with the database.
Laravel community has their own site and that is laracasts you could get help there too.
One of the most important features of Laravel is the Service Container (you'll hear about it also as the IoC Container) and the way it's used to register Services, provide Dependency Injection, and be a Registry for your application.
Middleware are one of my favorite feature of laravel: they are like filters executing before and after the requests, in which you can 'prepare' some data to be handled in the request or 'fix up' something after the request has been processed
Another peculiar feature are the Facades: (non to be confused with the homonym design pattern ) you'll see them everywhere, and you'll learn how they provide easy access to the service container keeping your code succint,readable and testable in the same time
Related
I've made an online store in php for school, and now my teacher wants this project to have a Laravel Framework. And I have no freaking idea how to do it. Are there any possibilities to implement this framework to my project, or my project to this framework, without starting from scratch? If yes, how should I do it?
irrespective, its going to involve a lot of rework. A lot also comes to down to HOW you've developed your original php app. Laravel is a Model View Controller framework. For starters all your routes (http redirects) are generally managed in a single file (web.php). Your views can be traditional php, however, Laravel gives you a good templating engine called Blade which allows you to shorthand code and keep code a lot cleaner. Models control your table relationships, controllers handle the functions/code/crud etc.
You will love how easy it is in most respects - especially the way eloquent data queries work etc. It can greatly reduce your code.
If your teacher wants you to LEARN Laravel specifically, I would say YES you will be starting over - however, your logic in the code should just need reworking rather than start from scratch.
There are heaps of posts around HOW to install Laravel (apache, virtual box, homestead etc) - once your ready, its super simple to create a new project and start building away... If you are new to MVC, you should do some tutorials first (e.g. laracasts or other).
Best of luck :)
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.
In a Symfony/Doctrine/PHP-project, a client is complaining that we've broken software development best practices. The complaint is about improper layering of the source code, and the lack of unit tests.
This is a sub $50k-project.
I believe that the client has an expert from the Java world, perhaps Spring Framework, looking at the source code.
We've been using proper MVC, as we see it.
View-logic is handled entirely by TWIG.
Database is handled entirely by Doctrine.
We're using Symfony Security for access control ($this->get('security.context')->isGranted('ROLE_ADMIN') and $this->get('security.context')->getToken()->getUser().
Beware that Symfony has changed the model a bit, since we started this project - but remains backward compatible.
In the controller the customer is specifically saying that it's wrong for the controller to handle:
Access Control (via Symfony Security)
Database Queries (via Doctrine)
"Parsing and other logic" for sending back responses (return $this->render('some_template.html.twig');)
The question
The client is saying that best practices is for the controller to simply pass on requests to another layer further down in the system.
Further he's saying that user-admin is based on a "custom model" where all users and roles are stored in the database - which makes plugging in a different access control system difficult. Specifically because role names seems to be hard coded such as via commands such as ($this->get('security.context')->isGranted('ROLE_ADMIN').
So; is there a definitive best practice on this field? What belongs in the controller, and is Doctrine, Twig, Symfony Security "sufficiently" a separate layer "below the controller".
Should there be yet another layer between the controller and Doctrine for example?
Source: http://fabien.potencier.org/what-is-symfony2.html
First, what is Symfony2?
First, Symfony2 is a reusable set of standalone, decoupled, and cohesive PHP components that solve common web development problems.
Then, based on these components, Symfony2 is also a full-stack web framework.
Depending on your project and depending on your needs, you can either pick and choose some of the Symfony2 components and start your project with them, or you can use the full-stack framework and benefit from the tight integration it provides out of the box. And choosing between the two different approaches is really up to you.
Is Symfony2 an MVC framework?
Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM. Of course, tight integration exists for the most well known ORMs like Doctrine2 and Propel; but they are optional dependencies. The Symfony2 core features do not and will never rely on any ORM.
Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.
Symfony about best practices: https://symfony.com/doc/current/best_practices.html
You should rly read this about controller best practices:
https://symfony.com/doc/current/best_practices.html#controllers
You can read this answer https://stackoverflow.com/a/21701890/2160958
I'm studying the Laravel 3, 1 week ago, but didn't understand everything about the routes.
My main question is: how to create administrative routes?
In the video lessons from Jeffrey Way (Tuts Premium), I could understand two things about it:
Nested Controllers (/application/controllers/admin/user.php)
Bundles (/bundles/user.php) - He did not say much about it.
Anyway, I noticed 2 things (obvious):
On both sides, I can have a route / admin / whatever.
But what the correct way?
I'm really very confused.
Laravel bundles are for developing modular code that you can reuse from application to application in Laravel. The Bundle itself is very much the same as the 'application' directory you have as standard in a Laravel install, allowing you to create modular sub applications within your project. I highly recommend you avoid bundles for the moment entirely and focus on learning the core functionality of Laravel.
For your needs, place your routes within your routes.php file within the application directory and nest them to your hearts content. This will serve your purposes fine. If you're not building/using bundles, you don't need to use bundle routes.
When you're comfortable with Laravels routing and you've built one or two apps you may well have an idea for a bundle that will help you develop your apps faster in the future. This is the time to start learning about bundle routing as it's the only way to link your application logic with your bundle and provide it with a URL schema.
Hope that helps.
Neither way is really right or wrong, the beauty of Laravel is that there are so many ways to achieve the same thing so it's up to the developer to choose what works for them.
Personally I started by using nested controllers as they're much easier to get up and running. I would however recommend making the move to bundles. If you plan on sticking with Laravel (and you should) then it would make sense to build a bundle that includes the auth and components you use in each project already setup. That way you just need install the bundle and you're good to go.
You've probably heard of the Fat Model/Thin Controller vs. Thin Model/Fat Controller distinction. I recently heard that you can have something in between where some of the logic from the model goes into a service layer. How common is this? and do you know of (or can think of) any real examples that illustrate it?
Martin Fowler describes the Service Layer pattern of his great book Patterns of Enterprise Application Architecture. If you care about questions like the one you asked, you should read this book.
One use that comes to my mind is managing database transactions. Some people try to encapsulate starting and committing transactions in their domain models. But then they get confused when domain models invoke other domain models that also try to start and commit db transactions. So which model really gets to decide if a transaction is committed or rolled back? And what do you do if a given model is used in different ways by different clients?
The Service Layer is a solution for this, because this is the layer in which you can start and commit work that involves multiple domain models.
As for how common this is, I don't think it's common at all. Most people using Zend Framework (or any other PHP or Ruby framework) have just barely moved from "Active Record solves everything" to the new shiny, "Data Mapper solves everything." It seems this community learns only one new pattern every five years. They won't get to Service Layer for a while.
Re comment from #ktutnik:
No, the Service Layer pattern is different from Repository pattern. Repository is about abstracting database access so you can use a database like a Collection. Service Layer is about encapsulating complex application operations.
Another way of thinking about them is their relationship to the Domain Model. The Repository is used between the Domain Model and the database. Whereas the Service Layer uses one or more Domain Models.
Service Layer ---> Domain Model(s) ---> Repository ---> DBAL
Service layer advocacy is relatively new and still subject to a variety of interpretations. I think it means having a layer that leverages multiple domain models which the controllers call (I may be simplifying it too much though). I recently developed a website making use of this and practical advantages I've encountered are:
Features as a service helps with scalability. If you have an image service that initially uses the local service to do it's work it becomes easier to have that service point to another server or some 3rd party without having to make sweeping updates
Flexibility. Half way through the project I decided to change a core piece of functionality and was able to do so painlessly; allowing me to quickly weigh the pros and cons of the update. This flexibility is useful when rapid prototyping and instills a certain confidence because if you need to revisit something it's not going to be a nightmare.
Extensibility. I have already identified services in my application what I can forsee opening to other developers or other widgets, mobile apps in the future. Doing so in theory is just a matter of adding authentication and authorization to the service (because the features are already in it's own layer and I don't have to spend time trying to decouple what I want to expose from the rest of the code base).
Services are easy to add and drop (maybe this belongs with one of the earlier points). I have services that a specific to a specific stage in the project (e.g. invite only stage) that I can drop once that phase is over.
I think it has practical advantages and a key to success in implementation is having a good way to manage the services in the application. I use symfony's dependency injection component
See ZFEngine it's cmf on ZF with service layer realisation