Ketika Anda membaca persyaratan untuk aplikasi web perusahaan berikutnya untuk penggunaan internal, maka biasanya (menilai dari pengalaman saya) itu adalah satu dan set yang sama: database relasional untuk menyimpan data, sering diwarisi dari versi aplikasi sebelumnya, sejumlah besar bentuk tingkat kesulitan yang berbeda (tetapi pada saat yang sama khas) untuk entri data, berbagai bentuk pelaporan, logika bisnis yang kompleks, integrasi dengan aplikasi lain - dari akuntansi ke manajemen pasokan, beberapa ribu pengguna yang bekerja secara bersamaan. Apa yang biasanya terlintas dalam pikiran?

"Jadi, saya akan mengambil DBMS yang saya tahu dan yang sesuai dengan volume data mereka, kencangkan Hibernate / JPA, tulis aplikasi pada Spring Boot, buka REST API dan tulis klien pada kerangka JS, kemungkinan besar Angular / Bereaksi."

"Ya, kita masih harus mengacaukan Spring Security. Dan tulis batasan pada akses ke data untuk berbagai departemen dan peran - di tingkat baris basis data atau objek data. Bagaimana cara melakukannya? Pengajuan atau VPD, Anda harus menonton. "

"Ugh, aku harus menulis banyak DAO - mereka selesai dengan cepat, tetapi ada banyak dari mereka."

"Dan konversi dari Entity ke DTO - Saya menggunakan ModelMapper ."

"Hal utama adalah jangan lupa untuk mengingatkan peserta pelatihan tentang atribut malas dan bergabung sehingga tidak ada, seperti terakhir kali."

"Pohon cemara, saat kamu memulai logika bisnis, kamu perlu menulis begitu banyak kode layanan ..."

Artikel ini adalah untuk mereka yang telah menulis setidaknya beberapa aplikasi perusahaan dari awal di Spring / Spring Boot dan sekarang berpikir bahwa akan lebih baik untuk mempercepat pengembangan yang berbeda, tetapi pada saat yang sama, aplikasi dengan tipe yang sama. Selanjutnya, kita akan melihat cara menyingkirkan tugas "khas" menggunakan Platform CUBA .

Kerangka lain?

Pikir nomor satu, ketika pengembang ditawari kerangka kerja baru (dan, khususnya, CUBA), itu adalah: "Mengapa saya harus repot dengan ini? Saya akan mengambil Spring Boot yang familier dan akrab dan saya akan menyelesaikan semuanya. " Dan ini masuk akal. Kerangka kerja baru adalah studi tentang pendekatan pengembangan baru, jebakan baru dan keterbatasan yang telah Anda pelajari untuk secara cerdik hindari ketika berkembang dalam kerangka kerja yang akrab.

Tetapi, ketika saya mulai mengembangkan CUBA, saya tidak perlu banyak mengubah keahlian saya dengan Spring. Secara alami, saya harus meluangkan sedikit waktu untuk memahami platform, tetapi ini bukan gangguan radikal dari semua kebiasaan, melainkan perubahan kecil dalam keterampilan pengembangan.
Akibatnya, kode untuk DTO, output data halaman demi halaman, penyaringan data (analisis parameter yang ditransfer ke formulir dan kompilasi permintaan) menghilang. Pada saat yang sama, saya hampir tidak perlu mengotak-atik pengaturan Spring Security dan menulis kode admin, formulir login dan logika alih bahasa antarmuka pengguna.

Mari kita mulai dari awal dan melihat bagaimana pengembangan CUBA dibandingkan dengan cara biasa mengembangkan di Spring dan bagaimana, menggunakan pengalaman Anda dan belajar beberapa hal baru, Anda akhirnya dapat membangun aplikasi lebih cepat.

Fokus utama artikel adalah pada pengembangan sisi server agar tidak kehilangan fokus dan menjaga jumlah teks pada tingkat yang dapat diterima.

Arsitektur Aplikasi Musim Semi

Dalam 90% kasus, mengetik di Google "Spring Application Architecture" atau "Spring application architecture", Anda akan melihat gambar yang serupa. Aplikasi tiga lapis klasik dengan modul yang umum untuk beberapa lapisan.



