Pola desain membuat aplikasi J2EE menjadi lebih baik

Sejak awal, J2EE (Java 2 Platform, Enterprise Edition) telah menyederhanakan konstruksi aplikasi perusahaan di Java. Karena J2EE menjadi lebih luas diadopsi, bagaimanapun, pengembang menyadari kebutuhan untuk pendekatan yang didefinisikan yang menyederhanakan dan menstandarisasi pembangunan aplikasi. Anda dapat mulai mencapai tujuan itu dengan menstandarkan lapisan arsitektur aplikasi Anda .

Lapisan arsitektural umumnya merangkum kompleksitas teknis aplikasi yang tidak bergantung pada logika bisnis, sehingga memberikan kopling longgar antara fungsionalitas bisnis dan infrastruktur teknis yang mendasarinya. Dalam artikel ini, saya menjelaskan metode yang muncul untuk membangun arsitektur aplikasi untuk proyek J2EE — metode yang menggunakan pola desain untuk memberikan standarisasi dan kesederhanaan yang dibutuhkan oleh arsitektur yang baik.

Arsitektur aplikasi dan J2EE

J2EE adalah teknologi infrastruktur yang hebat. Ini memberikan standar seragam untuk tugas-tugas tingkat bawah tumpukan teknologi, seperti komunikasi database atau distribusi aplikasi. Namun, J2EE tidak mengarahkan pengembang untuk membangun aplikasi yang berhasil. Pencipta J2EE, melihat ke tumpukan teknologi, bertanya-tanya: "Bagaimana kami dapat menstandarkan API ini?" Mereka seharusnya melihat ke pengembang aplikasi dan bertanya: "Bagaimana saya bisa memberi pengembang blok bangunan yang mereka butuhkan untuk fokus pada aplikasi bisnis mereka?"

Saat memulai proyek J2EE baru, beberapa anggota tim sering bertanya: "Jika J2EE itu sendiri adalah arsitektur, mengapa kita membutuhkan lebih banyak?" Banyak pengembang memegang kesalahpahaman itu di masa-masa awal J2EE, tetapi pengembang J2EE yang berpengalaman memahami bahwa J2EE gagal menyediakan arsitektur aplikasi yang diperlukan untuk secara konsisten memberikan aplikasi berkualitas tinggi. Pengembang ini sering menggunakan pola desain untuk mengisi celah itu.

Pola desain

Dalam pemrograman, pola desain memungkinkan Anda memanfaatkan pengalaman kolektif komunitas pengembang dengan berbagi masalah dan solusi yang menguntungkan semua orang. Pola desain harus menangkap definisi dan konteks masalah, solusi yang mungkin, dan konsekuensi solusi.

Untuk keperluan arsitektur aplikasi J2EE, pola desain terbagi dalam dua kategori: pola pengembangan perangkat lunak umum dan pola yang mengidentifikasi tantangan J2EE tertentu. Pola desain khusus J2EE mengidentifikasi rangkaian minimal masalah yang diketahui yang harus diselesaikan oleh arsitektur aplikasi yang solid. Kelompok pertama, yaitu pola pengembangan perangkat lunak yang tidak spesifik untuk J2EE, terbukti sama kuatnya — bukan untuk mengidentifikasi masalah, tetapi untuk memandu konstruksi arsitektur.

Mari kita periksa setiap area secara lebih rinci.

Pola desain J2EE

Pola desain J2EE telah berkembang selama beberapa tahun terakhir karena komunitas Java telah memperoleh pengalaman J2EE. Pola desain ini mengidentifikasi masalah potensial yang dihadapi saat menggunakan berbagai teknologi yang ditentukan J2EE dan membantu pengembang membangun persyaratan arsitektur aplikasi. Pola desain Pengontrol Depan yang populer, misalnya, mengubah kode servlet yang tidak terstruktur menjadi pengontrol yang mengingatkan pada pengembangan GUI (antarmuka pengguna grafis) yang disempurnakan.

