HMVC: Pola berlapis untuk mengembangkan tingkatan klien yang kuat

Tugas merancang dan mengembangkan tingkat klien dari arsitektur Web n-tier sering kali menantang para pengembang. Hal ini terutama berlaku di dunia Web, di mana keragaman server, platform penerapan, dan protokol yang sangat beragam membuat tantangan menjadi memusingkan. Seorang arsitek tingkat klien harus menjawab sejumlah pertanyaan:

  • Bagaimana saya harus menyusun GUI saya?
  • Bagaimana pengguna berinteraksi dengan GUI saya?
  • Bagaimana cara memisahkan format data sisi server / transportasi dari GUI saya?
  • Bagaimana cara menyediakan mekanisme yang baik untuk manajemen acara, alur aplikasi, dan kontrol widget?

Untuk memahami beberapa masalah utama ini, kita harus membedakan antara lapisan presentasi (atau tingkat klien ) dan lapisan GUI . Lapisan GUI menangani sebagian kecil dari keseluruhan lapisan presentasi, yaitu widget UI dan efek langsung dari tindakan pengguna - a JTextFielddan ActionListener, misalnya. Lapisan presentasi perlu menangani aliran aplikasi dan interaksi server selain menyediakan layanan GUI. Istilah lapisan presentasi dan tingkat klien digunakan secara bergantian dalam artikel ini.

Pendekatan berbasis kerangka kerja

Untuk mengurangi risiko yang terkait dengan pembuatan tingkat klien yang kuat, pengembang telah menghasilkan beberapa kerangka kerja dan pola desain dengan berbagai tingkat keberhasilan. Paradigma Model-View-Controller (MVC) tetap menjadi salah satu pola yang bertahan lama. Namun, lingkup MVC tradisional gagal dalam hal kontrol elemen GUI (widget). MVC tidak menangani kerumitan manajemen data, manajemen acara, dan aliran aplikasi. Sebagai adaptasi dari triad MVC, paradigma HMVC - Hierarchical-Model-View-Controller - berusaha untuk memperbaiki beberapa masalah yang disebutkan di atas. Kami mengembangkan pola ini selama pekerjaan kami di lapangan. HMVC menyediakan metodologi desain berlapis yang kuat namun mudah dipahami untuk mengembangkan lapisan presentasi yang lengkap.Meskipun MVC menyediakan kerangka kerja yang efisien untuk mengembangkan interaksi GUI, HMVC menskalakannya ke seluruh tingkat klien. Beberapa manfaat utama dari arsitektur berlapis berbasis tanggung jawab meliputi:

  • Komunikasi intralayer yang ditentukan dan isolasi dari lapisan yang lebih tinggi
  • Komunikasi antar lapisan yang ditentukan dengan kopling minimal
  • Pelokalan eksposur ke kode pihak ketiga

Artikel ini membahas penerapan pola desain HMVC dalam pengembangan infrastruktur tingkat klien berbasis Java.

Catatan : Seluruh kode sumber untuk artikel ini dapat diunduh sebagai file zip dari bagian Sumberdaya di bawah.

Pengontrol tampilan model - MVC

Pengembang terutama menggunakan MVC di Smalltalk untuk mengimplementasikan objek GUI. Banyak pustaka kelas GUI dan kerangka kerja aplikasi telah menggunakan kembali dan mengadopsi pola tersebut. Karena paradigma MVC menawarkan cara yang elegan dan sederhana untuk memecahkan masalah terkait UI dengan cara yang berorientasi objek, popularitasnya dapat dibenarkan. MVC memberikan peran dan tanggung jawab yang jelas untuk tiga elemen penyusunnya - model, view, dan controller. The pandangan mengelola tata letak layar - yaitu, apa yang berinteraksi pengguna dengan dan melihat di layar. The Model mewakili data yang mendasari objek - misalnya, negara on-off dari kotak centang atau string teks dari kolom teks. Peristiwa menyebabkan data dalam model berubah. The kontroler menentukan bagaimana pengguna berinteraksi dengan tampilan dalam bentuk perintah.

