I've seen this layering before, in fact I'm working on a .NET project with this exact layering (DataAccessLayer and BusinessLayer). The BusinessLayer object does absolutely nothing. I've seen this pattern in use many times and it introduces an additional class that adds no value. I would just use the DataAccessLayer class.

Besides, your BusinessLayer class doesn't actually contain any business logic.

The DataAccessLayer class looks mostly fine, except I would drop the "DAL" suffix on all the method names. The class name takes care of telling you its the "Data Access Layer".

The exception handling needs some reworking. In fact, if a PDOException gets thrown, I would just let it go. Catch it in your Slim controller methods and echo the error JSON. Don't do that in your DAL. And please please please please please don't swallow errors. Log them some place --- but not in the Data Access Layer.

function addCategory ($id) {
    $logger = new Logger(); // <- You will have to implement this

    try {
        $request = \Slim\Slim::getInstance()->request();
        $category = json_decode($request->getBody());       
        $bll = new BusinessLayer();
        $result = json_encode($bll->addCategoryBLL($category->cat_name, $category->cat_color, $id));
        echo $result;
    }
    catch (PDOException $ex) {
        $logger->error($ex);
        echo '{"error": "' . $ex->getMessage() . '"}';
    }
}

class Logger {
    public function error(Exception $ex) {
        // log error message and stack trace
    }
}

Separation of Concerns

@mikehomme commented:

(The business layer will) handle a lot of things such as validation, authentication, usage limits, etc.

Just those three things should be three additional layers in your application. In fact, authentication and rate limiting (usage limits) are great candidates for Slim PHP middleware. Your controller functions shouldn't even get invoked in the first place if the user is not authenticated, plus you would be repeating all of the authentication logic in each controller function. Don't Repeat Yourself (DRY) can be adhered to if you insert authentication and rate limiting in the middleware tier of your application.

Now your routes become:

$app->post('/calendars/:id/categories', 'authenticateRequest', 'enforceUsageLimit', 'addCategory');

The middleware functions:

function authenticateUser() {
    // Get auth token from query string
    // Query DB for user

    if (!$valid) {
        $app->redirect(...);
    }
}

function enforceUsageLimit() {
    // Find user in DB
    // Increment request count

    if ($numberOfRequests > $limit) {
        $app->redirect(...);
    }
}

Validation

Validation deserves a little more explanation. First, I would recommend against using plain old Arrays to hold you data. There are good O/RM's out there for PHP so you can deal with concrete classes. Your Data Access Layer should be returning Domain Models. A Domain Model is a class that represents a row in one table of the database. It gives you the ability to bundle data with behavior in a modular fashion. The validator class should handle validating the whole domain model object and keeping track of the error messages.

Putting your validation rules in it's own class or classes allows you to use the validation rules in multiple contexts (or multiple controller functions). It becomes an extra if statement, but is necessary in every MVC style framework I've used (Ruby on Rails, Codeigniter, ASP.NET MVC).

First, the domain model: Category

Category Domain Model

class Category {
    private $name;
    private $color;
    private $id;

    public function Category($data = array()) {
        foreach ($data as $key => $value) {
            $this->$key = $value;
        }
    }

    public function getName() {
        return $this->name;
    }

    public function setName($value) {
        $this->name = $value;
    }

    public function getColor() {
        return $this->color;
    }

    public function setColor($value) {
        $this->color = $value;
    }

    public function getId() {
        return $this->id;
    }

    public function setId($value) {
        $this->id = $value;
    }
}

This class represents a row in the "categories" table in the database. It takes a hash of key value pairs to populate its properties in the constructor. It has little more than getters and setters right now, but if you need to add functionality that concerns categories, this is the class to add it (related reading: Domain Driven Design)

Now the validation classes:

class BaseValidator {
    private $errors;

    public function __construct() {
        $this->errors = array();
    }

    public function addError($key, $message) {
        if (empty($this->errors[$key])) {
            $this->errors[$key] = array();
        }

        $this->errors[$key][] = ucfirst($key) . ' ' . $message;
    }