Pola desain J2EE mengidentifikasi masalah domain yang paling mungkin muncul di proyek J2EE Anda. Memang, jika masalah jarang terjadi, pola desain tidak akan berkembang untuk memenuhinya. Dengan pemikiran tersebut, Anda akan mendapatkan keuntungan dari menangani setiap masalah domain dalam arsitektur Anda. Untuk menyelesaikan semuanya, buat daftar periksa untuk memvalidasi arsitektur Anda untuk kelengkapan. Proses tersebut kontras dengan proses pola desain pengembangan perangkat lunak yang akan saya bahas selanjutnya, karena Anda perlu menerapkan pola tersebut hanya jika dan jika sesuai.

Jadi di mana Anda menemukan pola desain J2EE? Sun Microsystems menawarkan dua buku yang berisi banyak pola J2EE:

  • The J2EE BluePrint Group's Designing Enterprise Applications dengan Java 2 Platform (Enterprise Edition), Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
  • Pola Inti J2EE Grup Layanan Profesional Sun : Praktik Terbaik dan Strategi Desain, Deepak Alur, John Crupi, dan Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Lihat Sumberdaya untuk link ke kedua buku.)

Di luar sumber daya Sun, publikasi lain menawarkan informasi pola desain J2EE, termasuk berbagai majalah atau Situs Web industri Java (seperti JavaWorld ), serta banyak buku. (Lihat Sumber daya untuk link ke beberapa situs, termasuk JavaWorld' s Pola Desain halaman Topical Index.)

Pola desain pengembangan perangkat lunak

Ketahuilah juga pola desain pengembangan perangkat lunak, bagi menjadi pola desain berorientasi objek (OO) umum dan pola desain khusus Java. Pola Pabrik, misalnya, mewakili pola desain OO yang kuat untuk merangkum pembuatan objek agar dapat digunakan kembali dan memenuhi persyaratan sistem yang berubah. Untuk bagian mereka, pola desain bahasa Java memperhitungkan spesifikasi bahasa Java. Beberapa unik untuk Java dan biasanya informal (misalnya, pengecualian dan primitif), sementara yang lain adalah pola OO yang disempurnakan untuk diterapkan ke Java. Buku Gang of Four yang terkenal, Design Patterns oleh Eric Gamma et al., Merinci banyak pola pengembangan perangkat lunak umum yang berguna untuk semua pemrogram.

Jangan abaikan pola ini hanya karena tidak spesifik untuk J2EE. Sebaliknya, pola seperti itu terbukti sama kuatnya, jika tidak lebih, daripada pola desain J2EE, karena:

  • Sementara pola desain J2EE masih baru dan berkembang (karena J2EE baru dan berkembang), pola lain mendapatkan keuntungan dari usia, karena industri memiliki lebih banyak waktu untuk meninjau dan menyempurnakannya.
  • Mereka sering menjadi dasar dari mana pola desain J2EE berasal.
  • Mereka membangun fondasi di mana solusi khusus J2EE diimplementasikan. Membangun fondasi ini dengan benar secara luas memengaruhi ketahanan dan ekstensibilitas arsitektur secara keseluruhan. Jika tidak dibangun dengan benar, fondasi akan meminimalkan kegunaan arsitektur terlepas dari berapa banyak masalah J2EE yang dipecahkannya.

Jangan membuat daftar periksa yang mencakup pola pengembangan perangkat lunak yang dibutuhkan arsitektur Anda, seperti yang Anda lakukan dengan pola J2EE. Alih-alih, terapkan pola seperti itu jika sesuai berdasarkan tantangan spesifik proyek Anda. Banyak pengembang secara keliru percaya bahwa produk mereka akan meningkat jika mereka menggunakan lebih banyak pola — atau jika mereka menggunakan semuanya! Namun, bukan itu masalahnya. Gunakan kebijaksanaan dan kemahiran saat memutuskan pola mana yang akan diterapkan dan bagaimana menggunakannya bersama.

Pola desain: Di mana kodenya?

Ingatlah bahwa pola desain tidak disertai dengan implementasi yang tepat, atau kode sumber, yang akan Anda gunakan. Penawaran pola desain berkisar dari deskripsi tekstual yang jarang hingga dokumentasi yang kaya hingga mungkin beberapa kode contoh. Tantangannya datang dalam menerapkan ide-ide kuat pola tersebut. Ide-ide ini harus diterapkan pada lingkungan di mana mereka akan digunakan; lingkungan menentukan implementasi yang benar.

Sebagai analogi, pertimbangkan pola desain untuk membangun fondasi rumah. Pola desain mengidentifikasi masalah, konteks, dan kemungkinan solusi untuk membangun fondasi — informasi yang sangat berharga bagi pekerja konstruksi di lapangan. Namun, pekerja harus tetap membangun fondasi. Bukankah pekerja konstruksi itu mendapat manfaat lebih dari diberi yayasan (mirip dengan pengembang perangkat lunak yang diberikan implementasinya)? Mungkin fondasi ini hanya berupa lempengan beton tempat rumah itu bisa dibangun. Masalahnya: Fondasi harus menyatu dengan rumah itu sendiri dan tanah tempat tinggal rumah tersebut. Bagaimana pondasi prebuilt seperti itu dapat menampung semua kemungkinan denah rumah (persegi panjang, persegi, dan bentuk aneh lainnya) dan semua lanskap yang mungkin (di atas bukit,di tengah hutan, dan sebagainya)?

Kembali ke dunia perangkat lunak, kemungkinan menggunakan pola desain prebuilt bergantung pada dua faktor:

  • Implementasinya, bukan pola desain individu, merupakan solusi. Solusinya dapat menggabungkan beberapa pola desain, dan, dalam melakukannya, akan mengetahui bagaimana pola desain individu bermain bersama.
  • Solusinya harus dapat beradaptasi, yang menjawab pertanyaan terakhir dari analogi fondasi prebuilt: fondasi harus mampu beradaptasi dengan medan dan denah lantai. Seperti yang dapat Anda bayangkan, akan dibutuhkan pengrajin yang sangat terampil untuk membangun fondasi yang dapat disesuaikan, bukan fondasi standar.

Pola desain umum

Tabel di bawah mencantumkan beberapa pola desain umum dari sumber J2EE dan pola OO yang lebih luas.

Pola desain umum
Pola desain J2EE Pola pengembangan perangkat lunak
Fasad Sesi Singleton
Value Object Assembler Jembatan
Pola Pencari Layanan Prototipe
Delegasi Bisnis Pabrik Abstrak
Entitas Gabungan Kelas terbang
Penangan Daftar Nilai Penengah
Lokasi Layanan Strategi
Entitas Gabungan Penghias
Objek Nilai Negara
Layanan untuk Pekerja Iterator
Objek Akses Data Rantai Tanggung Jawab
Filter Mencegat Model View Controller II
Lihat Helper Memento
Tampilan Komposit Pembangun
Tampilan Operator Metode Pabrik

Mari kita lihat dua contoh pola desain J2EE: Session Facade dan pola Value Object. Keduanya menunjukkan bagaimana pola desain J2EE fokus pada masalah khusus untuk lingkungan J2EE, yang bertentangan dengan pola desain pengembangan perangkat lunak yang umumnya berlaku untuk setiap upaya pengembangan aplikasi.

Contoh: Pola J2EE Fasad Sesi

Pola Sesi Fasad berevolusi dari pengalaman dengan Enterprise JavaBeans (EJBs). Sistem yang dibangun di atas entitas EJB yang baru diperkenalkan (yang berkomunikasi dengan database) melambat hingga merayapi. Pengujian kinerja mengungkapkan masalah yang berasal dari beberapa panggilan jaringan yang dilakukan saat berkomunikasi dengan entitas EJB, yang menambahkan overhead untuk membuat koneksi jaringan, membuat serial data untuk pengiriman dan penerimaan, dan efek lainnya.

Sebagai tanggapan, pola Sesi Fasad meningkatkan kinerja dengan memusatkan beberapa klik jaringan ke dalam satu panggilan. Sesi Fasad menggunakan sesi EJB stateless untuk menengahi antara panggilan klien dan interaksi EJB entitas yang diperlukan. Ada lebih banyak pola untuk meningkatkan kinerja akses database, termasuk pola Fast Lane Reader dan Data Access Object.

Contoh: Pola Value Object J2EE

Pola Value Object J2EE juga bertujuan untuk meningkatkan kinerja sistem yang menggunakan EJB melalui jaringan. Panggilan jaringan yang menyebabkan overhead tersebut dari contoh sebelumnya mengambil bidang data individual. Misalnya, Anda mungkin memiliki Personentitas EJB dengan metode seperti getFirstName(), getMiddleName(), dan getLastName(). Dengan pola desain Value Object, Anda dapat mengurangi beberapa panggilan jaringan menjadi satu panggilan dengan metode pada entitas EJB, seperti getPersonValueObject(), yang mengembalikan data sekaligus. Objek nilai tersebut berisi data yang diwakili oleh entitas EJB dan dapat diakses sesuai kebutuhan tanpa menimbulkan overhead panggilan jaringan.

Contoh: Pola OO Kelas Terbang

Untuk contoh pola desain OO yang dapat diterapkan secara luas, pertimbangkan pola Kelas Terbang, yang meningkatkan kinerja aplikasi melalui penggunaan ulang objek. Perangkat lunak OO menghasilkan overhead — siklus CPU yang terbuang, pengumpulan sampah, dan alokasi memori — saat membuat dan menghancurkan objek. Jika sistem dapat menggunakan kembali objek tersebut, Anda dapat menghindari overhead tersebut. Objek sering kali tidak dapat digunakan kembali, karena berisi informasi (disebut status ) khusus untuk pengguna objek saat ini. Pola Kelas Terbang memberikan pendekatan untuk memindahkan status tersebut ke tempat lain sehingga sisa objek dapat digunakan kembali.

Gabungkan semuanya: Contoh ketekunan

Sekarang setelah Anda mengetahui dasar-dasarnya, Anda dapat mulai menerapkan pola desain dalam praktik pengembangan Anda. Tapi bagaimana Anda sebenarnya menggunakan pola? Mulailah dengan mengidentifikasi domain atau masalah teknis yang membutuhkan solusi. Persistence — memecahkan ketidakcocokan database objek-ke-relasional yang lama — merupakan contoh yang baik untuk sebagian besar aplikasi perusahaan. Mari kita lihat langkah-langkah yang diperlukan untuk merancang dan membangun lapisan persistensi arsitektur aplikasi.

Mengikuti pendekatan arsitektur dan desain OO tradisional, buat kasus penggunaan yang menjelaskan kebutuhan persistensi Anda. Kasus penggunaan yang mungkin termasuk:

  1. Ketahanan objek harus transparan dari sudut pandang pengembang.
  2. Mekanisme persistensi — EJB entitas, Objek Akses Data, dan sebagainya — harus dapat dikonfigurasi di tingkat arsitektur.
  3. Arsitektur kami harus memanfaatkan teknologi J2EE tetapi merangkum dependensi J2EE. Kami harus dapat mengubah vendor server aplikasi J2EE, versi J2EE, atau mengganti J2EE sepenuhnya tanpa memerlukan perombakan aplikasi secara keseluruhan.
  4. Lapisan persistensi yang dihasilkan harus dapat digunakan kembali di seluruh project. Ini harus menjadi bagian dari arsitektur aplikasi kami yang sedang berjalan.

Setelah Anda mengidentifikasi masalahnya, Anda dapat memutuskan pola mana yang berlaku. Ingatlah bahwa untuk pola J2EE, Anda harus menentukan pola mana yang berlaku di area masalah dan mengatasinya. Untuk ketekunan, pola desain J2EE yang relevan adalah (lihat buku pola desain J2EE Sun di Sumber):

  • Objek Nilai
  • Pembaca Jalur Cepat
  • Objek Akses Data
  • Fasad Sesi
  • Entitas Gabungan
  • Penangan Daftar Nilai

Karena Anda akan menggunakan EJB, sertakan pola Delegasi Bisnis dan Pencari Layanan untuk menangani akses EJB.

Selain itu, menyelesaikan kasus penggunaan kedua dan ketiga memerlukan pola desain pengembangan perangkat lunak tradisional. Bagaimana Anda merangkum dependensi dan memiliki mekanisme persistensi yang dapat dikonfigurasi? Beberapa pola pengembangan perangkat lunak yang dapat diterapkan meliputi:

  • Pabrik
  • Penengah
  • Strategi