Skip to main content

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 within some scopes 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 project management is scope.

When the desire to obtain a solution is stronger than the desire to consider the implications, 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 this:

     class MyModel extends Model {
          public function getUri() {

               return Request::root() . '/mymodel/' . $this->slug;

          }
     }

...and then think that you've done a great job at putting the code where it belongs, encapsulation, simplicity, elegance and other nice things.

Unfortunately, what you've also done is created a dependency by conflating a service concern with your model.  Understand that this isn't because you've used a static method, but because you've used a class resolved via the container that might not be ready yet.

So what?

You could be blithe about this and think "I'm always going to be in a request because I'm coding for the web!"  At which point, we're facing another convenience decision and it becomes all too easy to see where things unravel:
  • Scope
    Imagine you find the model class above performing in a scope that doesn't find itself within a request.  This could be in a cron, or it could be when you need your class running in a Java servlet.  These are just two examples, but a change in scope can and will catch you by surprise and your programs will crash trying to use a method that was made in haste.
  • Cross Cutting Concerns
    Suddenly a method you've authored on a class requires a security check, but you don't have access to the necessary information from within the class to do this.  You're faced now with either a regression or further convenience decisions that lead to bloated model code.  That can lead to duplication  at best because you didn't take the time to carefully construct a new scope to perform the operation desired.

What instead?

Make services!  There is a fine line here, but when you need to do an operation that blends disparate pieces of information, make a service.  The dependencies of that service will represent the scope you wish to create for that particular operation.  Once that service is made, you can rest easy knowing it exists in a space that has all the right information and state to perform the singular operation you're after.

The other benefit is that it gives you a centralized point to handle cross cutting concerns.  If one day you need to perform a secondary operation (security checks, analytics, accounting), you won't be adding more bloat to your model.  You will simply find the scope (read: service) you know the operation transpires in, and add it there.


I can assure you that by taking this approach, you'll be doing yourself a favour in the single responsibility, cohesion, repeatability and DRY departments.

Popular posts from this blog

Making TypeScript npm Packages

If you've landed here, I can only assume you're like me and see packages as the highest form of sophistication in software development.  In that same vein, I bet at some point in the past you've wished you could start applying DRY principles to your client-side efforts.  I know for myself, I don't enjoy writing the same application bootstrap code constantly and so recently, I was motivated to codify it.

This body of understanding has taken me quite some while to figure out, hopefully what I share here is helpful enough to get you up to speed.  No post is complete without some kind of example, so throughout I'm going to reference a package I've just finished putting together called protoculture.

Briefly described, protoculture encapsulates all the common bootstrap and conventions I've been using while developing TypeScript apps that use React and Redux.  Honestly, I've already gotten a lot of benefit out of putting this package together, but nothing about…

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of.
Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: CodingProject structureSoftware architectureBuildingDeliveryCommunityLicensing
After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis.  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget.


In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as a framework-framework. The…

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 considering that our a…