Mengapa kita membutuhkan objek entitas? [Tutup]

Saya benar-benar perlu melihat beberapa debat yang jujur ​​dan bijaksana tentang manfaat paradigma desain aplikasi perusahaan yang saat ini diterima .

Saya tidak yakin bahwa objek entitas harus ada.

Berdasarkan objek entitas, saya maksudkan hal-hal khas yang cenderung kita bangun untuk aplikasi kita, seperti "Orang", "Akun", "Pesanan", dll.

Filosofi desain saya saat ini adalah:

• Semua akses basis data harus dilakukan melalui prosedur tersimpan.
• Kapan pun Anda membutuhkan data, panggil prosedur tersimpan dan ulangi melalui SqlDataReader atau baris dalam DataTable

(Catatan: Saya juga telah membangun aplikasi perusahaan dengan Java EE, orang-orang java silakan gantikan equvalent untuk contoh .NET saya)

Saya bukan anti-OO. Saya menulis banyak kelas untuk tujuan yang berbeda, tidak hanya entitas. Saya akan mengakui bahwa sebagian besar kelas yang saya tulis adalah kelas pembantu statis.

Saya tidak membangun mainan. Saya berbicara tentang aplikasi transaksional volume besar yang digunakan di beberapa mesin. Aplikasi web, layanan windows, layanan web, interaksi b2b, apa saja.

Saya telah menggunakan ATAU Pemetaan. Saya telah menulis beberapa. Saya telah menggunakan Java EE stack, CSLA, dan beberapa padanan lainnya. Saya tidak hanya menggunakannya tetapi secara aktif mengembangkan dan memelihara aplikasi ini di lingkungan produksi.

Saya telah sampai pada kesimpulan pertempuran-diuji yang objek entitas mendapatkan di jalan kami, dan hidup kita akan jadi lebih mudah tanpa mereka.

Pertimbangkan contoh sederhana ini: Anda mendapat panggilan dukungan tentang halaman tertentu di aplikasi Anda yang tidak berfungsi dengan benar, mungkin salah satu bidang tidak bertahan seperti seharusnya. Dengan model saya, pengembang yang ditugaskan untuk menemukan masalah membuka persis 3 file . ASPX, ASPX.CS dan file SQL dengan prosedur tersimpan. Masalahnya, yang mungkin merupakan parameter yang hilang dari panggilan prosedur tersimpan, membutuhkan beberapa menit untuk menyelesaikannya. Tetapi dengan model entitas apa pun, Anda akan selalu menjalankan debugger, mulai melangkah melalui kode, dan Anda mungkin berakhir dengan 15-20 file terbuka di Visual Studio. Pada saat Anda turun ke bagian bawah tumpukan, Anda lupa di mana Anda mulai. Kita hanya dapat menyimpan begitu banyak hal di kepala kita sekaligus. Perangkat lunak sangat kompleks tanpa menambahkan lapisan yang tidak perlu.

Kompleksitas pengembangan dan pemecahan masalah hanyalah satu sisi dari keluhan saya.

Sekarang mari kita bicara tentang skalabilitas.

Apakah pengembang menyadari bahwa setiap kali mereka menulis atau memodifikasi kode apa pun yang berinteraksi dengan database, mereka perlu melakukan analisis mendalam tentang dampak yang tepat pada database? Dan bukan hanya salinan pengembangan, maksud saya meniru produksi, sehingga Anda dapat melihat bahwa kolom tambahan yang sekarang Anda perlukan untuk objek Anda hanya membatalkan rencana kueri saat ini dan laporan yang berjalan dalam 1 detik sekarang akan memakan waktu 2 menit, hanya karena Anda menambahkan satu kolom ke daftar pilih? Dan ternyata indeks yang Anda butuhkan sekarang sangat besar sehingga DBA harus mengubah tata letak fisik file Anda?

Jika Anda membiarkan orang terlalu jauh dari penyimpanan data fisik dengan abstraksi, mereka akan membuat kekacauan dengan aplikasi yang perlu ditingkatkan.

Saya bukan orang fanatik. Saya dapat diyakinkan jika saya salah, dan mungkin saya salah, karena ada dorongan kuat ke Linq ke Sql, ADO.NET EF, Hibernate, Java EE, dll. Tolong pikirkan tanggapan Anda, jika saya kehilangan sesuatu, saya benar-benar ingin tahu apa itu, dan mengapa saya harus mengubah pemikiran saya.

[Sunting]

Sepertinya pertanyaan ini tiba-tiba aktif kembali, jadi sekarang kita memiliki fitur komentar baru, saya telah berkomentar langsung pada beberapa jawaban. Terima kasih atas balasannya, saya pikir ini adalah diskusi yang sehat.

Saya mungkin seharusnya lebih jelas bahwa saya berbicara tentang aplikasi perusahaan. Saya benar-benar tidak dapat mengomentari, katakanlah, game yang berjalan di desktop seseorang, atau aplikasi seluler.