Model Domain (Model Domain) - kelas entitas dari domain (Entitas), disimpan, sebagai aturan, dalam database. Kelas biasanya dibuat secara manual, tetapi Anda dapat membangun struktur secara otomatis, berdasarkan skema database.

Lapisan Repositori (Lapisan Repositori) - sekumpulan kelas yang menyediakan pekerjaan dengan gudang data. Biasanya, lapisan ini menggunakan berbagai kerangka kerja ORM dan berisi logika untuk melakukan operasi CRUD. Jika kita berbicara tentang Spring, maka repositori cukup kompak, terutama karena metode JPA Query, tetapi sering kali Anda harus menulis logika pemilihan dari database dan memetakannya ke model domain secara manual.

Lapisan Layanan - lapisan aplikasi yang berisi implementasi logika bisnis, algoritma pemrosesan informasi khusus untuk bidang subjek. Ini berguna dalam kasus algoritme pemrosesan yang kompleks, serta untuk bekerja dengan data dari berbagai sumber (basis data, aplikasi eksternal, layanan dari Internet, dll.).

Web / Controllers Layer - kelas yang bertanggung jawab untuk REST API. Mungkin juga ada file templat halaman pada lapisan ini jika kita menggunakan kerangka kerja seperti Thymeleaf, Velocity, serta kelas yang bertanggung jawab untuk rendering dan penanganan peristiwa antarmuka pengguna jika sesuatu seperti GWT, Vaadin, Wicket, dll digunakan. Biasanya, pengontrol bekerja dengan DTO, dan bukan dengan kelas dari lapisan domain, sehingga fungsi konversi DTO ke Entitas dan sebaliknya ditambahkan ke aplikasi.
Jika semua hal di atas jelas bagi Anda, atau bahkan "kapten reguler" sangat baik. Jadi, Anda dapat mulai bekerja dengan CUBA tanpa masalah.

Aplikasi Referensi - Klinik Hewan Peliharaan

Mari kita lihat contoh spesifik dan tulis beberapa kode. Untuk Spring, ada aplikasi "referensi" - Pet Clinic di GitHub . Aplikasi ini dibuat dalam versi yang berbeda menggunakan alat yang berbeda - dari Spring klasik hingga Kotlin dan Angular. Selanjutnya kita akan melihat cara membuat aplikasi ini di CUBA. Bagi mereka yang tidak terbiasa dengan versi Spring, ada teks yang bagus di sini ; kutipan dari itu akan digunakan dalam artikel ini.

Model data

Diagram ER ditunjukkan pada gambar di atas. Model domain mengulangi struktur ini, beberapa kelas dengan bidang umum ditambahkan padanya, dan kelas entitas sudah diwarisi darinya. UML dapat ditemukan di presentasi yang saya sebutkan sebelumnya.

Lapisan repositori

Ada empat repositori dalam aplikasi yang bertanggung jawab untuk bekerja dengan entitas Pemilik (Pemilik), Hewan Peliharaan (Pet), Kunjungan (Visit) dan Dokter Hewan (Dokter Hewan). Repositori ditulis menggunakan Spring JPA dan hampir tidak mengandung kode, hanya deklarasi metode. Namun, kueri telah ditambahkan ke repositori yang berfungsi dengan entitas Pemilik, yang memungkinkan pemilik ekstraksi dan hewan peliharaan mereka dari database dalam satu sampel.

Antarmuka pengguna

Klinik Pet memiliki sembilan halaman yang memungkinkan Anda melihat daftar pemilik, hewan peliharaan mereka, dan daftar dokter hewan. Aplikasi ini menyediakan fungsionalitas CRUD sederhana: dimungkinkan untuk mengedit beberapa data - pemilik, hewan peliharaan, dan Anda juga dapat menambahkan kunjungan ke klinik. Namun, seperti yang telah disebutkan, kami tidak akan membahas antarmuka pengguna secara mendalam dalam artikel ini.

Opsional

Selain kode untuk manipulasi sederhana dengan entitas, aplikasi ini memiliki fungsi menarik yang dirancang untuk menunjukkan kemampuan Spring:

• Caching - daftar dokter hewan dipilih dari database hanya sekali, kemudian disimpan dalam cache sampai server aplikasi restart.
• Memeriksa penyelesaian bidang yang diperlukan saat memasukkan informasi tentang hewan peliharaan baru.
• Memformat jenis hewan sebelum menampilkannya.
• i18n - aplikasi mendukung Bahasa Inggris dan Jerman.
• Manajemen Transaksi - Beberapa transaksi ditandai sebagai hanya-baca.

