Menerapkan MVVM di ABAP

Setelah lulus, saya bekerja sebagai programmer C # selama beberapa tahun. Saya telah mengembangkan aplikasi WPF menggunakan pola desain MVVM. Lalu saya beralih ke ABAP. Sangat mengejutkan saya, saya menemukan bahwa ABAP lebih merupakan bahasa prosedural daripada bahasa berorientasi objek, meskipun SAP bekerja keras untuk memajukan paradigma OO. Untuk memisahkan logika bisnis dari GUI, pola arsitektur MVC biasanya digunakan. Setiap kali saya mencoba menerapkan pola MVC, saya menghadapi kesulitan tertentu yang membuat program lebih sulit dipelihara daripada jika ditulis dalam prosedur. Terlepas dari kenyataan bahwa implementasi MVC dijelaskan secara rinci dan dengan contoh-contoh dalam buku Design Patterns in ABAP Objects dan pada sumber daya khusus ( sapland.ru , blogs.sap.comdan lainnya), masalah dengan pemisahan logika tetap ada. Dalam implementasi MVC di ABAP, Model tetap menjadi bagian independen, dan Tampilan serta Pengontrol terkait erat. Kopling yang kuat antara View dan Controller menyulitkan pemeliharaan dan penskalaan. Berikut ini menjelaskan mengapa hal ini terjadi dan apa yang harus dilakukan.

Pola MVC dan MVVM

Saya tidak akan menjelaskan secara detail bagaimana pola MVC dan MVVM bekerja di artikel ini. Saya hanya akan memberikan poin utama yang kami butuhkan di masa depan.



Perbedaan utama antara MVC dan MVVM adalah bahwa pada Kontroler pertama yang mengetahui Tampilan dan Model, juga diizinkan bahwa Tampilan mengetahui tentang Model.







Dalam pola MVVM, hubungan antar lapisan lebih lemah. View hanya mengetahui Model ViewModel dan ViewModel saja. Tampilan menerima data dari ViewModel melalui referensi DataContex.







Pola MVVM dirancang untuk pengembangan WPF di C #. Tapi idenya bisa diterapkan ke ABAP juga.

Masalah MVC di ABAP

Saat mengimplementasikan MVC, sebagai aturan, kelas Model dibawa ke definisi global, dan kelas View dan Controller ke dalam definisi lokal. Penggunaan kelas lokal karena kebutuhan untuk berinteraksi dengan elemen GUI. Faktanya adalah Anda tidak dapat membuat GUI lengkap pada kelas ABAP. Di kelas View, Anda dapat menggunakan fungsionalitas untuk membentuk GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY, dll.), Tetapi ini tidak cukup. Tidak mungkin membuat status GUI, header, layar, PBO, PAI di dalam kelas.



Tampilan Lokal dan Pengontrol memiliki beberapa kelemahan:

1. View dan Controller memiliki akses ke semua variabel dan parameter global dari layar pemilihan.
2. PBO PAI Controller View ( ALV) View ( ALV). View, Controller, View Controller. , .. , Low Coupling.

MVVM ABAP MVA

Ingin memanfaatkan MVVM di ABAP dan membuat lapisan lebih mandiri, saya menentukan pola pengembangan berikut untuk diri saya sendiri.







Karena tidak mungkin mengimplementasikan MVVM dalam bentuk aslinya di ABAP, menggunakan ViewModel tidak sepenuhnya benar. Jadi alih-alih ViewModel dan Controller saya menggunakan Application.



Prinsip pemisahan logika mirip dengan prinsip MVVM. View meneruskan perintah pengguna ke Aplikasi, dan Aplikasi bertindak sesuai model. Tidak ada umpan balik.

Salah satu fitur aplikasi ABAP adalah tampilan hanya dapat diperbarui setelah tindakan pengguna. Meskipun beberapa proses asynchronous mengubah model, itu tidak akan dapat memulai pembaruan tampilan. Fitur ini memungkinkan Anda untuk melemahkan hubungan model-view dan mendelegasikan fungsi memperbarui tampilan ke tampilan itu sendiri. Dengan kata lain, gagasan itu sendiri harus memutuskan kapan memperbarui dirinya dan kapan tidak.

Konsep MVA

Implementasi MVA didasarkan pada pendekatan berorientasi objek, di mana satu atau lebih kelas akan diimplementasikan untuk setiap lapisan arsitektur. Setiap lapisan memiliki sejumlah properti.



Lihat (Lihat dan IView):

