Pertanyaan Umumnya pada aplikasi web J2EE Besar, aplikasi terpisah dengan jelas oleh modul. Kemungkinan penggunaan pola delegasi bisnis


Sebelum saya mengajukan pertanyaan "umum" saya, saya ingin menyajikan beberapa kutipan untuk pemahaman umum tingkat tinggi saya tentang pola delegasi bisnis:

"Anda ingin menyembunyikan klien dari kompleksitas komunikasi jarak jauh dengan komponen layanan bisnis."

"Anda ingin mengakses komponen bisnis-tier dari komponen dan klien tier-presentasi Anda, seperti perangkat, layanan web, dan klien kaya."

Katakanlah Anda memiliki aplikasi web J2EE yang besar. Ketika saya bermaksud besar, saya berarti bahwa aplikasi tersebut telah dikembangkan selama beberapa tahun dan oleh banyak orang dan departemen yang berbeda. Sistem ini tidak dirancang dengan baik untuk pertumbuhan. Saat ini, katakanlah aplikasi dikonfigurasi dengan satu aplikasi web.

Akan sangat bagus jika aplikasinya lebih modular. Tapi ternyata tidak. Satu kode atau pustaka dapat menurunkan seluruh sistem. Pengujian dan cara lain digunakan untuk mencegah hal ini, tetapi idealnya ini hanya satu aplikasi web monolitik.

Inilah pertanyaan saya; bagaimana Anda biasanya menghindari jenis desain dengan aplikasi J2EE, di mana aplikasi tumbuh dan berkembang dan satu aplikasi terpisah dapat menurunkan semuanya.

Saya bukan EJB yang akrab dan tidak berencana menggunakannya untuk hal-hal yang terlalu serius. Namun, konsep Pola Delegasi dan Layanan Pelvis Bisnis sepertinya cocok.

Katakanlah Anda memiliki layar keranjang belanja (aplikasi web yang sama) dan satu set layar untuk mengelola akun pengguna (aplikasi web yang sama). Dalam web-tier Anda (semacam metode aksi MVC), tampaknya Anda bisa memiliki Locator yang akan mendapatkan antarmuka khusus bisnis, memanggil antarmuka tersebut per modul dan jika ada yang salah dengan modul itu maka tidak akan membunuh kode lain. . Katakanlah modul keranjang belanja gagal (karena alasan apa pun), layar akun pengguna masih berfungsi.



4
2018-04-27 18:35


asal


Jawaban:


Dalam lingkungan pengembangan perangkat lunak yang sehat, aplikasi "tumbuh dan tumbuh" karena orang-orang bisnis meminta perubahan dan fitur baru dan biasanya tidak ada yang salah dengan itu.

Mari lupakan masalah skalabilitas, dan fokus dalam masalah desain, dengan mengarah pada pemeliharaan yang sangat menyakitkan.

Yang perlu Anda lakukan adalah memisahkan aplikasi Anda dalam modul yang masuk akal untuk orang-orang bisnis (dan pengguna). Setiap modul sistem Anda harus memiliki arti bisnis yang jelas yang mencerminkan domain aplikasi.


1
2018-04-27 22:34



Semua ide itu baik-baik saja, dan akan sangat masuk akal jika Anda memulai dari awal. Sayangnya, Anda tidak memulai dari awal tetapi berurusan dengan prototipe Big Ball of Mud. Percayalah ketika saya mengatakan bahwa saya merasakan sakit Anda.

Lebih penting daripada pola spesifik adalah memaksakan semacam pesanan, segala jenis pesanan, pada kekacauan ini. Lebih penting daripada pilihan desain khusus Anda - dapatkah Anda memaksakan pilihan desain Anda di seluruh sistem sehingga ada paradigma tunggal yang menyatukan seluruh aplikasi?

Jika desain Anda memenuhi persyaratan desain dan secara konseptual menyederhanakan aplikasi maka itu berlaku.


1
2018-04-29 01:38



Cara terbaik untuk memperbaiki sistem seperti ini adalah dengan perlahan membuatnya lebih baik. Jika sistem Anda mirip dengan sistem yang saya kerjakan, mengubah kode sering mengarah ke bug. Tes otomatis adalah cara untuk mengurangi kemungkinan memperkenalkan bug baru, tetapi sering kali kode tersebut tidak ditulis dengan pengujian dalam pikiran, dan mengubah kode untuk membuatnya lebih mudah untuk menulis tes dapat menyebabkan bug.

Cara mengatasi masalah ini adalah dengan memperkenalkan beberapa tes integrasi otomatis, dan menggunakan tes tersebut sebagai jaring pengaman saat Anda dengan hati-hati memperbaiki kode dan memperkenalkan tes pada tingkat yang lebih rendah. Membuat kode lebih dapat diuji sering menghasilkan pengenalan antarmuka dan abstraksi yang membuat kode lebih mudah digunakan. Hal ini juga sering membutuhkan logika bisnis yang terpisah dari logika presentasi (karena menguji keduanya sama-sama menyakitkan) dan membongkar kode kita ke dalam modul (karena kelas dengan banyak ketergantungan bisa sulit untuk diuji).

Ketika Anda menulis kode baru untuk sistem Anda, cobalah untuk menulis tes unit saat Anda menulis kode. Ini jauh lebih mudah (dan karena itu kurang membuat frustrasi) daripada menulis tes untuk kode warisan, dan memberi Anda kesempatan untuk melihat kemana Anda pergi ketika Anda mem-refactor kode warisan Anda.

Saya tahu ada dua bug yang sangat baik mengenai hal ini: Bekerja Efektif dengan Kode Legacy oleh Robert C. Martin dan Refactoring ke Pola oleh Joshua Kerievsky.

Akhirnya, pertimbangkan untuk menggunakan kerangka kerja injeksi ketergantungan, seperti Spring atau Guice. Ketergantungan injeksi membuatnya lebih mudah untuk membuat kode Anda dapat diuji dengan tes unit. Ini juga memudahkan mengikuti praktik desain yang baik seperti Prinsip Ketergantungan Inversi dan Prinsip Pemisahan Antarmuka.


1
2018-05-03 20:22



Cara terbaik untuk menghindari kekacauan saat Anda diberi kesempatan untuk memulai ulang adalah:

  • Gunakan Spring Framework seluruhnya.
  • Perhatikan high-cohesion, low coupling: pastikan tidak ada dependensi melingkar di antara paket (com.myapp.packageA tergantung pada com.myapp.packageB yang tergantung pada com.myapp.packageA). Ada beberapa alat gratis hebat seperti Aturan Arsitektur yang dapat memverifikasi itu untuk Anda secara otomatis.

Dengan dua aturan ini Anda sudah akan dipaksa untuk mengikuti prinsip-prinsip desain yang bagus. Jika tidak, desain membutuhkan perhatian konstan. Inti dari setiap usaha desain adalah untuk mengurangi ketidakpastian, jadi pada dasarnya Anda harus tahu mengapa Anda mendesain di tempat pertama.


1
2018-05-03 22:15