Satu hal yang harus saya kemukakan di sini sebagai jawaban atas beberapa jawaban yang sama: ortogonalitas dan pemisahan kekhawatiran sering dikutip sebagai alasan untuk menjadi entitas / ORM. Prosedur yang tersimpan, bagi saya, adalah contoh terbaik dari pemisahan kekhawatiran yang dapat saya pikirkan. Jika Anda melarang semua akses lain ke database, selain melalui prosedur tersimpan, secara teori Anda dapat mendesain ulang seluruh model data Anda dan tidak merusak kode apa pun, asalkan Anda mempertahankan input dan output dari prosedur yang tersimpan. Mereka adalah contoh sempurna pemrograman berdasarkan kontrak (asalkan Anda menghindari "pilih *" dan mendokumentasikan set hasil).

Tanyakan pada seseorang yang sudah lama berkecimpung di industri ini dan telah bekerja dengan aplikasi yang berumur panjang: berapa banyak aplikasi dan lapisan UI yang datang dan pergi ketika database sudah ada? Seberapa sulit untuk memperbaiki dan memperbaiki database ketika ada 4 atau 5 lapisan ketekunan yang berbeda menghasilkan SQL untuk mendapatkan data? Anda tidak dapat mengubah apa pun! ORM atau kode apa pun yang menghasilkan SQL mengunci basis data Anda .

Saya pikir itu datang ke betapa rumitnya "logika" aplikasi tersebut, dan di mana Anda telah menerapkannya. Jika semua logika Anda dalam prosedur tersimpan, dan semua aplikasi Anda lakukan adalah memanggil prosedur itu dan menampilkan hasilnya, maka mengembangkan objek entitas memang buang-buang waktu. Tetapi untuk aplikasi di mana objek memiliki interaksi kaya satu sama lain, dan database hanyalah mekanisme ketekunan, mungkin ada nilai untuk memiliki objek tersebut.

Jadi, saya akan mengatakan tidak ada jawaban satu ukuran untuk semua. Pengembang perlu menyadari bahwa, kadang-kadang, mencoba menjadi terlalu OO dapat menyebabkan lebih banyak masalah daripada yang dipecahkan.

Teori mengatakan bahwa implementasi yang sangat kohesif, longgar digabungkan adalah jalan ke depan.

Jadi saya kira Anda mempertanyakan pendekatan itu, yaitu memisahkan kekhawatiran.

Haruskah file aspx.cs saya berinteraksi dengan database, memanggil sproc, dan memahami IDataReader?

Dalam lingkungan tim, terutama di mana Anda memiliki lebih sedikit orang teknis yang berurusan dengan bagian aspx dari aplikasi, saya tidak perlu orang-orang ini dapat "menyentuh" ​​hal ini.

Memisahkan domain saya dari basis data melindungi saya dari perubahan struktural dalam basis data, tentu hal yang baik? Tentu saja kemanjuran basis data sangat penting, jadi biarkan seseorang yang paling hebat dalam hal itu menangani hal-hal itu, di satu tempat, dengan dampak sesedikit mungkin pada sisa sistem.

Kecuali jika saya salah memahami pendekatan Anda, satu perubahan struktural dalam database dapat memiliki area dampak besar dengan permukaan aplikasi Anda. Saya melihat bahwa pemisahan kekhawatiran ini memungkinkan saya dan tim saya untuk meminimalkan hal ini. Juga setiap anggota tim yang baru harus memahami pendekatan ini dengan lebih baik.

Juga, pendekatan Anda tampaknya menganjurkan logika bisnis aplikasi Anda untuk berada di database Anda? Ini terasa salah bagi saya, SQL benar-benar bagus dalam menanyakan data, dan bukan, imho, yang mengekspresikan logika bisnis.

Namun pemikiran yang menarik, meskipun terasa satu langkah menjauh dari SQL di aspx, yang dari hari-hari buruk lama yang tidak terstruktur, membuat saya takut.

Satu alasan - memisahkan model domain Anda dari model database Anda.

Apa yang saya lakukan adalah menggunakan Test Driven Development jadi saya menulis UI dan lapisan Model saya terlebih dahulu dan lapisan Data diejek, sehingga UI dan model dibangun di sekitar objek domain tertentu, kemudian saya memetakan objek ini ke teknologi apa pun yang saya gunakan Lapisan Data. Itu ide yang buruk untuk membiarkan struktur database menentukan desain aplikasi Anda. Jika memungkinkan, tulis aplikasi terlebih dahulu dan biarkan itu memengaruhi struktur basis data Anda, bukan sebaliknya.

Bagi saya intinya adalah saya tidak ingin aplikasi saya peduli dengan bagaimana data disimpan. Saya mungkin akan ditampar karena mengatakan ini ... tetapi aplikasi Anda bukan data Anda, data adalah artefak dari aplikasi tersebut. Saya ingin aplikasi saya berpikir dalam hal Pelanggan, Pesanan dan Barang, bukan teknologi seperti DataSets, DataTables dan DataRows ... karena siapa yang tahu berapa lama mereka akan ada.

Saya setuju bahwa selalu ada sejumlah kopling, tapi saya lebih suka kopling itu menjangkau ke atas daripada ke bawah. Saya bisa men-tweak tungkai dan daun pohon lebih mudah daripada saya bisa mengubah batangnya.

Saya cenderung memesan sprocs untuk pelaporan karena permintaan cenderung sedikit lebih buruk daripada aplikasi akses data umum.

