I was just curious about Facade and service container binding functions in Laravel 5.1, let's say Reponse::json() and response()->json() are the same. But is there any reason that one of them is better than the other?
It is already stated on the Laravel's documentation
Facades provide a "static" interface to classes that are available in
the application's service container. Laravel ships with many facades,
and you have probably been using them without even knowing it! Laravel
"facades" serve as "static proxies" to underlying classes in the
service container, providing the benefit of a terse, expressive syntax
while maintaining more testability and flexibility than traditional
static methods.
And this article by the creator of Laravel will also help you.
Related
I'm building application at top of the Laravel. In my Domain layer I have services. One of these needs to send an EMail. Laravel has Illuminate\Mail package for these purposes.
But Mailer contract depends on \Illuminate\Mail\PendingMail class.
https://github.com/laravel/framework/blob/5.7/src/Illuminate/Contracts/Mail/Mailer.php
Does it mean I need to write my own interface (port) for my Domain layer to fully decouple my application from framework?
To be honest, I'm not sure what you are asking. But I'll try to answer anway.
If you use (any) framework functionality directly in your code, you obviously couple your application to the framework. That's the whole point of a framework. It offers you a lot of functionalities that are commonly used throughout different types of applications. It can be seen as foundation for an applciation. These functionalities are often made available through interfaces, so that the implementation can be swapped out if necessary. Swapping out the implementation doesn't make your application less coupled to the framework though. It just allows you to use a different kind of implementation; the interface will still be a framework one.
So, the only way to prevent (heavy) coupling with a framework would be to write your own interfaces that abstract all the framework functionalities. You could then have proxy classes that implement these new interfaces and do nothing else than proxying requests to the proper functions of the framework, allowing you to write other proxy classes in future for a different framework.
If you ask me, this sounds like a bad idea though. Because in the end, you are building your own framework based on your own interfaces. So you are using additional custom code which adds no additional functionality, but comes with the added risk of bugs and errors.
I do have ready the topics in the documentation, but please help me to know why this is the most correct way and what's wrong (and not enough) with methods like $this->load->model('User_model') or setting the /config/autoload.php configs in CodeIgniter?
In case we want to use additional controllers (like Request $request) as method injection, or UserRepository $users as contrustor injection (which is not a meaningful example in my opinion, but has be exampled in the main documentation) what's wrong with accessing those classes as properties (like $this->input->get('id')) or traits if we want to be committed to OOP concepts?
It more seems to be just coding style and framework conventions (which is of course important, too), isn't it?
I have been using for a while but still I am confuse on what to include in my controllers specifically "When should I use Model and When to Use Service"?
I am confused if I am making the right thing.
I would suggest to never use models directly into the controllers.. Adopt the repository-pattern which enables the use of dependency injection of services into the controller.. Use Service Layer to contain the business logic.. In this way all the related codes would be onto similar layer.
Reference for repository pattern:
http://heera.it/laravel-repository-pattern#.VuJcVfl97cs
Please don't use model directly in your controller, unless if you are building a very simple application but for a large application, it would be good to use a repository. Kindly take a look at this tutorial https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/
why is the scope of commerce facades marked prototype by default ? Is it that we always need a new instance of the requested facade every time we refer it or am I missing something here while understanding the concept of commerce facades in hybris ?
In commercefacades-spring.xml only some populators and some POJOs are marked prototype.
The facades are still singletons since they are noting but special services.
Hybris v5.x
Facades are singleton scoped beans by default. There is no need to create a new instance of facade object on every request.
Facades in Hybris are the implementation of Facade Design Pattern. To understand them deeply follow the links:
https://wiki.hybris.com/display/release5/Using+Facades+and+DTOs+-+Best+Practice
https://en.wikipedia.org/wiki/Facade_pattern
I'm trying to understand where Spring custom namespace can help -- like simplifying somethings in a large application.
The last comment on this blog was intriguing:
I'm building out a namespace at work for making service and bean management more standardized within the development group. This also tends to make things simpler and not have them worry if I change the standard for a bean definition or maybe use different factories for different types of services in the future. I'm still figuring out how to best utilize this new mechanism, though.
Trying to understand how custom namespace helps in bean management.
If you developed custom namespaces, could you please post how custom namespaces helped in your development.
This blog has a great post about using custom namespaces and gives you a few examples as well.
Check this github repo for a working example of spring's custom namespace handling.
Or this article on spring io.