2. Web/PHP ortamında MVC geliştirme yaklaşımı

Burada, MVC mimarisine uygun web/PHP uygulamaları geliştirmek için bir yaklaşım öneriyoruz. Bu yaklaşım sadece yeni yollar açmak amacıyla sunulmuştur. Okuyucu, bunu kendi zevklerine ve ihtiyaçlarına göre uyarlayacaktır.

İlk olarak, uygulamanın tüm görünümlerini tanımlayacağız. Bunlar, kullanıcıya sunulan web sayfalarıdır. Görünümleri tasarlarken kendimizi kullanıcının yerine koyacağız. Üç tür görünüm ayırt edilir:
- Kullanıcıdan bilgi toplamayı amaçlayan giriş formu. Bu formda genellikle girilen bilgileri sunucuya göndermek için bir düğme bulunur.
- Yalnızca kullanıcıya bilgi vermek amacıyla kullanılan yanıt sayfası. Bu sayfada genellikle kullanıcının uygulamaya başka bir sayfayla devam etmesini sağlayan bir veya daha fazla bağlantı bulunur.
- karma sayfa: denetleyici, oluşturduğu bilgileri içeren bir sayfayı istemciye göndermiştir. Aynı sayfa, istemcinin kullanıcıdan gelen yeni bilgileri denetleyiciye iletmesi için kullanılacaktır.

Her görünüm, PHP adlı bir sayfa oluşturacaktır. Bunların her biri için:
- sayfanın görünümünü tasarlayacağız
- sayfanın hangi kısımlarının dinamik olduğunu belirleyeceğiz:
  - kullanıcıya yönelik bilgiler, denetleyici tarafından PHP görünümüne parametreler olarak sağlanmalıdır. Basit bir çözüm şöyledir:
    - denetleyici, bir V görünümüne sağlamak istediği bilgileri $dReponse sözlüğüne yerleştirir
    - kontrolör, V görünümünü görüntületir. Bu görünüm, V.php kaynak dosyasına karşılık geliyorsa, bu görüntüleme basitçe include V.php komutuyla elde edilir.
    - Yukarıdaki dahil etme işlemi, denetleyicideki bir kodun dahil edilmesidir. Denetleyici tarafından doldurulan $dReponse sözlüğüne, V.php kodundan doğrudan erişilebilir.
  - İşlenmek üzere ana programa iletilmesi gereken giriş verileri. Bu veriler, bir HTML formunun parçası olmalıdır (<form> etiketi).

Her bir görünümün G/Ç işlemlerini şematik olarak gösterebiliriz

Girişler, denetleyicinin PHP sayfasına sağlaması gereken verilerdir
Çıkışlar, PHP sayfasının uygulama denetleyicisine sağlaması gereken verilerdir. Bunlar HTML formunun bir parçasıdır ve denetleyici bunları $_GET["param"] (GET yöntemi) veya $_POST["param"] (POST yöntemi) türündeki bir işlemle alacaktır.

Çoğu zaman, müşteriye gönderilen son sayfa tek bir görünüm değil, birden fazla görünümün birleşimidir. Örneğin, bir kullanıcıya gönderilen sayfa şu şekilde olabilir:

1 numaralı alan bir başlık şeridi, 2 numaralı alan bir menü şeridi, 3 numaralı alan ise bir içerik alanı olabilir. PHP'te bu bileşim, aşağıdaki HTML/PHP kodu ile elde edilebilir:

<table>
    <tr>
        <td><?php include zone1.php ?></td>
    </tr>
    <tr>
        <td><?php include zone2.php ?></td>
        <td><?php include zone3.php ?></td>
    </tr>
</table>

Aşağıdaki şekilde yazarak bu kodu dinamik hale getirebiliriz:

<table>
    <tr>
        <td><?php include $dReponse['urlZone1'] ?></td>
    </tr>
    <tr>
        <td><?php include $dReponse['urlZone2'] ?></td>
        <td><?php include $dReponse['urlZone3'] ?></td>
    </tr>
</table>

