Apa gunanya Lapisan Logika Bisnis (BLL)?


14

Dalam membaca praktik yang baik untuk aplikasi basis data, saya sering menemui pendukung yang disebut "lapisan logika bisnis" dan saya mencoba memutuskan apakah yang terbaik untuk proyek saya untuk menggunakannya (ini adalah proyek pribadi kecil). Masalah saya terletak pada kenyataan bahwa saya tidak bisa memikirkan apa pun untuk BLL untuk melakukan hal yang DAL tidak bisa menangani (mengeksekusi query dan memetakan hasil ke objek), jadi BLL saya hanya memanggil DAL tanpa melakukan apa-apa sendiri.

Mungkin saya salah tentang apa yang seharusnya dilakukan DAL juga. Tetapi terlepas dari itu, fungsionalitas macam apa yang diharapkan dari BLL dalam aplikasi manajemen basis data?


Kedengarannya seperti efisiensi vs fleksibilitas / kode menggunakan kembali dilema.
Pekerjaan

@ Pekerjaan - Ya, semacam, terutama karena ini adalah aplikasi kecil dengan sedikit kemungkinan penggunaan kembali kode (belum). Tetapi sebagian juga mencoba menggunakan praktik terbaik yang ada.
Andrew Arnold

Saya membesarkan hati semua orang karena semuanya adalah jawaban yang luar biasa; sayangnya saya hanya bisa menerimanya.
Andrew Arnold

Jawaban:


10

Untuk aplikasi saya yang lebih kecil, BLL saya biasanya dimulai sebagai pass-through ke DAL. Saya baik-baik saja dengan itu. Ketika saya "menemukan" aturan bisnis, BLL adalah tempat saya meletakkannya. Saya juga akhirnya menemukan banyak hal yang diperlukan di BLL ketika saya menulis tes saya. Untuk aplikasi pribadi saya, saya membuat aturan bisnis, dan BLL masih di tempat saya meletakkannya. Bagi saya, BLL adalah sesuatu yang tumbuh seiring waktu. Semakin lama saya mengerjakan proyek, semakin besar BLL-nya.

Apakah saya akan mempertimbangkan menggabungkan BLL dan DAL untuk proyek kecil? Saya mungkin, kecuali kenyataan bahwa saya mengubah teknologi DAL sesering saya mengubah gaya rambut, dan saya suka memiliki sesuatu untuk mengisolasi kode klien saya dari itu.


2
Saya belum mengubah gaya rambut saya dalam 20 tahun. Saya benci mengubah teknologi DAL saya sesering saya mengubah gaya rambut.
Erik Funkenbusch

3
Beberapa orang juga memperbarui DAL mereka setiap 20 tahun juga!
Marcie

4
Jawaban yang bagus. Adalah umum untuk proyek-proyek kecil untuk benar-benar tidak memiliki banyak untuk dimasukkan ke dalam BLL. Ini juga umum untuk proyek-proyek kecil untuk tumbuh lebih besar, dan jika Anda tidak memiliki setidaknya shell BLL di tempat, jumlah logika yang meningkat akan terakumulasi di lapisan presentasi atau DAL, yang keduanya tidak secara khusus diinginkan.
Carson63000

5

BLL akan menangani hal-hal yang merupakan bagian dari domain bisnis, bukan bagian dari database, dan bukan bagian dari UI (biasanya). Misalnya, menggunakan usia pelanggan untuk menentukan apakah mereka memenuhi syarat untuk diskon khusus senior. DAL seharusnya tidak melakukan ini, ia hanya harus mengambil data pelanggan, dan kemudian menyimpannya dengan data diskon setelah BLL melakukan tugasnya. DAL harus lebih fokus pada CRUD. Dalam aplikasi kecil, kedua masalah tersebut mungkin tumpang tindih.


Sebenarnya, ini adalah bagian dari masalah dengan mencoba mengisolasi "tingkatan" atau "lapisan" seperti ini. Sering kali, sesuatu harus melintasi lapisan karena lebih cocok di lapisan yang berbeda itu. Contoh yang bagus adalah query SQL yang memiliki logika bisnis. Perhitungan umur Anda, misalnya, dapat sepenuhnya dilakukan di lapisan SQL (atau ORM) lebih efisien.
Erik Funkenbusch

2
@Mystere Man Lebih efisien bersifat subyektif. Komentar itu berarti Anda tahu apa yang terjadi di front-end. Sifatnya sangat statis. Memanfaatkan query SQL untuk mengoptimalkan data pasti tetapi ada garis tipis saat Anda mulai mengikat UI ke back-end.
Aaron McIver

1
@Mystere Man: Memang bisa. Dan seringkali benar bahwa hal-hal "berdarah" dari satu lapisan ke lapisan lainnya. Seni nyata dalam memisahkan mereka dan menjaga mereka terpisah. Saya tahu, itu tidak selalu mudah ...
FrustratedWithFormsDesigner

