Memisahkan Business logic dari DB-logic dengan transaksi

Kami memiliki tiga lapisan dalam aplikasi kami. Lapisan layanan untuk menyediakan API eksternal. Lapisan BO untuk logika bisnis kami, dan lapisan DAO untuk koneksi basis data kami.

Katakanlah setiap kali kita memperbarui File, kita juga ingin mengubah sesuatu di Folder, misalnya 'tanggal modifikasi terakhir'. Ini perlu dilakukan dalam transaksi. Entah berhasil dan baik File maupun Folder diedit. Atau ada kegagalan dan transaksi dibatalkan sehingga kedua objek berada dalam keadaan sebelumnya.

Tindakan "Edit folder saat file diedit" adalah murni logika bisnis. Jadi ini berarti itu termasuk dalam lapisan-BO. Namun, kami menggunakan Objectify untuk Database kami, jadi untuk memulai transaksi kami perlu memanggil ofy (). Transact (...). Jika kita memanggil fungsi ini di lapisan BO, ini akan merusak desain kita karena akan ada panggilan khusus Database (Objectify) di lapisan Bisnis kita.

Apa yang akan menjadi solusi bersih untuk masalah ini?

— Serge Hendrickx
sumber

Tidak dapat FileBOmenelepon FolderBO.edit(newDate)karena masalah transaksi?

— Melihat

apakah java tidak memiliki equvilant dari c # TransactionScope?

— Ewan

Di Jawa, cakupan transaksi tergantung pada kerangka kerja yang Anda gunakan. Dalam JEE itu dapat dikelola oleh server aplikasi tetapi biasanya didefinisikan dan dikelola secara deklaratif oleh Framework seperti Spring (penjelasan an, xml, ...)

— Laiv

Jangan khawatir tentang mencoba membuat "lapisan" aplikasi Anda yang berbeda secara fungsional / saling mengabaikan. Rangkullah gagasan bahwa kode Anda dibuat untuk arsitektur yang didukungnya dan alih-alih fokuslah untuk membuat kode itu tersusun dengan baik sehubungan dengan dirinya sendiri.

— Semut P

Jawaban:

Cara Anda memotong transaksi memang merupakan logika bisnis. Jadi biarkan layer DAO Anda menyediakan API db framework independent untuk transactmetode yang Anda sebutkan (dan mungkin untuk hal-hal seperti commitdan rollback). Kemudian Anda dapat menggunakannya dari layer BO Anda tanpa membuatnya tergantung dari database Anda atau kerangka db Anda.

— Doc Brown
sumber

Sepertinya Objectify dirancang untuk transaksi seperti atom ( Transaksi Mesin Aplikasi Google ). Ini akan menuntut Anda untuk mengembangkan abstraksi Anda sendiri tentang Manajemen Transaksi .

Pada kasus ini. abstraksi berjalan Bagaimana cara mendelegasikan manajemen transaksi ke lapisan atas?

@DocBrown mendekati bagi saya solusi yang lebih cepat dan lebih bersih untuk diimplementasikan ke dalam arsitektur yang diberikan ( arsitektur berlapis ).

Karena kami kehilangan terlalu banyak info tentang aplikasi dan konteksnya, solusi Doc juga bagi saya paling aman.

Namun, saya akan menyarankan untuk melihat pola desain UnitOfWork untuk lapisan bisnis . Saya pikir itu sesuai dengan manajemen transaksi yang dimaksudkan oleh Objectify .

Singkatnya, polanya bertujuan untuk merangkum aturan bisnis ke dalam Transaksi Bisnis (unit kerja). Pola ini memungkinkan pewarisan antara B.Ts dan sejauh ini saya melihat, Objectify juga. Bahkan mendukung komposisi. Jadi baik dengan komposisi atau pewarisan, pendekatan ini memungkinkan B.Ts yang kompleks .

Diterapkan pada arsitektur yang diberikan, akan terlihat seperti:

FileService -> FileBO : new EditFileTransaction().execute()
                           |-> ofy().transact(...)
                           |--> FileDAO.actionA()
                           |--> FolderDAO.actionA()
                           |-> [ofy().commit(...)|ofy().rollback()]

— Laiv
sumber