Catatan marjinal

Saya sangat suka gambar ini. Ini 100% mencerminkan perasaan saya ketika bekerja dengan kerangka kerja. Untuk menggunakan kerangka kerja secara efektif, Anda harus memahami bagaimana kerangka itu dibangun di dalamnya (apa pun yang terjadi). Misalnya, berapa banyak dari Anda yang bertanya-tanya berapa banyak kelas yang diperlukan untuk membuat antarmuka JPA berfungsi?
Bahkan dalam aplikasi kecil seperti Pet Clinic, ada sedikit keajaiban Spring Boot:

• Tidak ada konfigurasi untuk cache (kecuali untuk anotasi @Caheable ), namun, Boot Spring “tahu” bagaimana memulai cache yang diinginkan (EhCache dalam kasus ini).
• Repositori CRUD tidak ditandai dengan anotasi @Transactional (dan kelas induknya adalah org.springframework.data.repository.Repository juga), tetapi semua metode save() berfungsi seperti yang diharapkan.

Tetapi, terlepas dari semua "implisit", Spring Boot sangat populer. Mengapa Ini transparan dan dapat diprediksi. Dokumentasi yang baik dan kode sumber terbuka memungkinkan untuk memahami prinsip-prinsip dan, jika perlu, menyelidiki rincian implementasi. Tampak bagi saya bahwa semua orang menyukai kerangka kerja, transparansi dan prediktabilitas seperti itu - kunci stabilitas dan pemeliharaan aplikasi.

Klinik Hewan Piaraan di platform CUBA

Baiklah, mari kita lihat Klinik Hewan Piaraan, yang dibuat menggunakan CUBA, dari sudut pandang pengembang Spring dan cobalah untuk memahami di mana Anda dapat menyimpan.

Kode sumber aplikasi dapat ditemukan di GitHub . Selain itu, Platform CUBA memiliki dokumentasi yang sangat baik dalam bahasa Rusia dan Inggris, yang menjelaskan secara terperinci bagaimana mengembangkan dengan benar di platform ini. Banyak contoh di GitHub , termasuk beberapa tutorial. Dalam artikel saya akan sering merujuk pada dokumentasi, agar tidak menulis hal yang sama dua kali.

Arsitektur Aplikasi CUBA

Aplikasi CUBA terdiri dari modul yang ditunjukkan dalam diagram.



Global (modul global) - berisi kelas entitas, representasi CUBA, dan antarmuka layanan yang digunakan dalam berbagai modul.

Inti (modul layanan) - ini adalah tempat kode layanan yang menerapkan logika bisnis, serta kode untuk bekerja dengan gudang data, ditempatkan. Perlu dicatat bahwa kelas-kelas ini tidak tersedia dari modul aplikasi lain, ini dilakukan untuk menyediakan penyebaran terpisah untuk skalabilitas yang lebih baik. Untuk menggunakan layanan di modul aplikasi lain, Anda harus menggunakan antarmuka yang dideklarasikan di modul global.

GUI, Web, Desktop, Portal - modul ini berisi kode untuk kelas yang terkait dengan pemrosesan acara antarmuka pengguna, serta pengendali REST tambahan jika API REST CUBA bawaan tidak cukup.

Untuk menghemat waktu pengembang, CUBA memiliki studio - lingkungan pengembangan grafis kecil yang membantu melakukan pekerjaan rutin, seperti menghasilkan entitas, mendaftarkan layanan dalam file konfigurasi, dll. menggunakan antarmuka grafis. Untuk menghasilkan antarmuka dari aplikasi yang dikembangkan, ada (hampir) editor WYSIWYG.

Dengan demikian, aplikasi yang berbasis pada Platform CUBA terdiri dari dua modul utama - Core dan GUI, yang dapat digunakan secara terpisah, serta modul umum - Global. Mari kita lihat lebih dekat desain modul-modul ini.

Modul global

Model Entitas

Pemodelan entitas dalam aplikasi CUBA tidak berbeda dengan apa yang digunakan pengembang Spring. Kelas domain dibuat dan anotasi @Table , @Table , dll. Dimasukkan ke dalamnya. Kelas-kelas ini kemudian terdaftar dalam file persistence.xml .