Saya juga cenderung berpikir dengan pengujian unit yang tepat sejak awal bahwa skenario seperti bahwa satu kolom tidak bertahan kemungkinan tidak menjadi masalah.

Eric, kamu sudah mati. Untuk setiap aplikasi yang benar-benar scalable / mudah dirawat / kuat, satu-satunya jawaban nyata adalah membuang semua sampah dan tetap pada dasarnya.

Saya telah mengikuti lintasan serupa dengan karier saya dan sampai pada kesimpulan yang sama. Tentu saja, kita dianggap bidat dan terlihat lucu. Tapi barang-barang saya bekerja dan bekerja dengan baik.

Setiap baris kode harus dilihat dengan kecurigaan.

Saya ingin menjawab dengan contoh yang mirip dengan yang Anda usulkan.

Di perusahaan saya, saya harus membuat bagian CRUD sederhana untuk produk, saya membangun semua entitas saya dan DAL yang terpisah. Kemudian pengembang lain harus mengubah tabel terkait dan dia bahkan mengganti nama beberapa bidang. Satu-satunya file yang harus saya ubah untuk memperbarui formulir saya adalah DAL untuk tabel itu.

Apa yang (menurut saya) entitas bawa ke proyek adalah:

Ortogonality: Perubahan dalam satu lapisan mungkin tidak mempengaruhi lapisan lain (tentu saja jika Anda membuat perubahan besar pada basis data, itu akan mengacak-acak semua lapisan tetapi kebanyakan perubahan kecil tidak akan).

Testabilitas: Anda dapat menguji logika Anda tanpa menyentuh basis data Anda. Ini meningkatkan kinerja pada tes Anda (memungkinkan Anda untuk menjalankannya lebih sering).

Pemisahan masalah: Dalam produk besar Anda dapat menetapkan basis data ke DBA dan dia bisa mengoptimalkannya. Tetapkan Model ke pakar bisnis yang memiliki pengetahuan yang diperlukan untuk mendesainnya. Tetapkan formulir individual untuk pengembang yang lebih berpengalaman di formulir web, dll.

Akhirnya saya ingin menambahkan bahwa sebagian besar pemetaan ORM mendukung prosedur tersimpan karena itulah yang Anda gunakan.

Bersulang.

Saya pikir Anda mungkin "menggigit lebih dari yang bisa Anda kunyah" pada topik ini. Ted Neward tidak sembrono ketika ia menyebutnya " Vietnam of Computer Science ".

Satu hal yang saya benar-benar dapat menjamin Anda adalah bahwa itu akan mengubah sudut pandang siapa pun tentang masalah ini, seperti yang telah terbukti begitu sering di blog, forum, podcast lain yang tak terhitung banyaknya.

Tentu boleh saja memiliki debat terbuka dan debat tentang topik kontroversial, hanya saja ini telah dilakukan berkali-kali sehingga kedua "pihak" sepakat untuk tidak setuju dan baru saja mulai menulis perangkat lunak.

Jika Anda ingin membaca lebih lanjut di kedua sisi, lihat artikel di blog Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans dll.

@Dan, maaf, itu bukan hal yang saya cari. Saya tahu teorinya. Pernyataan Anda "adalah ide yang sangat buruk" tidak didukung oleh contoh nyata. Kami mencoba mengembangkan perangkat lunak dalam waktu yang lebih singkat, dengan lebih sedikit orang, dengan lebih sedikit kesalahan, dan kami ingin kemampuan untuk dengan mudah melakukan perubahan. Model multi-layer Anda, menurut pengalaman saya, adalah negatif di semua kategori di atas. Terutama berkenaan dengan membuat model data hal terakhir yang Anda lakukan. Model data fisik harus menjadi pertimbangan penting dari hari 1.

Saya menemukan pertanyaan Anda sangat menarik.
Biasanya saya memerlukan objek entitas untuk merangkum logika bisnis suatu aplikasi. Akan sangat rumit dan tidak memadai untuk mendorong logika ini ke dalam lapisan data.
Apa yang akan Anda lakukan untuk menghindari objek entitas ini? Solusi apa yang ada dalam pikiran Anda?

Objek Entitas dapat memfasilitasi cache pada lapisan aplikasi. Semoga berhasil caching datareader.

Kita juga harus berbicara tentang gagasan entitas apa sebenarnya. Ketika saya membaca diskusi ini, saya mendapatkan kesan bahwa kebanyakan orang di sini melihat entitas dalam arti Model Domain Anemik . Banyak orang yang mempertimbangkan Model Domain Anemik sebagai antipengganti!

Ada nilai dalam model domain kaya. Itulah yang dimaksud dengan Domain Driven Design . Saya pribadi percaya bahwa OO adalah cara untuk menaklukkan kompleksitas. Ini berarti tidak hanya kompleksitas teknis (seperti akses data, pengikatan ui, keamanan ...) tetapi juga kompleksitas dalam domain bisnis !

Jika kita dapat menerapkan teknik OO untuk menganalisis, memodelkan, mendesain, dan mengimplementasikan masalah bisnis kita, ini adalah keuntungan luar biasa untuk pemeliharaan dan ekstensibilitas aplikasi non-sepele!

