Lapisan layanan aplikasi memanggil fungsi database. Arsitektur yang buruk?

Skenario:

• Stack: Java, Spring, Hibernate.
• Model: Aplikasi Client-Server.
• Pola: Model-View-Controller (MVC).

Kelas-kelas Lapisan Layanan memiliki tiga perilaku:

1. Beberapa layanan memiliki aturan bisnis dalam metode dan mendelegasikan ketekunan ke aplikasi. Suka:

   EntityManager.save (entitas);

2. Beberapa layanan cukup memanggil fungsi basis data (melewati parameter) Seperti:

   CallableStatement cls = con.prepareCall ("{call databaseFunction (args)}");

3. Beberapa layanan memiliki metode dengan kedua perilaku tersebut.

Pertanyaan saya:

1. Apakah ada masalah dalam meminta layanan aplikasi memanggil - langsung - fungsi basis data? Bukankah ini dianggap praktik yang buruk? Apa yang akan menjadi model arsitektur yang berlaku untuk proyek seperti ini?
2. Apakah ada masalah dalam memiliki campuran perilaku dalam layanan yang sama? Seperti transaksi dan konsistensi?
3. Dalam hal pemeliharaan, apakah enkapsulasi ini membuatnya tidak jelas bagi pengembang bahwa ia juga harus mengubah fungsi dalam database? Bagaimana cara menghindarinya?
4. Apakah skenario ini terjadi pada aplikasi lain di seluruh dunia atau itu hanya kesalahan arsitektur?

Apakah ada masalah dalam meminta layanan aplikasi memanggil - langsung - fungsi basis data? Bukankah ini dianggap praktik yang buruk?

Saya pikir ada. Anda menempatkan pengetahuan tentang internal basis data ke layanan aplikasi. Mengubah database dengan cara apa pun (mengganti mesin penyimpanan atau bahkan mengubah nama bidang atau membuat indeks) mungkin mengharuskan Anda untuk mengubah layanan aplikasi dan itu melanggar SRP .

Apa yang akan menjadi model arsitektur yang berlaku untuk proyek seperti ini?

Lihat komentar di bawah.

Apakah ada masalah dalam memiliki campuran perilaku dalam layanan yang sama? Seperti transaksi dan konsistensi?

Saya tidak percaya ada masalah teknis, tapi ada yang logis. Anda hanya mencampur dua pendekatan dalam aplikasi sehingga tidak jelas, kurang terstruktur, sulit beradaptasi dengan perubahan. Lihat komentar di atas tentang melanggar SRP juga.

Dalam hal pemeliharaan, apakah enkapsulasi ini membuatnya tidak jelas bagi pengembang bahwa ia juga harus mengubah fungsi dalam database?

Tentu saja.

Bagaimana cara menghindarinya?

Tempatkan metode dan fungsi, yang secara langsung bekerja dengan basis data ke dalam tingkat abstraksi yang terpisah (baik itu lapisan DAO atau pola penyimpanan sederhana - tergantung pada kompleksitas aplikasi Anda)

Apakah skenario ini terjadi pada aplikasi lain di seluruh dunia atau itu hanya kesalahan arsitektur?

Saya pikir di dunia kita semuanya terjadi;)

Menurut apa yang Anda katakan ada lapisan layanan sehingga pola arsitektur yang tampaknya cocok adalah Layered Architecture. Referensi lebih lanjut

Ya itu biasanya merupakan praktik yang buruk untuk melakukan panggilan database langsung di lain dari pada lapisan akses data, dengan cara itu lapisan bisnis hanya mengakses abstraksi dari database.

Adapun perilaku pencampuran, menggunakan beberapa pola desain sebagai pola DAO atau pola Repositori dapat membantu mendelegasikan tanggung jawab itu sehingga meningkatkan kode itu.

Beberapa keuntungan menggunakan pola desain dan ORM adalah keterbacaan kode Anda enkapsulasi tanggung jawab jadi jika akses database Anda berubah lapisan bisnis Anda tidak boleh banyak berubah.