• MVA bekerja dengan abstraksi tampilan IView. Semua kelas View harus berisi implementasi IView.
• IView berisi peristiwa yang membutuhkan interaksi dengan model
• IView berisi konteks - tautan ke data model yang perlu ditampilkan kepada pengguna
• Tampilan dapat berisi logika bisnis yang tidak memerlukan interaksi dengan model. Misalnya, jika Anda ingin menerapkan dari ALV jatuh ke kartu mitra, maka logika ini akan diterapkan ke tampilan.
• View berisi elemen GUI dalam grup fungsi yang terkait dengan kelas View.

Aplikasi:

• Berfungsi sebagai pengikat tampilan dan model serta merupakan pintu masuk ke aplikasi.
• Memiliki kriteria peluncuran - sekumpulan parameter yang menentukan dengan parameter apa aplikasi harus diluncurkan. Ini biasanya merupakan parameter layar pemilihan.
• Kriteria aplikasi terdiri dari kriteria model dan penyajian. Misalnya, jika layar pemilihan mengharuskan Anda untuk memasukkan tanggal posting dan menentukan tanda keluaran laporan PDF atau ALV, maka tanggal posting akan mengacu pada kriteria model dan tanda PDF dan ALV ke kriteria presentasi.
• Kriteria peluncuran diteruskan ke desainer aplikasi. Aplikasi membuat model dan tampilan, berlangganan untuk melihat peristiwa, dan mengikat konteks tampilan ke model.

Model:

• Berisi atribut publik yang dibutuhkan tampilan.
• Berisi kriteria perhitungan model dan metode inisialisasi.

Implementasi MVA

Mari pertimbangkan penerapan MVA menggunakan contoh laporan aliran material. Tombol penyegaran data akan digunakan sebagai interaksi dengan model.



Diagram kelas akan terlihat seperti ini.







Model. Perancang model akan mengambil kriteria pemilihan data sebagai masukan. Kelas akan memiliki metode untuk menginisialisasi dan memperbarui data, serta atribut dengan data untuk ditampilkan.















Saya melihat. Antarmuka tampilan berisi metode untuk menyetel konteks, menampilkan tampilan, peristiwa, dan menentukan jenis konteks.















IView berisi deskripsi struktur konteks, dan bidang struktur harus menjadi referensi







View.Tampilan mengimplementasikan antarmuka IView. Selain itu, semua kejadian pengguna didaftarkan oleh kelas View dan hanya memunculkan kejadian yang perlu diproses oleh aplikasi. Di parameter peristiwa, Anda harus meneruskan semua data yang diperlukan dari Tampilan (misalnya, garis ALV yang disorot).



Implementasi kelas View dalam tampilan ALV







Dalam implementasi ini, kita perlu mendefinisikan status GUI, untuk ini kita akan membuat FM dan menghubungkannya ke instance CL_SALV_TABLE.







Penting bahwa semua kejadian UI diterima oleh View (dalam hal ini, melalui ON_USER_COMMAND) dan, jika perlu, View membuat RAISE EVENT untuk Aplikasi. Pendekatan ini membuat Tampilan dan Aplikasi lebih mandiri.



Aplikasi.Desainer aplikasi mengambil kriteria aplikasi (opsi layar pemilihan) sebagai input dan membuat instance Model dan View, berlangganan ke peristiwa View, dan mengikat konteks View ke Model. Konstruktor adalah satu-satunya tempat aplikasi mengetahui tentang View. Aplikasi berisi metode RUN yang memulai program. Memulai aplikasi dapat dibandingkan dengan memulai transaksi dengan parameter layar yang telah ditentukan sebelumnya. Ini memungkinkannya untuk digunakan dari program lain tanpa SUBMIT.







Meluncurkan Aplikasi. Sekarang kami sedang membuat program yang akan meluncurkan aplikasi.







Itu saja, aplikasinya sudah siap. Anda bisa melihat hasilnya.







Logika bisnis di sisi View. Acara yang tidak memerlukan pemanggilan model dan pengontrol bisa ditangani di Tampilan itu sendiri.



Misal, jika ingin membuka MM03 dengan cara double click pada MATNR, maka pengolahan logika ini bisa dilakukan pada sisi View.







Logika ini dipindahkan ke tingkat Tampilan berdasarkan pertimbangan: model tidak perlu ditangani untuk data tambahan; logika hanya berlaku untuk ALV, yaitu jika ada implementasi View dalam bentuk Excel atau PDF, maka acara ini tidak bisa diproses.



Referensi



Pola Desain dalam Pola Objek ABAP

untuk pemula: MVC vs MVP vs MVVM

Pola arsitektur di ABAP: MVC, MVP, MVVM, MVA