Ada perbedaan antara entitas Anda dan tabel Anda. Entitas harus mewakili model Anda, tabel hanya mewakili aspek data dari model Anda!

Memang benar bahwa data lebih lama daripada aplikasi, tetapi pertimbangkan kutipan dari David Laribee ini : Model selamanya ... data adalah efek samping yang menyenangkan.

Beberapa tautan lain tentang topik ini:

• Mengapa Setters dan Getters itu jahat

• Pengembalian OO murni

• POJO vs NOJO

• Super Model Bagian 2

• TDD, Mengolok-olok dan Desain

Pertanyaan yang sangat menarik. Jujur saya tidak bisa membuktikan mengapa entitas itu baik. Tapi saya bisa membagikan pendapat saya mengapa saya suka mereka. Seperti kode

void exportOrder(Order order, String fileName){...};

tidak peduli dari mana datangnya pesanan - dari DB, dari permintaan web, dari tes unit, dll. Itu membuat metode ini secara lebih eksplisit menyatakan apa yang sebenarnya dibutuhkan, alih-alih mengambil DataRow dan mendokumentasikan kolom mana yang diharapkan memiliki dan jenis apa yang harus mereka pesan. menjadi. Hal yang sama berlaku jika Anda mengimplementasikannya sebagai prosedur tersimpan - Anda masih perlu mendorong id rekaman ke sana, sementara itu tidak perlu harus ada dalam DB.

Implementasi metode ini akan dilakukan berdasarkan abstraksi Order, bukan berdasarkan bagaimana tepatnya disajikan dalam DB. Sebagian besar operasi yang saya implementasikan benar-benar tidak bergantung pada bagaimana data ini disimpan. Saya mengerti bahwa beberapa operasi memerlukan penggabungan dengan struktur DB untuk tujuan kinerja dan skalabilitas, hanya dalam pengalaman saya tidak ada terlalu banyak dari mereka. Dalam pengalaman saya sangat sering itu cukup untuk mengetahui bahwa Orang memiliki .getFirstName () mengembalikan String, dan .getAddress () mengembalikan Alamat, dan alamat memiliki .getZipCode (), dll - dan tidak peduli tabel mana yang terlibat untuk menyimpan data itu .

Jika Anda harus berurusan dengan masalah seperti yang Anda jelaskan, seperti ketika kolom tambahan memecah kinerja laporan, maka untuk tugas Anda DB adalah bagian penting, dan Anda memang harus sedekat mungkin dengan itu. Sementara entitas dapat memberikan beberapa abstraksi yang mudah, mereka dapat menyembunyikan beberapa detail penting juga.

Skalabilitas adalah poin yang menarik di sini - sebagian besar situs web yang membutuhkan skalabilitas yang sangat besar (seperti facebook, livejournal, flickr) cenderung menggunakan pendekatan asketis DB, ketika DB digunakan sesering mungkin dan masalah skalabilitas diselesaikan dengan caching, terutama dengan penggunaan RAM. http://highscalability.com/ memiliki beberapa artikel menarik di dalamnya.

Ada alasan bagus lainnya untuk objek entitas selain abstraksi dan kopling longgar. Salah satu hal yang paling saya sukai adalah pengetikan kuat yang tidak bisa Anda dapatkan dengan DataReader atau DataTable. Alasan lain adalah bahwa ketika dilakukan dengan baik, kelas entitas yang tepat dapat membuat kode lebih dapat dikelola dengan menggunakan konstruksi kelas satu untuk istilah khusus domain yang dapat dipahami oleh siapa pun yang melihat kode daripada sekelompok string dengan nama bidang di dalamnya yang digunakan untuk mengindeks DataRow. Prosedur tersimpan benar-benar ortogonal untuk penggunaan ORM karena banyak kerangka pemetaan memberi Anda kemampuan untuk memetakan ke sprocs.

Saya tidak akan menganggap sprocs + datareaders sebagai pengganti ORM yang baik. Dengan prosedur tersimpan, Anda masih dibatasi oleh, dan tergabung erat dengan, tipe tanda tangan prosedur, yang menggunakan sistem tipe yang berbeda dari kode panggilan. Prosedur tersimpan dapat dikenakan modifikasi untuk mengakomodasi opsi tambahan dan perubahan skema. Alternatif untuk prosedur tersimpan dalam kasus di mana skema dapat berubah adalah dengan menggunakan tampilan - Anda dapat memetakan objek untuk dilihat dan kemudian memetakan kembali tampilan ke tabel yang mendasarinya saat Anda mengubahnya.

Saya dapat memahami keengganan Anda untuk ORM jika pengalaman Anda terutama terdiri dari Java EE dan CSLA. Anda mungkin ingin melihat LINQ to SQL, yang merupakan kerangka kerja yang sangat ringan dan terutama pemetaan satu-ke-satu dengan tabel-tabel database tetapi biasanya hanya memerlukan ekstensi kecil agar objek-objek tersebut menjadi objek bisnis yang lengkap. LINQ ke SQL juga dapat memetakan objek input dan output ke parameter dan hasil prosedur tersimpan.