Saat menulis Pet Clinic, saya hanya menyalin kelas-kelas dari aplikasi Musim Semi asli dan sedikit mengubahnya. Berikut adalah beberapa tambahan kecil yang perlu Anda ketahui jika Anda menulis di platform CUBA:

1. CUBA memperkenalkan konsep " namespace " untuk setiap komponen aplikasi untuk menghindari duplikasi nama tabel dalam database. Itulah sebabnya awalan "petclinic $" ditambahkan ke setiap entitas.
2. Disarankan untuk menggunakan anotasi @NamePattern - analog dari metode toString() untuk tampilan entitas yang dapat dibaca dalam antarmuka pengguna.

Pertanyaan alami: "Apa lagi yang ditambahkan CUBA selain awalan dan deklaratif ke toString() ?" Berikut adalah sebagian daftar fitur tambahan:

1. Basis kelas dengan ID yang dibuat secara otomatis dari Integer ke UUID.
2. Antarmuka penanda yang berguna yang menyediakan fitur tambahan:
   
   • Versioned - untuk mendukung Versioned versi instance entitas.
   • SoftDelete - untuk mendukung penghapusan "logis" catatan dalam database.
   • Updatable - bidang ditambahkan untuk mendaftarkan fakta memperbarui catatan, nama pengguna dan waktu.
   • Creatable - bidang ditambahkan untuk mendaftarkan pembuatan catatan.
   
   Anda dapat membaca lebih lanjut tentang pemodelan entitas dalam dokumentasi .
3. Skrip untuk membuat dan memperbarui database secara otomatis dihasilkan menggunakan CUBA Studio.

Jadi, membuat model data untuk Klinik Pet datang untuk menyalin kelas entitas dan menambahkan hal-hal khusus CUBA ke mereka, yang saya sebutkan di atas.

Tampilan

Konsep "representasi" dalam CUBA mungkin tampak agak tidak biasa, tetapi cukup mudah untuk dijelaskan. Tampilan adalah cara deklaratif untuk mendeklarasikan atribut yang nilainya perlu diambil dari gudang data.

Misalnya, Anda perlu mengekstrak pemilik dan hewan peliharaan mereka dari basis data (atau dokter hewan dan profesi mereka) - tugas yang sangat umum saat membuat antarmuka adalah ketika Anda perlu menampilkan data dependen dalam bentuk yang sama dengan yang utama. Di Musim Semi, ini dapat dilakukan melalui ...

 @Query("SELECT owner FROM Owner owner left join fetch owner.pets WHERE owner.id =:id") public Owner findById(@Param("id") int id); 

... atau atur atribut EAGER / LAZY untuk mengambil koleksi entitas utama dalam konteks satu transaksi.

 @ManyToMany(fetch = FetchType.EAGER) @JoinTable(name = "vet_specialties", joinColumns = @JoinColumn(name = "vet_id"), inverseJoinColumns = @JoinColumn(name = "specialty_id")) private Set<Specialty> specialties; 

Di CUBA, Anda bisa melakukan ini melalui EntityManager dan JPQL (semua orang tahu caranya) atau melalui tampilan dan DataManager:

1. Bentuk presentasi (dapat dilakukan di CUBA Studio atau secara manual dalam konfigurasi)
   
   

    <view class="com.haulmont.petclinic.entity.Vet" extends="_minimal" name="vet-specialities-view"> <property name="specialities" view="_minimal"> </property> </view> 

2. Dan gunakan DataManager untuk mengambil:

    public Collection<Vet> findAll() { return dataManager.load(Vet.class) .query("select v from cubapetclinic$Vet v") .view("vet-specialities-view") .list(); } 

Anda dapat membuat tampilan berbeda untuk tugas yang berbeda dengan sekumpulan atribut yang diinginkan dan tingkat entitas bersarang. Ada artikel bagus tentang posting blog Mario David.

Enam pengajuan berbeda dibuat untuk aplikasi Pet Clinic. Sebagian besar dari mereka dihasilkan "semi-otomatis" ketika membuat antarmuka pengguna, dan pandangan yang dijelaskan di atas diterapkan untuk layanan ekspor data.

Antarmuka layanan

