Framework Design Guidelines Bagian 07 – Prinsip #4: Layered Architecture

Masing-masing developer mempunyai masalahnya sendiri-sendiri yang harus diselesaikan. Mereka masing-masing membutuhkan level abstraksi serta kontrol dari framework yang berbeda-beda sesuai dengan masalah yang dihadapi. Developer yang biasanya menggunakan C++ atau C# pada umumnya menginginkan low level API yang tangguh dan ekspresif. Sementara developer yang biasanya menggunakan C# atau VB.NET pada umumnya menginginkan high level API yang dioptimasi untuk kesederhanaan penggunaan serta peningkatan produktivitas.

Agar sebuah framework bisa digunakan oleh berbagai tipe developer, maka kita harus membaginya menjadi low level API yang menekankan pada kekuatan serta kemampuan mengekspresikan berbagai macam detail operasi, serta high level API yang membungkus low level API ke dalam abstraksi yang lebih tinggi dan API yang lebih sederhana.

ASP.NET (pada namespace System.Web) merupakan contoh framework yang didesain berdasarkan layer. Sebagai ilustrasi, jika kita ingin membuat sebuah halaman web seperti tampak pada gambar berikut,

 

Kita bisa melakukannya dengan dua cara. Yang pertama adalah dengan memprogram pada low level API, yaitu dengan mengakses langsung HTTP Request seperti tampak pada kode di bawah:

if (Request.Form[“btnSubmit”] != “”)

{

    string name = Request.Form[“txtName”];

    string nilai = Request.Form[“txtNilai”];

    Response.Write(“Halo “ + nama + “. Nilai Anda: “ + nilai);

}

 

 

 

Namun kita juga bisa membuatnya pada level abstraksi yang lebih tinggi yaitu menggunakan web control milik ASP.NET yang menyederhanankan object model dengan menyediakan property, method, maupun event tanpa mengharuskan developer mengetahui tentang HTTP Request, HTTP Header, dll. Berikut ini adalah contoh kode untuk membuat halaman web di atas dalam abstraksi yang lebih tinggi menggunakan event
Button Click:

protected void btnSubmit_Click(object sender, EventArgs e)

{

    Label1.Text = “Halo “ + txtName.Text + “. Nilai Anda: “ + txtNilai.Text;

}

 

 

 

Ada dua pendekatan dalam menerapkan prinsip Layered Architecture, yaitu :

• Menempatkan masing-masing layer dalam namespace yang berbeda
  

  Cara ini bisa dilihat misalnya pada ASP.NET dimana ia menempatkan low level API (misalnya kelas HttpRequest) di dalam namespace System.Web, sementara high level API (misalnya kelas Page) yang ditujukan untuk skenario utama ditempatkan di namespace yang berbeda, yaitu System.Web.UI. Cara ini mempunyai keuntungan yaitu namespace akan lebih “bersih” sehingga ketika developer sedang memprogram pada skenario utama, ia tidak terganggu dengan entity-entity yang digunakan pada skenario yang lebih kompleks.

   

• Menempatkan layer-layer tersebut dalam namespace yang sama.
  

  Cara ini mempunyai kelebihan yaitu developer tidak perlu mengimport namespace lain untuk mengerjakan skenario yang paling sederhana sampai skenario yang paling kompleks. Namun kekurangannya adalah jika entity-entity yang terdapat di dalam namespace tersebut sangat banyak, maka namespace tersebut akan terlihat “kotor” karena entity-entity untuk skenario utama saling bercampur aduk dengan entity-entity untuk skenario yang kompleks. Jadi di sini perlu kita pertimbangkan jumlah entity yang terlibat. Jika tidak terlalu banyak, maka tidak menjadi masalah jika layer-layer yang ada kita satukan dalam namespace yang sama untuk mempermudah developer.

Berikut ini adalah panduan untuk prisip Layered Architecture:

Pertimbangkan:
untuk membagi arsitektur framework ke dalam layer yang berisi high level API (dioptimasi untuk kesederhanaan dan produktivitas) dan layer yang berisi low level API (dioptimasi untuk kekuatan serta kemampuan mengekspresikan berbagai macam detail operasi).

Hindari:
menyatukan low level dan high level API di dalam sebuah namespace jika low level API sangat kompleks.

Lakukan:
Pastikan bahwa layer-layer yang ada terintegrasi dengan baik. Jika semua layer terintegrasi dengan baik, maka ketika developer ingin berpindah ke skenario yang lebih kompleks dan menggunakan layer yang berbeda, kode sebelumnya yang dibuat tetap bisa terintegrasi dengan skenario yang baru.