# Getting Started with My First Laravel 4 Project

> The structure that comes from moving beyond raw PHP to a framework: first impressions, installation, and the basics of Laravel 4.

- Published: 2014-06-01
- Category: Framework & Library
- Tags: PHP, Laravel
- Reading time: 3 min read
- Source: https://www.muhammetsafak.com.tr/en/blog/getting-started-with-my-first-laravel-4-project/
- Language: en-US
- Author: Muhammet Şafak

---
I've been writing PHP for six years. During that time, most of my projects grew out of raw PHP or small custom structures I built myself. Setting up routing, database connections, and session management from scratch on every project eventually became a routine burden. At some point I started asking: "how does everyone else solve this?"

I'd been loosely familiar with Laravel for about a year, but never took it seriously. This month I decided to actually use it for a client project. Here are my observations after a few weeks.

## Why a framework now?

When you build a project in raw PHP, you wire everything yourself. That feels like control at first, but maintenance gets harder as the project grows. [Composer](/en/blog/switching-to-composer-stop-managing-php-dependencies-by-hand/) and [PSR-4](/en/blog/psr-4-and-autoloading-escaping-the-include-chain/) improved the structure somewhat, but rebuilding the same boilerplate — routing, form handling, authentication — every single time is wasteful.

**Laravel 4** is a PHP framework built by Taylor Otwell on top of Composer. It uses Symfony components under the hood, which means it isn't "just another framework written from scratch" — it's a structured layer built on top of mature libraries.

## Installation

It requires Composer, so the habits I'd already picked up paid off right away:

```bash
composer create-project laravel/laravel projem 4.2.*
```

This command downloads the latest Laravel 4.2 release, installs dependencies, and creates a ready-to-run skeleton in the `projem/` directory. A working application in a matter of minutes.

## Directory structure

It felt unfamiliar at first glance, but I got used to it within a few days:

```
app/
├── config/        → database, application, mail configuration
├── controllers/   → controller classes
├── models/        → model classes
├── views/         → Blade template files
├── routes.php     → all URL definitions
public/            → web server document root
vendor/            → Composer packages
```

In my raw PHP projects I used to dump everything under `public_html/`. Here, only `public/` is exposed to the web — everything else sits outside. A sensible approach from a security standpoint.

## Routes

In Laravel you define your URLs in `app/routes.php`:

```php
<?php

Route::get('/', function() {
    return View::make('anasayfa');
});

Route::get('/kullaniciler', 'KullaniciController@index');

Route::post('/kullaniciler', 'KullaniciController@store');
```

The first example assigns a closure directly to a URL. The second and third point to a controller method. Compared to the old `switch/if` chain approach, this is vastly more readable.

## Controller

```php
<?php

class KullaniciController extends BaseController
{
    public function index()
    {
        $kullanicilar = User::all();
        return View::make('kullaniciler.liste', compact('kullanicilar'));
    }

    public function store()
    {
        $veri = Input::all();
        // validation and saving...
        return Redirect::to('/kullaniciler');
    }
}
```

`BaseController` is Laravel's base controller class. `View::make` returns a view file, `Input::all()` retrieves POST/GET data, and `Redirect::to` issues a redirect. All of these are static-like interfaces exposed through Laravel's **facade** layer.

## First impressions

A few things stood out to me:

**The facade pattern:** Static-looking calls like `DB::`, `Route::`, and `Input::` felt strange at first. These aren't real static classes — under the hood they're resolved from the service container. Fully grasping how that works took a few days.

**Configuration:** You manage database credentials in `app/config/database.php`. Environment-based configuration is built in, so you can maintain different values for development and production. In raw PHP I always had to wire this up myself.

**Artisan:** The command-line tool that ships with the framework. You can generate controllers, models, and other files with a single command:

```bash
php artisan controller:make KullaniciController
```

These small conveniences add up over time.

## How it differs from raw PHP

Using a framework comes with trade-offs: a learning curve, the obligation to follow the framework's conventions, and moving forward without always knowing what's happening underneath. For a first project, that curve is real. But escaping the repetitive setup work and gaining a consistent structure makes it worth it.

I'm now building a real project with Laravel 4. As I get to know each layer of the application, I'll continue this series.