    public function getErrors() {
        return $this->errors;
    }

    public function hasErrors() {
        return !empty($this->errors);
    }
}

This provides the foundation for the other validator classes.

class CategoryValidator extends BaseValidator {
    public function __construct() {
        parent::__construct();
    }

    public function isValid(Category $model) {
        if (empty($model->getName())) {
            $this->addError('name', 'is required')
        }

        if (empty($model->getColor())) {
            $this->addError('color', 'is required');
        }

        if (empty($model->getId())) {
            $this->addError('Id', 'is required');
        }

        return !$this->hasErrors();
    }
}

This validates Category objects.

Now your controller function will need some changes and cleaning up:

function addCategory($id) {
    $validator = new CategoryValidator();
    $data = json_decode(\Slim\Slim::getInstance()->request()->getBody());
    $category = new Category($data);
    $category->setId($id);
    $repository = new DataLayer();

    if ($validator->isValid($category)) {
        $repository->createCategory($category);
        echo '{"category": ' . json_encode($data) . '}';
    } else {
        echo '{"errors": ' . json_encode($validator->getErrors()) . '}';
    }
}

The controller function becomes pretty dumb. The data access layer is pretty dumb. This is the position you want to be in. The controller just does stuff. Why stuff happens is delegated to the validator and domain layers of your application. What to do when stuff happens is the responsibility of the controller function. The data access layer should assume that all data is valid before persisting it to the database, and it should fail noisily and immediately if anything goes wrong (i.e. let it throw exceptions). Also notice that we pass a Category object into the data access layer instead of an array.

People rail against strongly typed code, but there are advantages, and this is one of them. You get a clear idea of what data you are dealing with, so, changes to the data access layer:

class DataLayer {

    public function addCategory (Category $category) {
        $sql = "INSERT INTO categories (
            cat_name, 
            catcolor,
            calendar_id
            ) 
            VALUES (:cat_name, :catcolor, :calendar_id)";

     $db = $this->connect();
     $stmt = $db->prepare($sql);
     $stmt->bindParam("cat_name", $category->getName());
     $stmt->bindParam("catcolor", $category->getColor());
     $stmt->bindParam("calendar_id", $category->getId());
     $stmt->execute();
    }

}

Error Handling

Slim PHP has its own error handling. Read up on it and learn it. Your controller functions don't need to trap exceptions and log them. Just let them bubble up the call stack --- unless you can gracefully handle the exception.

Additional Layers Promotes Unit Testing

Having these layers:

1. Controller functions
2. Middleware for authentication and rate limiting
3. Validators
4. Domain Models
5. Data Access

Exposes more of your application to unit tests so you can test your application without a full blown technology stack powering it. These unit tests can cover the functionality in your validators and domain models without invoking a web server or database. Now you can throw a mob of tests at your business logic in the domain model and validator layers, and these tests execute in seconds. Compare that with how long manual testing takes, and you are setting yourself up to iterate on this application very quickly. The test coverage also means that changing frameworks or upgrading dependencies becomes easier. Upgrade the framework and depedencies, run unit tests. When the tests pass, you've got about 60 to 80% of the work done.

As a side story, I worked on a large Rails project a while back. It had close to 40 models, and integrated with over a dozen web services. We upgraded our Ruby on Rails framework, as well as upgraded the base Ruby language itself. We had about 1,800 unit tests, and around 800 automated functional tests that drove the web browser. We completed the non compatible framework, dependency AND language upgrade in one month, start to finish --- and we delivered about 5 new features at the same time. One developer was responsible for the upgrade while the others built the new features. Once the 2,400 unit and functional tests were passing, it was easy peasey, rice and cheesey to upgrade the new features as well.

Two weeks of development, two weeks of QA and user acceptance testing plus software upgrades to all pre production and production servers. This was all possible because of the test coverage we had.

And the test coverage was possible because we had these same layers in our application.