MVC berlapis - HMVC

Pola HMVC menguraikan tingkat klien menjadi hierarki lapisan MVC induk-anak. Aplikasi berulang dari pola ini memungkinkan arsitektur tingkat klien terstruktur, seperti yang ditunjukkan pada Gambar 1.

Pendekatan MVC berlapis menyusun tingkat klien yang cukup kompleks. Beberapa manfaat utama menggunakan HMVC mengungkapkan manfaat orientasi objek. Arsitektur berlapis yang optimal:

  • Mengurangi ketergantungan antara bagian-bagian program yang berbeda
  • Mendorong penggunaan kembali kode, komponen, dan modul
  • Meningkatkan ekstensibilitas sekaligus memudahkan perawatan

Gunakan HMVC untuk mendesain arsitektur tingkat klien

Meskipun Anda mungkin merasa tugas itu menakutkan, Anda dapat secara efektif mengelola pengembangan lapisan presentasi untuk aplikasi dengan memasukkan pengembangan cerdas ke dalam strategi Anda - yaitu, dengan menggunakan pola yang kuat dan dapat diskalakan yang dapat mengurangi beberapa risiko dan memberikan fondasi desain siap pakai untuk membangun.

Ada tiga aspek utama pengembangan tingkat klien:

  • Kode tata letak GUI : Tata letak widget serta tampilan dan nuansa layar
  • Kode fitur GUI : Validasi dan pengambilan peristiwa pengguna
  • Kode logika aplikasi : Aliran aplikasi, navigasi, dan interaksi server

Pola desain HMVC mendorong dekomposisi tingkat klien menjadi lapisan yang dikembangkan dan berbeda untuk mengimplementasikan GUI dan layanan aplikasi. Sebuah arsitektur berbasis pola menghasilkan standardisasi; pola HMVC menstandarisasi lapisan presentasi (layanan pengguna) aplikasi Web. Standardisasi di lapisan presentasi membantu berkontribusi untuk:

  • Konsistensi UI : Kerangka kerja membagi entitas visual (tampilan) ke dalam panel dengan tanggung jawab dan fungsi yang spesifik dan konsisten.
  • Interaksi standar : Interaksi antara berbagai subkomponen dalam lapisan presentasi didefinisikan dengan jelas, menyediakan kelas dasar yang dapat disesuaikan.
  • Kode yang dapat dipelihara : Menggunakan pola menghasilkan kode yang dapat dipelihara yang menyediakan basis kode yang fleksibel dan dapat diperluas untuk mengembangkan aplikasi.
  • Dukungan aliran aplikasi: Kerangka kerja menyusun layanan presentasi ke dalam lapisan yang berbeda dan menyediakan komunikasi antar dan intralayer. Struktur seperti itu menawarkan cara yang kuat dan teratur untuk mengimplementasikan logika dan aliran aplikasi.

Prinsip desain

Pola HMVC memberikan gambaran yang jelas tentang tanggung jawab di antara berbagai komponen dan lapisan. Pola desain standar (Pabrik Abstrak, Komposit, Rantai Tanggung Jawab, Fasad, dll.) Dapat digunakan untuk memberikan desain yang stabil.

Gambar 2 mengilustrasikan beberapa lapisan dan komponen kunci dari pola HMVC. Lapisan horizontal menentukan hierarki dalam aplikasi; irisan vertikal mengacu pada komponen dari MVC triad. Dalam sebuah lapisan, pengontrol memiliki tanggung jawab keseluruhan untuk mengelola model dan komponen tampilan. Misalnya, GUIFrame Controller mengontrol GUIFrame Model dan GUIFrame (tampilan). Garis putus-putus antara model, pengontrol, dan tampilan dalam sebuah lapisan menandakan antarmuka yang jelas untuk komunikasi. Interaksi ini dicapai melalui AppEvents. Untuk komunikasi intralayer, hierarki pengontrol orang tua-anak ada, dan semua komunikasi intralayer hanya dapat dirutekan melalui jalur ini. Pengontrol berinteraksi melalui AppEvents.

Melihat