Bu görünüm bileşimi, kullanıcıya verilen yanıtın tek formatı olabilir. Bu durumda, müşteriye verilen her yanıt, yanıt sayfasını görüntülemeden önce üç alana yüklenecek üç URL'i belirlemelidir. Yanıt sayfası için birkaç olası şablon olduğunu varsayarak bu örneği genelleştirebiliriz. Dolayısıyla, müşteriye verilen yanıt:

kullanılacak şablonu belirlemeli
bu şablona dahil edilecek öğeleri belirlemeli
şablonun görüntülenmesini talep etmelidir

Her yanıt şablonu için PHP/HTML kodunu yazacağız. Bu kod genellikle basittir. Yukarıdaki örnekteki kod şöyle olabilir:

<?php
    // kontrolörsüz testler için başlatma işlemleri
...
?>
<html>
    <head>
      <title><?php echo $dReponse['titre'] ?></title>
      <link type="text/css" href="<?php echo $dReponse['style']['url'] ?>" rel="stylesheet" />    
    </head>
  <body>      
    <table>
        <tr>
            <td><?php include $dReponse['urlZone1'] ?></td>
        </tr>
        <tr>
            <td><?php include $dReponse['urlZone2'] ?></td>
            <td><?php include $dReponse['urlZone3'] ?></td>
        </tr>
    </table>
  <body>
</html>

Mümkün olduğunca her seferinde bir stil sayfası kullanılarak, PHP/HTML kodunu değiştirmeye gerek kalmadan yanıtın "görünümü" değiştirilebilecektir.

Her bir temel görünümün PHP/HTML kodunu yazacağız. Bu kod genellikle şu şekilde olacaktır:

<?php
     // gerekirse, özellikle hata ayıklama aşamasında bazı başlatma işlemleri
    ...
?>

<balise>
...
         // burada PHP kodunu en aza indirmeye çalışacağız
</balise>

Bir temel görünümün bir modele entegre edildiği unutulmamalıdır. HTML kod numarası, modelin kodunun içine entegre edilir. Çoğu zaman, modelin kodu zaten <html>, <head> ve <body> etiketlerini içerir. Dolayısıyla, bu etiketlerin bir temel görünümde bulunması pek yaygın değildir.

Farklı yanıt şablonları ve temel görünümler üzerinde testler yapılabilir

Her yanıt şablonu test edilir. Bir şablonun adı modele1.php ise, bir tarayıcıyla URL adresine http://localhost/chemin/modele1.php şeklinde erişilir. Şablon, denetleyiciden değerler bekler. Burada model, denetleyici aracılığıyla değil, doğrudan çağrılmaktadır. Model, beklenen parametreleri almayacaktır. Yine de testlerin yapılabilmesi için, modelin PHP sayfasında beklenen parametreleri sabit değerlerle kendimiz başlatacağız.
Her model ve tüm temel görünümler bu şekilde test edilir. Ayrıca, kullanılacak stil sayfalarının ilk öğelerini hazırlamanın da tam zamanıdır.

Ardından uygulamanın iş mantığını yazıyoruz:

Denetleyici veya ana program genellikle birden fazla eylemi yönetir. Kendisine gelen isteklerde gerçekleştirilecek eylemin tanımlanmış olması gerekir. Bu, burada "eylem" olarak adlandıracağımız bir istek parametresi aracılığıyla yapılabilir:
- İstek bir formdan geliyorsa (<form>), bu parametre formun gizli bir parametresi olabilir:

<form ... action="/C/main.php" method="post"  ...>
<input type="hidden" name="action" value="uneAction">
...
</form>

(devamı)
- istek bir bağlantıdan geliyorsa, bu bağlantı için ayar yapılabilir:

 <a href="/C/main.php?action=uneAction">lien</a>