Kerangka kerja Entitas ADO.NET memiliki keuntungan tambahan bahwa tabel basis data Anda dapat dilihat sebagai kelas entitas yang diwarisi satu sama lain, atau sebagai kolom dari beberapa tabel yang dikumpulkan menjadi satu entitas. Jika Anda perlu mengubah skema, Anda dapat mengubah pemetaan dari model konseptual ke skema penyimpanan tanpa mengubah kode aplikasi yang sebenarnya. Dan lagi, prosedur tersimpan dapat digunakan di sini.

Saya pikir lebih banyak proyek TI di perusahaan gagal karena kode yang tidak dapat dipastikan atau produktivitas pengembang yang buruk (yang dapat terjadi dari, misalnya, pengalihan konteks antara penulisan spro dan penulisan aplikasi) daripada masalah skalabilitas aplikasi.

Saya juga ingin menambahkan jawaban Dan bahwa memisahkan kedua model dapat memungkinkan aplikasi Anda dijalankan pada server basis data yang berbeda atau bahkan model basis data.

Bagaimana jika Anda perlu mengatur skala aplikasi Anda dengan memuat balancing lebih dari satu server web? Anda dapat menginstal aplikasi lengkap di semua server web, tetapi solusi yang lebih baik adalah membuat server web berbicara dengan server aplikasi.

Tetapi jika tidak ada objek entitas, mereka tidak akan memiliki banyak hal untuk dibicarakan.

Saya tidak mengatakan bahwa Anda tidak boleh menulis monolith jika itu adalah aplikasi yang sederhana, internal, dan singkat. Tetapi segera setelah itu menjadi cukup kompleks, atau harus bertahan dalam waktu yang signifikan, Anda benar-benar perlu memikirkan desain yang baik.

Ini menghemat waktu untuk mempertahankannya.

Dengan memisahkan logika aplikasi dari logika presentasi dan akses data, dan dengan melewatkan DTO di antara mereka, Anda memisahkan mereka. Mengizinkan mereka berubah secara mandiri.

Anda mungkin menemukan posting ini di comp.object menarik.

Saya tidak mengklaim setuju atau tidak setuju tetapi ini menarik dan (saya pikir) relevan dengan topik ini.

Sebuah pertanyaan: Bagaimana Anda menangani aplikasi yang terputus jika semua logika bisnis Anda terjebak dalam database?

Dalam jenis aplikasi Enterprise yang saya minati, kita harus berurusan dengan banyak situs, beberapa di antaranya harus dapat berfungsi dalam keadaan terputus.
Jika logika bisnis Anda diringkas dalam lapisan Domain yang mudah untuk dimasukkan ke dalam berbagai jenis aplikasi - katakanlah dll- maka saya dapat membangun aplikasi yang mengetahui aturan bisnis dan dapat, bila perlu, menerapkannya secara lokal.

Dalam menjaga lapisan Domain dalam prosedur tersimpan pada basis data, Anda harus tetap menggunakan satu jenis aplikasi yang membutuhkan garis pandang permanen ke basis data.

Tidak masalah untuk kelas lingkungan tertentu, tetapi tentu saja tidak mencakup seluruh spektrum aplikasi Enterprise .

@ jdecuyper, salah satu pepatah yang sering saya ulangi pada diri saya sendiri adalah "jika logika bisnis Anda tidak ada dalam database Anda, itu hanya rekomendasi". Saya pikir Paul Nielson mengatakan itu di salah satu bukunya. Lapisan aplikasi dan UI datang dan pergi, tetapi data biasanya hidup untuk waktu yang sangat lama.

Bagaimana cara menghindari objek entitas? Prosedur tersimpan kebanyakan. Saya juga dengan bebas mengakui bahwa logika bisnis cenderung menjangkau seluruh lapisan dalam suatu aplikasi baik Anda bermaksud atau tidak. Sejumlah kopling melekat dan tidak dapat dihindari.

Saya telah memikirkan hal yang sama belakangan ini; Saya adalah pengguna berat CSLA untuk sementara waktu, dan saya suka kemurnian mengatakan bahwa "semua logika bisnis Anda (atau setidaknya sebanyak mungkin yang masuk akal) dienkapsulasi dalam entitas bisnis".

Saya telah melihat model entitas bisnis memberikan banyak nilai dalam kasus di mana desain basis data berbeda dari cara Anda bekerja dengan data, yang merupakan kasus dalam banyak perangkat lunak bisnis.

Misalnya, gagasan tentang "pelanggan" dapat terdiri dari catatan utama dalam tabel Pelanggan, dikombinasikan dengan semua pesanan yang telah ditempatkan pelanggan, serta semua karyawan pelanggan dan informasi kontak mereka, dan beberapa properti dari seorang pelanggan dan anak-anaknya dapat ditentukan dari tabel pencarian. Sangat bagus dari sudut pandang pengembangan untuk dapat bekerja dengan Pelanggan sebagai entitas tunggal, karena dari perspektif bisnis, konsep Pelanggan mengandung semua hal ini, dan hubungan tersebut mungkin atau mungkin tidak ditegakkan dalam basis data.

