Skip to main content

Moving away from Laravel Facades

Are you looking for a way to resolve things like translation, validation and config from the Laravel IoC? Look no further!

Make yourself a service provider (whether in a common tools package or in your project) and add the following to it in the register method:

 $this->app->bind('Symfony\Component\Translation\TranslatorInterface', function ($app) {
  return $app['translator'];
 });

 $this->app->bind('Illuminate\Config\Repository', function ($app) {
  return $app['config'];
 });

What you've done is mapped all the string-registered services to their most abstract but also most specific types.  Config is a good example of where you should be binding the class name and not an interface because the only interfaces it implements are ArrayAccess, and that's obviously wrong! :)

Happy constructor-injecting!

Comments

Post a Comment

Popular posts from this blog

Laravel is Good, Facades Aren't

I've been working on some Laravel 4 based packages lately which inevitably results in me also looking at other packages. I've noticed sometimes that people use facades at times that give me pause. The most troubling being from inside their model classes. A quick google turned up this video which assures people "there's still an instance behind everything, we're fine" .  Everything mentioned in the video is true except that there is a very glaring omission. Scope What usually goes out the door at the start of a long series of mishaps in software design is scope . When the desire to obtain a solution is stronger than the desire to consider the implications of a firm approach, mistakes are sure to follow.  Sacrifices like this are made due to the assumption of a high cost to developing carefully. What really is happening however is a false dilemma , being responded to with a convenience decision . It's very easy to write model code like ...
1 comment
Read more

ASP.net Core 1 Projects on .NET Core 2

A small post for today although something I think could trip others up.  I'm trying out the latest WebJobs 3.0 beta which is a port of the 2.0 version with .net Core 2.0 support.  This is really exciting as .net Core projects are considerably easier to work with than .net 4.x.  There tends to be less magic and they're a lot more command line friendly. One issue is that in order to use the new WebJobs 3.0 library, my current ASP.net Core 1.x web applications need to be running on .net Core 2 to use it for dispatch.  This hasn't been too much of a hassle, it was largely just a matter of updating the TargetFramework entry in my csproj to netcoreapp2.0 .  You may also end up with a few other items to clean up after that as the netcoreapp2.0 TFM comes with some useful configurations out of the box to ensure well behaved .net 4.6 PCLs are easier to get into your projects. The one surprise I hit was that when I shipped things up to Azure App Service, I got a fairl...
Post a Comment
Read more

Laravel Project Architecture: The Missing Guide

At my job, we've been doing a lot of learning and development using Taylor Otwell 's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided. If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects. Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary. While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially consider...
5 comments
Read more