Halo, Habr! Kami baru-baru ini menerbitkan buku "
Belajar Java EE. Pemrograman Modern untuk Perusahaan Besar " oleh juara Jawa Jerman Sebastian Dashner.
Dashner aktif menulis dan berbicara tentang topik yang berkaitan dengan Java EE modern, sehingga blognya tidak mengabaikan prinsip-prinsip desain umum untuk platform EE Jakarta, yang sekarang dikembangkan oleh Eclipse. Terjemahan artikel khusus ini (Juni) kami sampaikan kepada Anda hari ini.
Platform Jakarta EE secara bertahap mengambil alih, dan spesifikasi baru untuk pengembangan perusahaan muncul bersamaan dengannya. Untuk menyetujui berbagai standar dan teknologi yang akan segera muncul, seluruh komunitas Java EE hanya akan mendapat manfaat jika prinsip-prinsip desain umum untuk spesifikasi EE Jakarta dikembangkan.
Saya percaya teknologi Java EE telah begitu sukses hanya dengan beberapa prinsip. Di bawah ini saya akan menyampaikan pandangan saya tentang prinsip-prinsip desain mana yang telah dikembangkan di Jawa EE menurut saya yang paling penting, yang layak untuk dipelajari lebih lanjut dan berpotensi dapat berfungsi sebagai rekomendasi untuk desain di Jakarta EE.
Saya memutuskan untuk menulis artikel ini, terinspirasi oleh proposal Dmitry Kornilov mengenai arah pengembangan teknis EE Jakarta.
Yang pertama adalah logika bisnisModel pemrograman yang diadopsi dalam Java EE memungkinkan pengembang untuk fokus pada apa yang diperlukan - yaitu, pada logika bisnis. Anda tidak perlu lagi mewarisi kelas API; pengembang dapat mengekspresikan logika area subjeknya dalam bahasa Java yang biasa dan sebagian besar secara deklaratif (menggunakan anotasi) mengontrol perilaku server aplikasi. Dengan demikian, kerangka kerja terintegrasi dengan mulus ke dalam kode Anda dan, pada dasarnya, mudah untuk dihapus dari sana. Saat mendesain, jangan mengandalkan penggunaan kembali, tetapi pada penghapusan yang mudah.
Namun, implementasi harus secara maksimal membebaskan pengembang dari pekerjaan yang paling sulit - yaitu, memungkinkannya untuk melarikan diri dari persyaratan teknis yang tidak terkait dengan logika bisnis. Contohnya adalah multithreading, transaksi, inversi kontrol, atau pemrosesan permintaan HTTP. Di sisi aplikasi, membosankan itu bagus :)
Tampaknya penting bagi saya bahwa kerangka kerja tidak hanya tidak mengganggu implementasi logika bisnis, tetapi juga mendorong programmer untuk dengan cepat membawa fitur yang dikembangkan ke produksi. Tidak perlu memoles kerangka untuk bersinar - lebih baik untuk membawa kode logika bisnis ke ideal. Bandingkan Java EE atau Spring modern dengan versi kuno J2EE - Saya pikir Anda akan segera mengerti apa yang saya maksud.
EE Jakarta harus berkembang dalam nada yang sama dan, karenanya, fokus pada spesifikasi yang akan memungkinkan pengembang untuk dengan cepat mengimplementasikan logika bisnis.
Konvensi konfigurasiJava EE meminimalkan konfigurasi yang diperlukan untuk mendefinisikan aplikasi perusahaan tipikal. Dalam sebagian besar situasi praktis, perjanjian berjalan langsung, tidak ada konfigurasi yang diperlukan. Jadi, Anda tidak lagi memerlukan file XML untuk mengonfigurasi aplikasi Java EE sederhana. Contoh lain adalah bahwa JAX-RS menyediakan kode respons HTTP default yang sesuai dengan nilai balik metode JAX-RS.
Java EE memang memiliki fleksibilitas untuk memodifikasi perilaku dan mengimplementasikan skrip yang lebih kompleks; Namun, tidak ada kesepakatan tentang ini.
Jakarta EE harus terus mengubah yang sederhana menjadi yang mudah, dan yang kompleks menjadi yang mungkin.
Spesifikasi InteroperabilitasEE Jakarta harus melanjutkan dan memperluas interoperabilitas spesifikasi. Java EE memenuhi spesifikasi yang ada dan fungsionalitas yang ada di dalamnya yang telah menjadi bagian dari standar.
Pengembang dapat mengandalkan spesifikasi berbeda untuk berinteraksi dengan baik satu sama lain, tanpa konfigurasi apa pun. Standar yang diminta: jika lingkungan runtime mendukung spesifikasi A dan spesifikasi B, maka A + B harus saling berinteraksi. Contoh: validasi komponen, JAXB, atau JSON-B dapat digunakan dalam kelas sumber daya JAX-RS, dan tidak diperlukan konfigurasi lebih lanjut.
Ketergantungan Injeksi dan CDITentu saja, EE Jakarta tidak diinginkan untuk menemukan kembali hal-hal yang sudah ada - misalnya, injeksi ketergantungan yang terkait dengan CDI. Diinginkan bahwa spesifikasi menggunakan dan menekankan kekuatan JSR 330 atau, jika perlu, CDI.
Contoh
UriInfo adalah penggunaan
UriInfo dari JAX-RS dalam metode sumber daya. Annotation
@Inject belum mendukung implementasi metode jenis ini. Lebih mudah bagi programmer untuk bekerja, semakin ia bergantung pada mekanisme universal.
Ukuran spesifik lainnya adalah ini: Penyedia CDI harus disediakan dalam spesifikasi, dan, jika perlu, kualifikasi typesafe untuk jenis yang perlu dibuat. Jadi, saat ini, instance klien JAX-RS hanya dapat diperoleh secara terprogram, melalui API
ClientBuilder . Produsen dan kualifikasi menyederhanakan pekerjaan programmer dengan memberikan definisi deklaratif.
Pendekatan deklaratifUntuk semua ini, Java EE API sangat bergantung pada pendekatan deklaratif, saat menggunakan inversi kontrol. Dengan demikian, pengembang tidak memanggil fungsi secara langsung; container bertanggung jawab untuk memanggil fungsional, sementara kita bergantung pada definisi kode. Contoh (dari spesifikasi terkini) adalah JAX-RS, JSON-B, atau CDI.
EE Jakarta tidak hanya menyediakan API perangkat lunak yang lebih komprehensif, tetapi juga harus memfasilitasi penggunaan definisi deklaratif dan inversi kontrol.
Strategi penyebaranFitur khusus (dan menurut saya keuntungan besar) Java EE adalah bahwa model penyebaran yang diusulkan di sini, di mana masalah logika bisnis dipisahkan dari implementasi. Program pengembang khusus untuk API, yang bukan bagian dari artefak penyebaran dan diimplementasikan oleh wadah aplikasi.
Artefak penyebaran yang ringkas ini menyederhanakan dan mempercepat pengiriman program, termasuk perakitan, penerbitan, dan penyebaran seperti itu. Mereka juga kompatibel dengan tingkat sistem file kontainer yang digunakan, misalnya, di Docker. Selama proses perakitan, Anda hanya perlu membangun kembali atau mengirim ulang elemen yang diubah.
Idealnya, artefak penyebaran harus hanya berisi logika bisnis dan tidak ada yang lain; implementasi runtime dan pustaka pihak ketiga yang berpotensi ditambahkan dikirimkan pada tingkat yang lebih rendah, misalnya, di pustaka server aplikasi yang ditambahkan pada tahap perakitan wadah sebelumnya.
Di Jakarta EE, artefak yang dikerahkan juga harus dianggap entitas kelas satu. Mungkin akan ada peluang untuk lebih memperketat lingkungan runtime berdasarkan spesifikasi yang diperlukan oleh aplikasi. Namun, EE Jakarta berharap untuk memberikan perhatian maksimal pada logika bisnis dan produktivitas pengembang, dan penyempurnaan waktu eksekusi sudah sekunder.
TestabilitasMenerapkan prinsip-prinsip di atas, terutama memberikan preferensi untuk pemrograman deklaratif dan injeksi ketergantungan, kami meningkatkan testabilitas kode bisnis. Dengan demikian, pengembang dapat langsung membuat instance objek dalam skrip pengujian, karena sekarang Anda tidak perlu mewarisi kelas API atau memanggil fungsi yang tidak nyaman yang sebelumnya perlu Anda simulasikan.
Namun, di Jakarta EE perlu secara serius memperbaiki standardisasi pengujian integrasi pada tingkat kode, sehingga tidak tergantung pada pabrikan. Sebelumnya, inilah tepatnya yang harus Anda hadapi saat bekerja dengan Arquillian. Dalam proyek nyata, standar semacam itu akan berguna, yang memungkinkan Anda untuk mendeklarasikan hanya skenario penerapan pengujian dan fungsi panggilan untuk satu atau lebih komponen. Sebelumnya, saya menulis bahwa saya tidak menganggap pengujian integrasi pada level kode menjadi sangat penting, misalnya, ketika menjalankan aplikasi dalam wadah bawaan. Namun, jika Anda menstandarkan tes integrasi pada level kode, ini jelas akan memiliki efek positif.
KesimpulanSaya pikir itu bukan kebetulan bahwa Java EE API banyak digunakan dalam proyek nyata: API ini dipikirkan dengan baik dan dirancang sesuai dengan prinsip-prinsip yang jelas, berkat itu dimungkinkan untuk menyatukan tidak hanya satu spesifikasi, tetapi seluruh platform. Mereka memungkinkan Anda untuk menggunakan beberapa spesifikasi sekaligus, didukung dalam semangat yang sama. Di sini, kami berhasil menyingkirkan hambatan buatan yang hanya menyulitkan pekerjaan programmer - oleh karena itu, saya percaya, semua pengembangan usaha menjadi jauh lebih menyenangkan.