Sementara saya menghargai kutipan bahwa "jika aturan bisnis Anda tidak ada dalam database Anda, itu hanya saran", saya juga percaya bahwa Anda tidak boleh mendesain database untuk menegakkan aturan bisnis, Anda harus mendesainnya agar efisien, cepat, dan dinormalisasi. .

Yang mengatakan, seperti yang orang lain catat di atas, tidak ada "desain sempurna", alat harus sesuai dengan pekerjaan. Tetapi menggunakan entitas bisnis dapat sangat membantu dalam pemeliharaan dan produktivitas, karena Anda tahu ke mana harus mengubah logika bisnis, dan objek dapat memodelkan konsep dunia nyata dengan cara yang intuitif.

Eric,

Tidak ada yang menghentikan Anda dari memilih kerangka / pendekatan yang Anda inginkan. Jika Anda akan pergi jalur "data didorong / disimpan prosedur-powered", maka dengan segala cara, pergi untuk itu! Terutama jika itu benar-benar membantu Anda mengirimkan aplikasi Anda secara langsung dan tepat waktu.

Peringatannya adalah (kebalikan dari pertanyaan Anda), SEMUA aturan bisnis Anda harus pada prosedur tersimpan, dan aplikasi Anda tidak lebih dari klien yang kurus.

Yang sedang berkata, aturan yang sama berlaku jika Anda melakukan aplikasi Anda di OOP: konsisten. Ikuti prinsip OOP, dan itu termasuk membuat objek entitas untuk mewakili model domain Anda.

Satu-satunya aturan nyata di sini adalah konsistensi kata . Tidak ada yang menghentikan Anda dari pergi DB-sentris. Tidak ada yang menghentikan Anda dari melakukan program terstruktur sekolah lama (alias, fungsional / prosedural). Sial, tidak ada yang menghentikan siapa pun dari melakukan kode gaya COBOL. TETAPI aplikasi harus sangat, sangat konsisten setelah melewati jalan ini, jika ingin mencapai tingkat kesuksesan apa pun.

Saya benar-benar tidak yakin apa yang Anda anggap "Aplikasi Perusahaan". Tapi saya mendapat kesan Anda mendefinisikannya sebagai Aplikasi Internal di mana RDBMS akan dibuat mati dan sistem tidak harus dapat dioperasikan dengan sistem lain baik internal maupun eksternal.

Tetapi bagaimana jika Anda memiliki database dengan 100 tabel yang setara dengan 4 Prosedur Tersimpan untuk setiap tabel hanya untuk operasi CRUD dasar itu 400 prosedur tersimpan yang perlu dipelihara dan tidak diketik dengan kuat sehingga rentan terhadap kesalahan pengetikan juga tidak dapat diuji Unit. . Apa yang terjadi ketika Anda mendapatkan CTO baru yang merupakan Penginjil Sumber Terbuka dan ingin mengubah RDBMS dari SQL Server ke MySql?

Banyak perangkat lunak saat ini baik Aplikasi Perusahaan atau Produk menggunakan SOA dan memiliki beberapa persyaratan untuk mengekspos Layanan Web, setidaknya perangkat lunak saya dan telah terlibat. Dengan menggunakan pendekatan Anda, pada akhirnya Anda akan mengekspos Serialized DataTable atau DataRows. Sekarang ini dapat dianggap dapat diterima jika Klien dijamin .NET dan di jaringan internal. Tetapi ketika Klien tidak dikenal maka Anda harus berusaha untuk Merancang API yang intuitif dan dalam kebanyakan kasus Anda tidak ingin mengekspos skema Database Lengkap. Saya tentu tidak ingin menjelaskan kepada pengembang Java apa itu DataTable dan bagaimana menggunakannya. Ada juga pertimbangan Bandwith dan ukuran muatan serta DataTables berseri, DataSet sangat berat.

Tidak ada peluru perak dengan desain perangkat lunak dan itu benar-benar tergantung pada di mana prioritas terletak, bagi saya itu dalam kode Unit Testable dan komponen yang digabungkan secara longgar yang dapat dengan mudah dikonsumsi menjadi klien apa pun.

hanya 2 sen saya

Saya ingin menawarkan sudut lain untuk masalah jarak antara OO dan RDB: sejarah.

Setiap perangkat lunak memiliki model realitas yang pada tingkat tertentu merupakan abstraksi realitas. Tidak ada program komputer yang dapat menangkap semua kompleksitas realitas, dan program ditulis hanya untuk menyelesaikan serangkaian masalah dari kenyataan. Oleh karena itu setiap model perangkat lunak adalah pengurangan dari kenyataan. Terkadang model perangkat lunak memaksa kenyataan untuk mengurangi dirinya sendiri. Seperti ketika Anda ingin perusahaan penyewaan mobil memesankan mobil untuk Anda selama warnanya biru dan memiliki paduan, tetapi operator tidak dapat mematuhinya karena permintaan Anda tidak akan sesuai dengan komputer.

RDB berasal dari tradisi yang sangat lama memasukkan informasi ke dalam tabel, yang disebut akuntansi. Akuntansi dilakukan di atas kertas, kemudian pada kartu punch, kemudian di komputer. Tetapi akuntansi sudah merupakan pengurangan realitas. Akuntansi telah memaksa orang untuk mengikuti sistemnya begitu lama sehingga telah menjadi kenyataan yang diterima. Itu sebabnya relatif mudah untuk membuat perangkat lunak komputer untuk akuntansi, akuntansi telah memiliki model informasinya, jauh sebelum komputer datang.