Denetleyici, önce bu parametrenin değerini okuyabilir, ardından isteğin işlenmesini bu tür istekleri işlemekten sorumlu bir modüle devredebilir. Burada, her şeyin main.php adlı tek bir komut dosyası tarafından kontrol edildiği durumu ele aldık. Uygulamanın action1, action2, ..., actionx eylemlerini işlemesi gerekiyorsa, denetleyici içinde her eylem için bir işlev oluşturulabilir. Çok sayıda eylem varsa, denetleyici “dinozor” haline gelebilir. Ayrıca, her bir eylemi işlemekle görevli action1.php, action2.php, ...,actionx.php gibi her bir eylemi işlemekle görevli komut dosyaları da oluşturulabilir. actionx eylemini işlemesi gereken denetleyici, "include "actionx.php" gibi bir komutla ilgili komut dosyasının kodunu yüklemekle yetinecektir. Bu yöntemin avantajı, denetleyici kodunun dışında çalışılabilmesidir. Böylelikle geliştirme ekibindeki her üye, actionx eyleminin işleme komut dosyası üzerinde nispeten bağımsız bir şekilde çalışabilir. Yürütme sırasında actionx.php komut dosyasının kodunun denetleyici koduna dahil edilmesi, belleğe yüklenen kodun boyutunu azaltma avantajı da sağlar. Yalnızca o anda işlenmekte olan eylemin işleme kodu yüklenir. Bu kod dahil etme işlemi, denetleyicinin değişkenlerinin eylem betiğindeki değişkenlerle çakışmasına neden olabilir. Göreceğiz ki, denetleyicinin değişkenlerini iyi tanımlanmış birkaç değişkenle sınırlayabiliriz; bu durumda bu değişkenlerin betiklerde kullanılmasından kaçınılmalıdır.

İş mantığı kodunu veya kalıcı verilere erişim kodunu her zaman ayrı modüllerde izole etmeye çalışacağız. Denetleyici, müşterilerinden (web istemcileri) talepler alan ve bunları en uygun kişiler (iş mantığı modülleri) tarafından yürütülmesini sağlayan bir tür ekip lideridir. Denetleyiciyi yazarken, yazılması gereken iş modüllerinin arayüzünü belirleyeceğiz. Tabii bu iş modülleri henüz oluşturulmamışsa. Zaten mevcutsa, denetleyici mevcut modüllerin arayüzüne uyum sağlayacaktır.

Denetleyici için gerekli iş modüllerinin iskeletini yazacağız. Örneğin, denetleyici bir karakter dizisi tablosu döndüren getCodes modülünü kullanıyorsa, ilk etapta şunu yazmak yeterli olabilir:

function getCodes(){
    return array("code1","code2","code3");
}

Ardından, denetleyici ve ilgili PHP komut dosyalarının testlerine geçilebilir:

kontrolör, eylem komut dosyaları, modeller, görünümler ve uygulama için gerekli kaynaklar (resimler vb.) uygulamanın C bağlamıyla ilişkili DC klasörüne yerleştirilir.
Bu işlem tamamlandıktan sonra uygulama test edilir ve ilk hatalar düzeltilir. main.php denetleyici ve C uygulama bağlamı ise, URL http://localhost/C/main.php adresi çağrılır. Bu aşamanın sonunda, uygulama mimarisi çalışır hale gelir. Gelişmiş ve genellikle ücretli geliştirme ortamları kullanılmadığında hata ayıklama araçlarının sınırlı olduğu göz önüne alındığında, bu test aşaması zorlu olabilir. Müşteriye gönderilen HTML akışına yazan ve dolayısıyla tarayıcı tarafından görüntülenen web sayfasında görünen echo "mesaj" komutlarından yararlanılabilir.

Son olarak, denetleyicinin ihtiyaç duyduğu iş sınıfları yazılır. Burada genellikle, çoğu zaman herhangi bir web uygulamasından bağımsız olan klasik bir PHP sınıfı geliştirilir. Bu sınıf öncelikle bu ortamın dışında, örneğin bir konsol uygulaması ile test edilir. Bir iş sınıfı yazıldıktan sonra, bu sınıf web uygulamasının dağıtım mimarisine entegre edilir ve doğru bir şekilde entegre olup olmadığı test edilir. Her iş sınıfı için bu işlem tekrarlanır.