Karena modul global digunakan oleh semua modul aplikasi lain, antarmuka layanan dideklarasikan di dalamnya, sehingga nantinya mereka dapat digunakan dalam modul lain melalui mekanisme injeksi ketergantungan (DI).

Selain itu, Anda perlu mendaftarkan layanan di file web-spring.xml di modul Web. Ketika menginisialisasi konteks, CUBA akan membuat kelas proksi untuk membuat cerita bersambung dan melakukan deserialisasi saat berinteraksi dengan layanan dalam modul Core. Ini hanya menyediakan penyebaran terpisah dari Core dan modul Web, sementara pengembang tidak perlu melakukan upaya tambahan, semuanya dilakukan secara transparan.

Jadi: saat membuat kelas entitas di CUBA, jumlah waktu yang sama dihabiskan seperti di Spring murni (jika Anda tidak menggunakan CUBA Studio), tetapi Anda tidak perlu membuat kelas dasar untuk menghasilkan kunci primer. Selain itu, Anda tidak perlu menulis kode untuk mendukung bidang versi entitas, penghapusan logis, dan audit. Juga, menurut pendapat saya, pandangan dapat menghemat sedikit waktu untuk debugging JPA bergabung dan memanipulasi sampel EAGER / LAZY.

Modul inti

Modul ini berisi implementasi antarmuka yang dinyatakan dalam modul global. Setiap layanan dalam aplikasi CUBA dijelaskan oleh @Service , Anda dapat menggunakan anotasi Spring lainnya, tetapi Anda perlu mempertimbangkan yang berikut:

• Jika Anda ingin layanan tersedia dalam modul lain, Anda harus mengatur anotasi @Service .
• Disarankan untuk memberi nama layanan untuk menghindari duplikasi jika komponen muncul dalam aplikasi yang mengimplementasikan antarmuka yang sama.
• Pengambilan sampel data dilakukan sedikit berbeda dari pada Musim Semi, lebih banyak pada bagian selanjutnya.

Jika tidak, modul Core adalah kode Spring reguler. Anda dapat memilih data dari database, Anda dapat memanggil layanan web eksternal, secara umum, menulis kode seperti biasa.

Manajer Entitas dan Pengelola Data

Platform CUBA menggunakan EntityManager sendiri, yang mendelegasikan sebagian dari panggilan ke javax.persistence.EntityManager sudah dikenal, tetapi tidak mengimplementasikan antarmuka ini. EntityManager terutama menyediakan operasi tingkat rendah dan tidak sepenuhnya mendukung model keamanan CUBA. Kelas utama untuk bekerja dengan data adalah DataManager, yang menyediakan fungsionalitas berikut:

• Kontrol akses di tingkat baris dan atribut.
• Menggunakan tampilan saat mengambil data.
• Atribut dinamis.

Lebih lanjut tentang DataManager dan EntityManager ditulis dalam dokumentasi . Tidak perlu secara eksplisit bekerja dengan kelas-kelas ini untuk memilih data ke dalam komponen antarmuka pengguna (tabel, dll.), Sumber data (Sumber Data) digunakan dalam GUI.

Jika kita berbicara tentang PetClinic - hampir tidak ada kode dalam modul Core, tidak ada logika bisnis yang kompleks dalam aplikasi ini.

Fungsionalitas tambahan dari Pet Clinic ke CUBA

Di bagian sebelumnya, fungsionalitas tambahan dipertimbangkan dalam aplikasi referensi. Karena CUBA menggunakan Spring, fungsi yang sama juga tersedia saat mengembangkan berdasarkan platform ini, tetapi Anda harus melakukannya tanpa beberapa keajaiban Spring Boot. Selain itu, CUBA menyediakan fungsionalitas out-of-box yang serupa.

Caching

Platform CUBA memiliki cache permintaan dan cache entitas. Mereka dijelaskan secara rinci dalam dokumentasi dan dapat dianggap sebagai solusi prioritas jika Anda ingin menggunakan caching dalam aplikasi. Solusi tertanam mendukung penyebaran dan pengelompokan aplikasi terdistribusi. Yah, tentu saja, Anda dapat menggunakan anotasi @Cacheable , seperti yang dijelaskan dalam dokumentasi Spring , jika cache @Cacheable tidak bekerja untuk sesuatu.

Pemeriksaan input