Mengingat pentingnya sistem akuntansi yang baik, dan penerimaan yang Anda dapatkan dari manajer bisnis mana pun, sistem ini telah menjadi sangat maju. Yayasan basis data sekarang sangat solid dan tidak ada yang ragu untuk menyimpan data penting dalam sesuatu yang dapat dipercaya.

Saya kira OO pasti muncul ketika orang menemukan bahwa aspek lain dari kenyataan lebih sulit untuk dimodelkan daripada akuntansi (yang sudah menjadi model). OO telah menjadi ide yang sangat sukses, tetapi data OO yang bertahan relatif kurang berkembang. RDB / Akuntansi telah menang dengan mudah, tetapi OO adalah bidang yang jauh lebih besar (pada dasarnya segala sesuatu yang bukan akuntansi).

Banyak dari kita yang ingin menggunakan OO tetapi kita masih menginginkan penyimpanan data yang aman. Apa yang bisa lebih aman daripada menyimpan data kami dengan cara yang sama seperti yang dilakukan oleh sistem akuntansi yang terhormat? Ini adalah prospek yang menarik, tetapi kita semua mengalami kesulitan yang sama. Sangat sedikit yang mengambil kesulitan untuk memikirkan kegigihan OO dibandingkan dengan upaya besar-besaran oleh industri RDB, yang telah mendapatkan manfaat dari tradisi dan posisi akuntansi.

Prevayler dan db4o adalah beberapa saran, saya yakin ada orang lain yang belum pernah saya dengar, tetapi tidak ada yang mendapatkan setengah dari pers, misalnya, hibernasi.

Menyimpan objek Anda dalam file-file lama yang bagus bahkan tampaknya tidak dianggap serius untuk aplikasi multi-pengguna, dan terutama aplikasi web.

Dalam perjuangan sehari-hari saya untuk menutup jurang antara OO dan RDB saya menggunakan OO sebanyak mungkin tetapi mencoba untuk menjaga warisan seminimal mungkin. Saya tidak sering menggunakan SP. Saya akan menggunakan hal-hal permintaan lanjutan hanya dalam aspek yang tampak seperti akuntansi.

Saya akan dengan senang hati dikurung saat jurangnya ditutup untuk selamanya. Saya pikir solusinya akan datang ketika Oracle meluncurkan sesuatu seperti "Oracle Object Instance Base". Untuk benar-benar memahami, itu harus memiliki nama yang meyakinkan.

Tidak banyak waktu saat ini, tetapi tepat di atas kepala saya ...

Model entitas memungkinkan Anda memberikan antarmuka yang konsisten ke basis data (dan sistem lain yang mungkin) bahkan melampaui apa yang dapat dilakukan antarmuka prosedur tersimpan. Dengan menggunakan model bisnis skala perusahaan Anda dapat memastikan bahwa semua aplikasi memengaruhi data secara konsisten yang merupakan hal yang SANGAT penting. Kalau tidak, Anda berakhir dengan data buruk, yang benar-benar jahat.

Jika Anda hanya memiliki satu aplikasi maka Anda tidak benar-benar memiliki sistem "perusahaan", terlepas dari seberapa besar aplikasi itu atau data Anda. Dalam hal ini Anda dapat menggunakan pendekatan yang mirip dengan apa yang Anda bicarakan. Sadarilah pekerjaan yang akan dibutuhkan jika Anda memutuskan untuk mengembangkan sistem Anda di masa depan.

Berikut adalah beberapa hal yang harus Anda ingat (IMO):

1. Kode SQL yang dihasilkan buruk (pengecualian untuk diikuti). Maaf, saya tahu bahwa banyak orang berpikir bahwa ini adalah penghemat waktu yang sangat besar, tetapi saya tidak pernah menemukan sistem yang dapat menghasilkan kode yang lebih efisien daripada yang dapat saya tulis dan sering kali kode itu benar-benar mengerikan. Anda juga sering berakhir menghasilkan satu ton kode SQL yang tidak pernah digunakan. Pengecualian di sini adalah pola yang sangat sederhana, seperti mungkin tabel pencarian. Banyak orang terbawa karenanya.
2. Entitas <> Tabel (atau entitas model data logis tentu saja). Model data sering memiliki aturan data yang harus ditegakkan sedekat mungkin dengan database yang dapat mencakup aturan seputar bagaimana baris tabel saling berhubungan satu sama lain atau aturan serupa lainnya yang terlalu rumit untuk deklaratif RI. Ini harus ditangani dalam prosedur tersimpan. Jika semua prosedur tersimpan Anda adalah proksi CRUD sederhana, Anda tidak bisa melakukan itu. Selain itu, model CRUD biasanya menciptakan masalah kinerja karena tidak meminimalkan perjalanan bolak-balik di jaringan ke database. Itu sering menjadi hambatan terbesar dalam aplikasi perusahaan.

