I read that facades are not good. I have no idea if that is correct. I also read that Laravel uses a lot of them. Further, I read you can turn them off in Lumen. "Turn off" may not be the right word.
Do you have to use Laravel with facades? If I do not use the facades, does this mean I should probably not have chosen Laravel in the first place?
You aren't forced to use facades.
Check documentation at https://laravel.com/docs/5.1/facades
Just use app helper to get what you need.
app('router');
app('config')
or you can use IoC. There are a lot of ways.
In fact you don't need to use facades in your app. If you look at Facades class reference for each facade you can find class in this table. So for example instead of DB facade you can inject Illuminate\Database\DatabaseManager and you can use its method.
Using facade you would use:
DB:beginTransaction();
and injecting class and assigning it to class property you can write:
$this->db->beginTransaction();
Related
Symfony has this:
https://symfony.com/doc/4.1/components/templating.html#helpers
I can't find laravels equivalent? What do people use in Laravel in place of this?
I myself have tried creating custom helpers.php, which is good for some use cases I guess, but now I'm at the point, where I would like something a little bit more structured.
I am thinking maybe Facades would be be good option?
Is there anything else I could take a look at for Symfony's template helpers equivalent in Laravel?
I would say the closest thing to this is directives. It allows you to add new methods to blade that you can use.
Can find the docs here
You can also add a new facade if you need something more complex that will be accessable from the view layer as well.
Hope this helps!
I found that some developer use app(SomeService::class); while other use new SomeService(); in Laravel? Is there any difference between them?
Yes, the main difference is the ServiceContainer.
If you instantiate using app(YourService::class), the ServiceContainer will use reflection to inject in the class constructor the dependecies required.
So you don't have to explicit use all the dependencies needed.
It's well explained here.
Please check https://laravel.com/docs/5.7/providers.
Briefly speaking if you want to customize the class which you will use in runtime you can change it in provider (make it singleton or pass some arguments) and get in runtime via $app (if you have no opportunity to use DI). but when you making object vie new its only creates an instance.
Imagine that we have class A which receive 2 config parameters in construction.
So you need everywhere call new A($param1,$param2) . but using providers u can use DI to get instance of class A with already passed parameters or $app if u have no opportunity to use DI
I am looking for a way to add few custom methods which will be used in all models. I can imagine 3 ways of doing it :
Adding custom method to main Eloquent's Model.php class file(I want to avoid doing this as this is a core file)
Creating a custom model class with required custom methods, which will extend to eloquent's Model class and all the models in the project will extend to custom model class.
Adding a trait which will have my methods and include it inside all models
However, I want to do it more efficiently and best way possible. Is their any other way to do it?
PS I am using laravel 5.2 as its an old project.
Based on the comment discussion and adding my experience in Laravel I would suggest you to go either with #2 or #3 approach as #ceejayoz have specified in the comments
first one is definitely a bad approach as you need to modify the core which is not at all a good practice. Second and third are both good approaches.
But, before that you need to check your requirements if literally all models (including any future ones your app will ever have) need the extra functionality, however you can use traits for all models.
If I have the choice probably I will go for traits over custom models as traits are relatively simple then custom models
I have a class called Awesome and have used the ServiceProvider and the Facade to register it to the app. Now I can use it as Awesome::Things().
I want to add constants to this class, so I tried
<?php namespace Helper\Awesome;
class Awesome()
{
public static $MOVIE = 'I love the Lego Movie!";
}
but when I call Awesome::$MOVIE, I get Access to undeclared static property: Helper\\Aesome\\Facades\\AwesomeFacade::$MOVIE
Can someone help?
The short version is -- you don't really want to do that. Laravel facades aren't mean to be used like normal classes, and if your application uses them that way you'll likely confuse future developers.
Warning out of the way. When you create a "facade" in Laravel, you're actually creating a class alias. When you added Awesome to the alias list in app/config/app.php, at some point code like the following ran
class_alias('Helper\Aesome\Facades\AwesomeFacade','Awesome');
That means whenever you use a global non-namespaced class Awesome, PHP substitutes Helper\Aesome\Facades\AwesomeFacade. If you wanted to add constants, you'd need to add them to this class.
Laravel's able to pass through methods because of the base Facade class implements a __callStatic method that passes on your call to the actual service implementation object. Facades don't pass on static constant access. Additionally, PHP does not (appear to?) have similar magic methods for passing along requests for constants.
If you're curious about the in depth version of this answer, I'm currently writing a series on Laravel's object system, including some in-depth information about the facade implementation.
I have a Model in my Laravel app called Event. As I just discovered, this creates a conflict between my model and Illuminate\Support\Facades\Event, a built-in facade. The obvious solution here is to either change the name of my Model, which is not ideal because there is really no other name I could give my Model that makes any sense, or to rename the alias in app.php for Illuminate\Support\Facades\Event, which I'd like to avoid for fear of breaking anything that may rely on that alias in the future (I'm afraid I may forget).
It's been suggested that perhaps I could use namespaces, which I attempted as follows:
app/models/Event.php
namespace Models; #<-- I've also tried using "\Models" here
class Event extends \Eloquent{
app/database/seeds/DatabaseSeeder.php
Models\Event::create(); #<-- again, I've also used "\Models\Event"
All 4 combinations above have yielded a Class 'Models\Event' not found error when I run php artisan db:seed.
Perhaps I simply don't understand namespaces properly, but the more pressing issue is how to solve my problem. If it can be solved using namespaces as suggested, great, but I'm open to any other ideas as well.
I made this mistake early on as well, not necessarily understanding the role of namespace throughout the entire app.
The namespace should mark the business logic within the domain or responsibility of the app itself, so giving a namespace of Models isn't necessarily useful. Instead create a root namespace named after the app, your company, you, or whatever you like, then provide a Model sub-namespace.
For example:
namespace MyGreatApp\Models;
class Event extends \Eloquent{ }
Then you would reference this model under:
use MyGreatApp\Models\Event;
$event = new Event();
In the long run this is a cleaner and more organized approach. This does mean moving your models into a different folder, though. But there's nothing wrong with that. At least that way you know you have all your custom code in your MyGreatApp namespace. :)