CUBA menggunakan BeanValidation untuk memvalidasi data yang dimasukkan. Jika kelas bawaan tidak menyediakan fungsionalitas yang diperlukan, Anda dapat menulis logika cek sendiri . Dan, di samping itu, CUBA menyediakan kelas Validator , yang dijelaskan di sini .

Pemformatan keluaran

Platform CUBA menyediakan beberapa formatter untuk komponen antarmuka pengguna, Anda juga dapat membuatnya sendiri sebagai tambahan terhadap standar. Anda bisa menggunakan anotasi @NamePattern untuk merepresentasikan instance entitas sebagai string

i18n

CUBA mendukung keluaran multi-bahasa menggunakan file message.properties , tidak ada yang baru di sini. CUBA Studio membuat membuat dan mengedit file seperti itu dengan cepat dan mudah.

Manajemen transaksi

Jenis manajemen transaksi berikut ini didukung:

• Akrab dengan anotasi Spring @Transactional ,
• Antarmuka yang Persistence (dan kelas) jika Anda memerlukan manajemen transaksi tingkat rendah.

Ketika saya menulis Pet Clinic, saya membutuhkan manajemen transaksi hanya di satu tempat: ketika saya mengembangkan formulir input yang memungkinkan saya untuk mengedit beberapa entitas terkait pada satu layar. Itu perlu untuk mengedit pemilik dan hewan peliharaan mereka, serta menambah kunjungan ke klinik. Itu perlu untuk hati-hati menyimpan data dan memperbaruinya di layar lain.

Klinik Hewan Piaraan dalam beberapa jam. Sungguh

Saya membuat salinan Klinik Hewan Peliharaan dengan antarmuka CUBA standar dalam enam jam. Bukan untuk mengatakan bahwa saya adalah seorang ahli dalam CUBA (beberapa minggu telah berlalu sejak saya mulai bekerja di Haulmont), tetapi saya memiliki pengalaman dengan Spring dan itu banyak membantu saya.

Mari kita lihat aplikasi CUBA dalam hal arsitektur klasik:

Model data - kelas entitas dalam modul Global. Membuat model adalah prosedur yang terkenal dan akrab. Berkat kelas BaseIntegerIdEntity untuk menghemat waktu yang biasanya diperlukan untuk bermain-main dengan menghasilkan ID.

Lapisan repositori tidak diperlukan. Saya membuat beberapa tampilan, dan hanya itu. Tentu saja, CUBA Studio menyelamatkan saya sedikit waktu, saya tidak perlu menulis file XML secara manual.

Lapisan layanan - aplikasi hanya memiliki dua layanan untuk mengekspor data ke JSON dan XML. Dalam versi aplikasi Boot Musim Semi saat ini, fitur ini telah dihapus. Meskipun tidak berhasil untuk JSON. Dalam versi CUBA, saya mendeklarasikan antarmuka dalam modul global dan meletakkan implementasinya di Core. Tidak ada yang baru kecuali DataManager, tetapi butuh sedikit waktu untuk menguasainya.

Lapisan pengontrol - Klinik Hewan CUBA hanya memiliki satu pengontrol REST untuk diekspor ke JSON dan XML. Saya menempatkan pengontrol ini di modul Web. Sekali lagi, tidak ada yang istimewa, penjelasannya sama, pengendali pegas biasa.

Antarmuka pengguna - membuat formulir CRUD standar, dan bahkan dengan CUBA Studio, tidak menyebabkan kesulitan apa pun. Tidak perlu menulis kode untuk mentransfer data ke komponen, tidak ada parsing data dari formulir penyaringan data, tidak perlu repot dengan pagination. Ada komponen untuk semua ini. Butuh waktu untuk membuat tampilan seperti yang dibuat dalam versi Spring Boot. Vaadin masih bukan HTML murni, dan itu lebih sulit untuk ditata.

Pengalaman pribadi telah ditabulasi:

	Mudah dimengerti, mudah dilakukan	Saya perlu membaca dokumentasinya
Entitas	Membuat Model Obyek Pembuatan skrip DB Kelas dasar untuk entitas	Fitur tambahan untuk bekerja dengan data
Repositori	Manajer Entitas Tampilan	Datamanager
Layanan	Kacang Kantor Manajemen transaksi Manajemen pengguna	Antarmuka Ketekunan (dan Kelas)
Pengontrol	Pengontrol REST asli URL REST standar	Penerbitan Layanan
Antarmuka	Bentuk standar bekerja dengan data	Gaya dan komponen khusus

