Bisakah model domain dalam database menjadi solusi berkelanjutan?


13

Saya baru saja memulai pekerjaan baru sebagai pengembang basis data untuk perusahaan menengah-kecil yang berbasis pada teknologi Microsoft. Saya perhatikan sejak awal seberapa banyak praktik yang menyimpang dari apa yang telah saya pelajari di sekolah mengenai praktik terbaik, pola desain, pengujian, dan manajemen proyek.

Yang paling menggangguku adalah bagaimana pengembang basis data utama kami (selanjutnya disebut "John") menyimpan skema model dalam basis data! Kami melakukan ini dengan memiliki 3 tabel "ajaib"; satu untuk skema database, satu untuk tabel dan satu untuk kolom.

Menyisipkan catatan ke dalam " Tabel " -tabel menghasilkan (melalui pemicu database), tabel yang sesuai, sebenarnya. Memasukkan baris ke " Baris " -tabel memperbarui tabel yang direferensikan dengan baris itu. Ini pada gilirannya dibaca oleh program C # buatannya untuk menghasilkan model C #, yang digunakan oleh pengembang frontend untuk pengontrol dan keluar.

Terlepas dari ini, sebagian besar pengembangan dilakukan sesuai dengan kerangka kerja ASP.NET MVC .

Saya melihat beberapa kekurangan dengan pendekatan ini:

  • Kami membutuhkannya untuk mempertahankan ORM, dan dia jarang memiliki waktu untuk melakukannya (keamanan pekerjaan baik!)
  • Pemicu untuk tabel "Tabel" dan "Baris" cacat. Mereka tidak mendukung pembaruan tabel, atau Periksa-kendala atau lebih banyak fitur "canggih". Meskipun kami pasti bisa memperbaikinya, saya belum yakin apakah ini jalan yang harus ditempuh.
  • Mempertahankan logika terprogram dalam basis data terasa aneh dan membatasi (walaupun dimungkinkan untuk memperluas modelnya melalui C #).
  • C-Model-generator-nya harus dijalankan secara manual oleh salah satu dari 3 orang (di antaranya saya adalah satu), dan belum cukup matang untuk dimasukkan ke dalam proses pembuatan otomatis.

Beberapa orang telah menyarankan pentahapan dalam produk yang benar dan teruji seperti Entity Framework , tetapi ia menolaknya, menegaskan bahwa menjaga logika bisnis dalam lapisan kode hanya cocok untuk aplikasi skala kecil dan proyek bootstrap untuk startup.

Posting ini mengarah ke sesuatu yang bisa terlihat seperti diskusi yang penuh pendapat, tapi itu bukan maksud saya. Saya hanya ingin klarifikasi mengenai pendekatan arsitektur kami.

Bisakah menjaga model domain dalam database menjadi solusi berkelanjutan bagi perusahaan dalam pertumbuhan?


Model domain sangat terkait erat dengan desain berbasis domain. Inti dari desain yang digerakkan oleh domain adalah bebas dari desain yang didorong oleh data, di mana data (mis. Database) adalah inti dari aplikasi. Pendekatan pendekatan dan model domain tidak benar-benar berjalan bersama. Ketika mengembangkan mengikuti praktik desain berbasis domain, Anda tidak peduli dari mana data berasal, Anda hanya menggunakannya dan melakukan logika di dalamnya di lapisan bisnis Anda.
Andy

Saya sedikit tidak jelas tentang apa yang Anda maksud dengan "menjaga logika program dalam database." Bisakah Anda mengklarifikasi itu?
Robert Harvey

Logika bisnis dalam kode persis cara yang benar. Db harus menjadi datastore bodoh, tidak ada yang lain.
Andy

@Andy saya kira ini tergantung. Mungkin DBA mereka adalah pusat dari tim dan dia menyimpan semua logika bisnis dalam database, yang kemudian ditanyakan oleh panggilan procs yang disimpan bodoh, mengekstrak data ke POCO dll. Ini adalah pendekatan yang dipertanyakan tapi saya tahu tim, menjaga sebagian besar logika bisnis jika tidak semuanya dalam DB.
Vladislav Rastrusny

@VladislavRastrusny Apa pun alasannya, menjaga logika bisnis di db adalah desain yang sangat buruk.
Andy

Jawaban:


16

Anda sedang mendeskripsikan Platform Dalam.

Masalah dengan platform dalam adalah bahwa Anda menemukan kembali semua mekanisme platform atau teknologi (dalam hal ini, database relasional) yang telah diasah dan disempurnakan selama beberapa dekade evolusi dan upaya, tetapi menciptakannya kembali dengan buruk. Anda melewati semua optimasi yang tersedia bagi mereka yang memilih desain yang lebih konvensional, dan berdagang kesederhanaan dan keanggunan awal untuk kompleksitas dan kesulitan di masa depan.

Yang mengatakan, jika produk akhir dari proses ini adalah tabel nyata dan kelas nyata pemodelan objek domain bisnis nyata , saya tidak melihat banyak kerugian dalam pendekatan ini, terlepas dari ketidakdewasaan alat. Stack Exchange sebenarnya menggunakan ORM buatan mereka sendiri, dan itu tampaknya berhasil bagi mereka. Jadi saya tahu bahwa pendekatan "pondok" semacam ini bisa berhasil.

Perhatikan bahwa sebagian besar ORM yang mengambil pendekatan "table-first" cukup melihat struktur tabel dalam database untuk membuat kelas. Tabel "tabel" dan "baris" yang telah dibuat teman Anda hanyalah metadata yang sudah ada di tabel sistem dari sebagian besar sistem basis data relasional modern.

Bacaan Lebih Lanjut
Proyek "Visi", sebuah kisah peringatan tentang efek platform dalam
(Anda dapat melewatkan pembukaan dan mulai membaca di sub judul "Pengenalan Visi")


2
Baca menarik, saya pasti bisa menggambar anologi. Saya masih baru dan akan tetap menjadi penonton untuk saat ini, tetapi saya pasti akan menyimpannya di bawah lensa. Terima kasih atas tanggapan yang baik!
krystah
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.