1
Dan boom , optimasi prematur meningkatkan kepalanya yang buruk! Saya merasa sulit untuk membayangkan bahwa perbandingan tanggal yang sederhana adalah hambatan yang mengharuskan memindahkan aturan bisnis ke DAL. Pemeliharaan harus menjadi tujuan juga, bukan hanya kecepatan.
TMN

5

Andrew,

Lapisan logika bisnis adalah apa yang Anda dapatkan ketika Anda melakukan pengembangan berbasis domain dan fokus pada kegiatan inti domain. Jika Anda menghapus lapisan presentasi (gui, web) dan lapisan infrastruktur (db, konektivitas jaringan, dll.), Anda memiliki aset inti yang merupakan bagian dari domain Anda, seperti menyetor uang ke rekening bank. Sekarang jika Anda telah memodelkan lapisan bisnis Anda dan mengisolasinya dari presentasi dan infrastruktur, Anda dapat dengan mudah memindahkannya ke penggunaan lain, seperti web atau perangkat seluler. Ini cara yang bersih untuk memikirkan pengembangan dan dari apa yang saya lihat, sayangnya tidak ditanggapi dengan serius.

Saya merekomendasikan Anda untuk menggunakan Eric Evans - Domain Driven Design, yang merupakan buku bagus yang membenarkan upaya pengembangan fokus pada domain. Harus diakui, ini agak sulit untuk dibaca, tetapi ini memang membangun momentum dan memiliki beberapa keyakinan kuat tentang apa yang dilakukan pengembang yang salah dengan sistem saat ini.


4

Tidak ada yang mengatakan Anda HARUS memiliki sejumlah tingkatan atau lapisan. Itu semua tergantung pada kompleksitas proyek Anda. Lihatlah banyak aplikasi sampel MVC, seperti nerd dinner atau record store .. semuanya menggunakan 2 layer karena untuk aplikasi yang memiliki logika pemrosesan sangat sedikit, itu tidak masuk akal.

Namun, bahkan jika aplikasi Anda kecil, itu mungkin mendapat manfaat dari abstrak lapisan data dari lapisan presentasi melalui lapisan ketiga yang biasanya menjadi lapisan bisnis. Ini memungkinkan Anda membuat perubahan di satu tempat, bukan di seluruh lapisan presentasi Anda.

Misalkan Anda memutuskan untuk mengubah ORM Anda dari Linq ke SQL ke Entity Framework (atau nhibernate). Mungkin akan lebih mudah untuk mengubahnya di lapisan bisnis daripada di lapisan presentasi Anda, karena presentasi cenderung berpasangan dengan model presentasi itu.

Jika Anda memahami MVC, yaitu .. Model View Controller, Anda dapat memikirkan arsitektur aplikasi Anda dalam istilah yang sama. Model ini mirip dengan lapisan data Anda, lapisan Presentasi adalah tampilan, dan Lapisan Bisnis adalah Pengontrol.


4

Melengkapi jawaban Desolate Planet tentang Domain Driven Design:

Lihat juga The Onion Architecture , yang sangat selaras dengan konsep Domain Driven Design.

Perhatikan bagaimana "Lapisan" Logika Bisnis adalah inti dari bawang merah dan setiap lapisan infrastruktur (seperti lapisan akses data) adalah ketergantungan luarnya. Ini banyak membantu pengujian, karena Anda harus dapat mengejek setiap ketergantungan infrastruktur eksternal dan sepenuhnya menguji logika domain Anda.

Menurut pendapat saya: Lapisan Logika Bisnis adalah tempat "solusi konseptual murni" hidup. Sisanya hanyalah detail implementasi infrastruktur.

Namun, beberapa aplikasi mungkin tidak memerlukan arsitektur semacam ini. Jika semua aplikasi Anda adalah operasi dataset CRUD, 'solusi konseptual murni' Anda mungkin bisa dibilang kosong dan yang Anda butuhkan hanyalah pengeditan basis data. Dalam hal ini, Anda mungkin sebaiknya fokus pada layer DAL dan UI saja.


1

Jawaban untuk pertanyaan ini adalah (IMHO): "bisakah saya mengganti DAL saya sepenuhnya dan tidak perlu menulis ulang kode logika bisnis saya"?

Anggap saja seperti lapisan presentasi Anda - cukup umum untuk berpikir mengubah GUI untuk yang berbeda, GUI desktop yang tebal akan ditukar untuk klien web, yang ditukar untuk aplikasi iPhone. Ini tidak begitu umum untuk berpikir seperti ini untuk BLL / DAL karena mereka tidak pernah benar-benar ditukar kecuali mungkin untuk sesuatu yang sangat mirip (misalnya DB SQLServer diganti dengan yang MySQL), tetapi jika Anda bayangkan Anda harus mengubah DB Anda ke penyimpanan terdistribusi layanan yang diakses menggunakan API, Anda mungkin mendapatkan ide yang lebih jelas tentang di mana lapisan bertemu.

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.