Tentu saja, Pet Clinic tidak menggunakan semua fitur CUBA, daftar lengkap fitur platform dapat ditemukan di situs , di sana Anda juga dapat menemukan contoh kode untuk memecahkan masalah khas yang muncul saat mengembangkan aplikasi perusahaan.

Pendapat pribadi saya adalah bahwa CUBA menyederhanakan pengembangan sisi server dari aplikasi dan membantu menghemat lebih banyak waktu dalam mengembangkan antarmuka pengguna jika Anda menggunakan komponen pengguna standar dan kemampuan penataan. Tetapi, bahkan jika Anda memerlukan beberapa antarmuka pengguna khusus, masih akan ada keuntungan karena sisi server standar.

Satu plus! Apakah ada kerugiannya?

Tentu saja ada, tidak ada kerangka kerja yang sempurna. Mereka tidak kritis, tetapi pada awalnya, ketika saya baru saja mulai bekerja dengan CUBA, ada beberapa ketidaknyamanan. Tetapi nilai WTF / m tidak menghalangi.

• Untuk platform CUBA, ada IDE yang menyederhanakan pembuatan awal proyek. Beralih di antara studio dan IDEA sedikit mengganggu pada awalnya. Berita baiknya adalah ada versi beta CLI, Anda tidak perlu menjalankan studio untuk menghasilkan struktur proyek, dan juga - versi selanjutnya dari CUBA Studio akan menjadi plugin Intellij IDEA. Tidak ada lagi peralihan.
  
• CUBA memiliki lebih banyak file XML daripada aplikasi Spring Boot rata-rata, ini karena inisialisasi konteks di CUBA dilakukan dengan caranya sendiri. Sekarang perjuangan sedang berlangsung untuk mengurangi jumlah XML, kita beralih ke anotasi jika memungkinkan.
  
• Tidak ada URL yang "dapat dibaca" untuk formulir antarmuka pengguna. Dimungkinkan untuk mengakses formulir melalui tautan ke layar , tetapi mereka tidak terlalu ramah pengguna.
  
• Untuk bekerja dengan data, Anda perlu menggunakan DataManager, tampilan, dan EntityManager, bukan Spring JPA atau JDBC (tetapi API ini juga tersedia jika perlu).
  
• CUBA bekerja paling baik dengan database relasional sebagai data warehouse. Sedangkan untuk NoSQL, Anda harus menggunakan pustaka akses untuk repositori ini dan menulis layer repositori Anda sendiri. Tetapi ini adalah jumlah pekerjaan yang sama seperti ketika mengembangkan aplikasi tanpa CUBA, menurut saya.
  

Total

Jika ada tugas mengembangkan aplikasi yang menggunakan basis data relasional sebagai gudang data dan berfokus pada bekerja dengan data dalam format tabular, maka CUBA bisa menjadi pilihan yang baik, karena:

1. CUBA transparan. Kode sumber tersedia, metode apa pun dapat didebug.
   
2. CUBA dapat diperpanjang (hingga batas yang diketahui, tentu saja). Anda dapat mewarisi hampir semua kelas utilitas dan menyelipkannya di platform, membuat REST API Anda sendiri, menggunakan kerangka kerja favorit Anda untuk antarmuka pengguna. CUBA dibuat sehingga Anda dapat dengan mudah menyesuaikan solusi untuk setiap pelanggan. Ada artikel bagus tentang perluasan platform.
   
3. CUBA adalah Musim Semi. 80% dari kode server Anda hanya akan menjadi aplikasi Musim Semi.
   
4. Mulai cepat. Anda akan memiliki aplikasi lengkap dengan panel admin setelah membuat entitas pertama dan layar untuk bekerja dengannya.
   
5. Banyak tugas rutin telah diselesaikan di platform.
   

Jadi, dengan CUBA Anda dapat menghemat waktu untuk menulis kode "layanan" yang monoton dan fokus pada penulisan kode untuk memecahkan masalah bisnis. Dan ya, kami di Haulmont menggunakan CUBA untuk mengembangkan produk-produk kotak dan custom.