Seorang pengguna berinteraksi dengan tampilan, bagian aplikasi yang terlihat. HMVC mengabstraksi tampilan pada level yang berbeda untuk menyediakan metode yang bersih untuk mendesain GUI. Pada level tertinggi adalah GUIContainer, dengan pengontrol yang terkait. Kontainer pada dasarnya menyimpan beberapa tampilan yang berpotensi, yang disebut GUIFrame (s); setiap GUIFrame adalah entitas visual yang berinteraksi dengan pengguna. Kerangka kerja mendefinisikan GUIFrame sebagai terdiri dari beberapa subbagian - yaitu, GUIPane Menu, GUIPane Navigasi, GUIPane Status, dan GUIPane Konten pusat (lihat Gambar 3). Di sebagian besar aplikasi Web umum, pengembang biasanya mengharapkan beberapa GUIFrame tidak mungkin terjadi; terutama, itu adalah PANDUAN Konten yang perlu diubah. Area GUIPane Konten dianggap sebagai bagian terpenting dari GUIFrame; di situlah sebagian besar interaksi pengguna terjadi.Kerangka kerja ini mengasumsikan bahwa kontrol yang efisien dari beberapa GUIPanes Konten akan cukup untuk memberikan sebagian besar pengalaman pengguna.

Gambar 3 mengilustrasikan frontend GUI yang khas. Itu pecah menjadi beberapa bagian (yaitu, GUIPanes). Kita dapat menerapkan triad MVC ke setiap panel penulisan dan menetapkan hierarki, dengan GUIFrame yang terdiri dari Menu, Status, Nav, dan GUIPanes Konten. Bergantung pada kompleksitas kode dalam setiap komponen, kami mungkin atau mungkin tidak menetapkan kontroler dan model independen ke GUIPane. Misalnya, karena kesederhanaannya dan kurangnya kebutuhan nyata untuk kontrol canggih, Status GUIPane tidak perlu memiliki pengontrol sendiri; kita dapat memilih agar pengontrol GUIFrame menjalankan Status GUIPane sebagai gantinya. Namun, karena GUIPane Konten adalah area aktivitas penting, kami mungkin menetapkannya sebagai pengontrol dan model terpisah. Berdasarkan triad MVC, GUIFrame memiliki model pengontrol dan pemegang data yang terkait,seperti halnya GUIPane Konten. Lapisan GUIFrame memiliki GUIContainer sebagai triad induknya. GUIContainer adalah bagian tak terlihat dari arsitektur; itu berpotensi menampung beberapa GUIFrame.

Aspek penting dari desain adalah isolasi kode khusus Swing - yaitu, komponen Swing dan pendengarnya (lihat kembali Gambar 2) - dalam anak tangga terendah dari hierarki. Sebagai gambaran, widget Swing terutama menyusun PANDUAN Konten. Ini bukan batasan desain; Nav GUIPane juga dapat memiliki komponen Swing seperti, misalnya, a JTree. Oleh karena itu, GUIPane Konten juga bertanggung jawab untuk melayani acara Swing seperti ActionEvents. Demikian pula, suara yang ActionEventdihasilkan dengan mengklik a JMenuItemdalam Menu GUIPane akan terdengar oleh Menu GUIPane itu sendiri. Jadi, GUIPane bertindak sebagai pendengar acara Swing. GUIPane yang terpengaruh selanjutnya dapat meminta layanan lebih lanjut dari pengontrolnya dengan menggunakan peristiwa tingkat aplikasi. Ini memungkinkan pelokalan kode khusus Swing.

Kontroler

Pengontrol menggunakan model untuk mengoordinasikan efek peristiwa pengguna pada tampilan dengan model; itu juga melayani aliran logika. HMVC mendefinisikan lapisan dalam GUI dan menyediakan kontrol peristiwa yang didistribusikan melalui hierarki pengontrol induk-anak. Dalam sebuah lapisan, pengontrol adalah komandan tertinggi, yang mengatur aliran aplikasi dan respons peristiwa pengguna. Pola desain Rantai Tanggung Jawab menerapkan pengontrol, di mana mereka meneruskan peristiwa yang tidak dapat mereka penuhi.