Terkadang, aplikasi dan lapisan data Anda tidak terlalu erat. Misalnya, Anda mungkin memiliki aplikasi penagihan telepon. Anda kemudian membuat aplikasi terpisah yang memonitor penggunaan telepon untuk a) beriklan lebih baik kepada Anda b) mengoptimalkan rencana telepon Anda.

Aplikasi ini memiliki masalah dan persyaratan data yang berbeda (bahkan data keluar dari database yang sama), mereka akan mendorong desain yang berbeda. Basis kode Anda dapat berakhir berantakan total (di salah satu aplikasi) dan mimpi buruk untuk dipertahankan jika Anda membiarkan basis data menggerakkan kode.

Aplikasi yang memiliki logika domain terpisah dari logika penyimpanan data dapat beradaptasi dengan segala jenis sumber data (database atau lainnya) atau aplikasi UI (web atau windows (atau linux dll)).

Anda cukup banyak terjebak dalam database Anda, yang tidak buruk jika Anda dengan perusahaan yang puas dengan sistem database saat ini yang Anda gunakan. Namun, karena database berevolusi dari waktu ke waktu, mungkin ada sistem database baru yang benar-benar rapi dan baru yang ingin digunakan perusahaan Anda. Bagaimana jika mereka ingin beralih ke metode layanan data untuk akses data (seperti Arsitektur Berorientasi Layanan kadang-kadang melakukannya). Anda mungkin harus porting prosedur tersimpan Anda di semua tempat.

Juga logika domain mengabstraksi UI, yang bisa lebih penting dalam sistem kompleks besar yang pernah mengembangkan UI (terutama ketika mereka terus-menerus mencari lebih banyak pelanggan).

Juga, sementara saya setuju bahwa tidak ada jawaban pasti untuk pertanyaan tentang prosedur tersimpan versus logika domain. Saya di kamp logika domain (dan saya pikir mereka menang dari waktu ke waktu), karena saya percaya bahwa prosedur tersimpan yang rumit lebih sulit dipertahankan daripada logika domain rumit. Tapi itu perdebatan lain

Saya pikir Anda hanya terbiasa menulis aplikasi jenis tertentu, dan menyelesaikan masalah jenis tertentu. Anda tampaknya menyerang ini dari perspektif "basis data pertama". Ada banyak pengembang di luar sana di mana data bertahan ke DB tetapi kinerja bukan prioritas utama. Dalam banyak kasus meletakkan abstraksi di atas lapisan persistensi menyederhanakan kode dengan sangat dan biaya kinerja adalah bukan masalah.

Apa pun yang Anda lakukan, itu bukan OOP. Itu tidak salah, itu hanya bukan OOP, dan tidak masuk akal untuk menerapkan solusi Anda untuk setiap masalah lain di luar sana.

Pertanyaan menarik. Beberapa pemikiran:

1. Bagaimana Anda menguji unit jika semua logika bisnis Anda ada di database Anda?
2. Tidakkah perubahan pada struktur basis data Anda, khususnya yang memengaruhi beberapa halaman di aplikasi Anda, akan menjadi masalah besar untuk berubah di seluruh aplikasi?

Pertanyaan bagus!

Salah satu pendekatan yang saya suka adalah membuat objek iterator / generator yang memancarkan instance objek yang relevan dengan konteks tertentu. Biasanya objek ini membungkus beberapa hal akses database yang mendasarinya, tetapi saya tidak perlu mengetahuinya saat menggunakannya.

Sebagai contoh,

Objek AnswerIterator menghasilkan objek AnswerIterator. Menjawab objek. Di bawah tenda itu iterasi atas Pernyataan SQL untuk mengambil semua jawaban, dan pernyataan SQL lain untuk mengambil semua komentar terkait. Tetapi ketika menggunakan iterator saya hanya menggunakan objek Jawab yang memiliki properti minimum untuk konteks ini. Dengan sedikit kode kerangka ini menjadi hampir sepele untuk dilakukan.

Saya telah menemukan bahwa ini bekerja dengan baik ketika saya memiliki set data yang besar untuk dikerjakan, dan ketika dilakukan dengan benar, itu memberi saya objek kecil, sementara yang relatif mudah untuk diuji.

Ini pada dasarnya lapisan tipis atas hal-hal Akses Database, tetapi masih memberi saya fleksibilitas untuk mengabstraksi ketika saya perlu.

Objek dalam aplikasi saya cenderung menghubungkan satu-ke-satu dengan database, tapi saya menemukan menggunakan Linq To Sql daripada sprocs membuatnya lebih mudah menulis kueri rumit, terutama bisa membangunnya menggunakan eksekusi yang ditangguhkan. mis. dari r di Images.User.Ratings di mana dll. Ini menyelamatkan saya mencoba untuk bekerja beberapa pernyataan bergabung dalam sql, dan memiliki Lewati & Ambil untuk paging juga menyederhanakan kode daripada harus menanamkan kode row_number & 'over'.

Mengapa berhenti di objek entitas? Jika Anda tidak melihat nilai dengan objek entitas di aplikasi tingkat perusahaan, maka cukup lakukan akses data Anda dalam bahasa fungsional / murni prosedural dan kirimkan ke UI. Mengapa tidak memotong semua "bulu" OO?