Misalnya, jika, sebagai hasil dari mengklik tombol dalam GUIPane Konten, Menu GUIPane perlu diubah, maka GUIPane ActionEventakan dicegat oleh GUIPane Konten itu sendiri (karena ini adalah pendengar untuk acara Swing / AWT). ContentGUIPane selanjutnya akan membuat permintaan navigasi ke pengontrol ContentGUIPane, yang akan, pada gilirannya, meneruskannya ke pengontrol induknya, pengontrol GUIFrame. Ini terjadi karena perubahan dalam GUIPane Menu hanya dapat dilakukan pada level yang lebih tinggi, karena GUIPane Konten dan GUIPane Menu berada pada level yang sama dalam hierarki (keduanya terdapat dalam GUIFrame).

Hubungan orang tua-anak

Hubungan induk-anak yang absolut dan didefinisikan dengan jelas dibuat antara pengontrol GUIContainer di tingkat paling atas, atau induk, dan anaknya, pengontrol GUIFrame. Demikian pula, ada hubungan induk-anak antara pengontrol GUIFrame dan pengontrol GUIContent Pane. Pengontrol dalam setiap lapisan hanya bertanggung jawab atas tindakan yang terbatas pada lingkup pengaruhnya - yaitu, model dan tampilan di tingkat tersebut. Untuk semua layanan lainnya, pengontrol perlu meneruskan tindakan ke induknya.

Komunikasi

Jika pengontrol tidak dapat menangani kejadiannya, pola Rantai Tanggung Jawab memberi sinyal kepada pengontrol untuk meneruskan kejadian ke induknya. Pengontrol berkomunikasi satu sama lain melalui AppEvents- yang biasanya dapat berupa peristiwa navigasi, peristiwa permintaan data, atau peristiwa status. Peristiwa navigasi biasanya adalah peristiwa yang mengubah tampilan dan nuansa tampilan. Misalnya, jika Anda mengklik JMenuItemdalam GUIPane Menu - yang menggantikan GUIPane Konten aktif - acara navigasi akan membuat perubahan. Pengembang aplikasi perlu mengidentifikasi peristiwa ini dan membuat beberapa stereotip dasar.

Pengontrol juga dapat berkomunikasi melalui peristiwa data. Jika GUIPane Konten perlu menampilkan data di beberapa JTextFieldobjek, maka GUIPane Konten akan membuat peristiwa data. GUIPane Konten kemudian akan meneruskannya ke pengontrolnya, yang, setelah menentukan bahwa itu adalah peristiwa data, akan mendelegasikannya ke model terkait. Model selanjutnya akan meneruskan permintaan penyegaran ke Content GUIPane, yang akan memberikan jalur komunikasi yang bersih dan terdefinisi dengan baik.

Tanggung jawab

Pengendali memiliki banyak tanggung jawab; ia harus merespons peristiwa navigasi tingkat aplikasi dan peristiwa permintaan data, misalnya. Menanggapi peristiwa navigasi, pengontrol menyediakan logika aliran aplikasi - mengubah layar atau menonaktifkan / mengaktifkan opsi, misalnya. Untuk peristiwa permintaan data, pengontrol mendelegasikan permintaan ke objek model terkait.

Model

Lihat entitas seperti GUIContainer, GUIFrame (s), dan GUIContent Pane (s) memiliki model terkait. HMVC membuat ketentuan untuk model di setiap lapisan hierarki, namun terserah desainer aplikasi untuk benar-benar menerapkannya. Model GUIFrame biasanya berisi data atau informasi yang mempengaruhi seluruh aplikasi, sedangkan model GUIFrame berisi informasi yang hanya terkait dengan status GUIFrame. Model berisi atau menyimpan objek data yang akan ditampilkan atau dikerjakan dalam tampilan. Biasanya, model menerima permintaan layanan data yang didelegasikan dari pengontrol, mengambil data, dan memberi tahu tampilan terkait tentang ketersediaan data baru.