Business Logic Layer (BLL) ใช้อะไร?

ในการอ่านแนวปฏิบัติที่ดีสำหรับแอปพลิเคชันฐานข้อมูลฉันเจอผู้สนับสนุนที่เรียกว่า "เลเยอร์ตรรกะทางธุรกิจ" บ่อยครั้งและฉันพยายามตัดสินใจว่าควรใช้โครงการใดดีที่สุด (เป็นโครงการส่วนตัวขนาดเล็ก) ปัญหาของฉันอยู่ที่ข้อเท็จจริงที่ว่าฉันไม่สามารถคิดอะไรได้เลยสำหรับ BLL ที่จะทำเช่นนั้น DAL ไม่สามารถจัดการได้ (ดำเนินการแบบสอบถามและผลลัพธ์การจับคู่กับวัตถุ) ดังนั้น BLL ของฉันจึงเรียก DAL โดยไม่ทำอะไรเลย

บางทีฉันผิดเกี่ยวกับสิ่งที่ DAL ควรทำเช่นกัน แต่ไม่ว่าจะมีฟังก์ชั่นอะไรบ้างที่คาดว่าน่าจะเป็น BLL ในแอพพลิเคชั่นการจัดการฐานข้อมูล?

สำหรับแอปพลิเคชันขนาดเล็กของฉัน BLL ของฉันมักจะเริ่มต้นจากการส่งผ่านไปยัง DAL ฉันไม่เป็นไร เมื่อฉัน "ค้นพบ" กฎเกณฑ์ทางธุรกิจ BLL เป็นที่ที่ฉันวางไว้ ฉันยังพบสิ่งที่จำเป็นมากมายใน BLL เมื่อฉันเขียนแบบทดสอบ สำหรับแอพส่วนบุคคลของฉันเองฉันทำตามกฎเกณฑ์ทางธุรกิจและ BLL ยังคงเป็นตำแหน่งที่ฉันวางไว้ สำหรับฉัน BLL เป็นสิ่งที่เติบโตตลอดเวลา ยิ่งฉันทำงานโครงการนานขึ้นเท่าไหร่ BLL ก็ยิ่งใหญ่ขึ้นเท่านั้น

ฉันจะพิจารณารวม BLL และ DAL เข้ากับโครงการขนาดเล็กหรือไม่ ฉันอาจยกเว้นว่าฉันเปลี่ยนเทคโนโลยี DAL บ่อยเท่าที่ฉันเปลี่ยนทรงผมและฉันชอบที่จะมีบางสิ่งบางอย่างเพื่อแยกรหัสลูกค้าของฉันจากสิ่งนั้น

BLL จะจัดการสิ่งต่าง ๆ ที่เป็นส่วนหนึ่งของโดเมนธุรกิจไม่ใช่ส่วนหนึ่งของฐานข้อมูลและไม่ใช่ส่วนหนึ่งของ UI (โดยปกติ) ตัวอย่างเช่นการใช้อายุของลูกค้าเพื่อตรวจสอบว่าพวกเขามีสิทธิ์ได้รับส่วนลดอาวุโสของพิเศษ DAL ไม่ควรทำสิ่งนี้เพียงแค่ดึงข้อมูลลูกค้าจากนั้นจัดเก็บข้อมูลส่วนลดหลังจาก BLL ทำงานเสร็จแล้ว DAL ควรมุ่งเน้นที่ CRUD มากขึ้น ในแอปพลิเคชันขนาดเล็กทั้งสองข้อกังวลอาจทับซ้อน

แอนดรู

เลเยอร์ตรรกะทางธุรกิจคือสิ่งที่คุณจะได้รับเมื่อคุณพัฒนาและขับเคลื่อนโดเมนโดยมุ่งเน้นที่กิจกรรมหลักของโดเมน หากคุณตัดเลเยอร์การนำเสนอ (gui, เว็บ) และเลเยอร์โครงสร้างพื้นฐาน (db, การเชื่อมต่อเครือข่ายและอื่น ๆ ) คุณจะมี acitivies หลักที่เป็นส่วนหนึ่งของโดเมนของคุณเช่นการฝากเงินเข้าบัญชีธนาคาร ตอนนี้ถ้าคุณจำลองโมเดลเลเยอร์ธุรกิจของคุณและแยกมันออกจากการนำเสนอและโครงสร้างพื้นฐานคุณสามารถย้ายพอร์ตไปยังการใช้งานอื่น ๆ ได้อย่างง่ายดายเช่นเว็บหรืออุปกรณ์มือถือ มันเป็นวิธีที่สะอาดในการคิดเกี่ยวกับการพัฒนาและจากสิ่งที่ฉันเห็นมันไม่ได้นำสิ่งที่น่าเสียดายอย่างจริงจัง

ฉันขอแนะนำให้จับอีริคอีแวนส์ - การออกแบบการขับเคลื่อนด้วยโดเมนซึ่งเป็นหนังสือที่ดีที่แสดงให้เห็นถึงการมุ่งเน้นการพัฒนาบนโดเมน เป็นที่ทราบกันดีว่าเป็นเรื่องที่อ่านได้ยาก แต่ก็เป็นการสร้างแรงผลักดันและมีความเชื่อมั่นอย่างมากเกี่ยวกับสิ่งที่นักพัฒนาทำผิดกับระบบในปัจจุบัน

ไม่มีอะไรที่บอกว่าคุณจะต้องมีระดับหรือเลเยอร์จำนวนหนึ่ง ทุกอย่างขึ้นอยู่กับความซับซ้อนของโครงการของคุณ ลองดูที่แอปตัวอย่าง MVC จำนวนมากเช่น nerd dinner หรือ record store .. พวกเขาใช้ 2 เลเยอร์เพราะสำหรับแอปพลิเคชันที่มีตรรกะการประมวลผลน้อยมากมันก็ไม่สมเหตุสมผล

อย่างไรก็ตามแม้ว่าแอปของคุณจะเล็ก แต่ก็อาจได้รับประโยชน์จากการแยกชั้นข้อมูลออกจากเลเยอร์การนำเสนอผ่านเลเยอร์ที่สามซึ่งโดยปกติจะเป็นเลเยอร์ธุรกิจ สิ่งนี้ช่วยให้คุณสามารถทำการเปลี่ยนแปลงได้ในที่เดียวแทนที่จะอยู่ในเลเยอร์การนำเสนอของคุณทั้งหมด

สมมติว่าคุณตัดสินใจเปลี่ยน ORM จาก Linq เป็น SQL เป็น Entity Framework (หรือ nhibernate) มันอาจจะง่ายกว่าที่จะเปลี่ยนในเลเยอร์ธุรกิจกว่าในเลเยอร์การนำเสนอของคุณเนื่องจากงานนำเสนอมักจะมีรูปแบบการนำเสนอที่แน่น

หากคุณเข้าใจ MVC นั่นคือ .. Model View Controller คุณสามารถนึกถึงสถาปัตยกรรมแอปพลิเคชันของคุณในแง่เดียวกัน แบบจำลองนั้นคล้ายกับชั้นข้อมูลของคุณชั้นการนำเสนอคือมุมมองและชั้นธุรกิจเป็นตัวควบคุม

เมี่ยงคำตอบที่อ้างว้างของโลกเกี่ยวกับการขับเคลื่อนโดเมนออกแบบ:

ลองดูThe Onion Architectureซึ่งสอดคล้องกับแนวคิดการออกแบบโดเมนขับเคลื่อน

โปรดสังเกตว่า Business Layer "Layer" เป็นแกนหลักของหัวหอมใหญ่และทุกชั้นโครงสร้างพื้นฐาน (เช่น data access layer) นั้นขึ้นอยู่กับการพึ่งพาจากภายนอก สิ่งนี้ช่วยทดสอบได้มากเพราะคุณควรจะจำลองการพึ่งพาโครงสร้างพื้นฐานภายนอกและทดสอบตรรกะโดเมนของคุณอย่างเต็มที่

ในความคิดของฉัน: ชั้นตรรกะทางธุรกิจเป็นที่ที่ "วิธีแก้ปัญหาแนวคิดบริสุทธิ์" มีชีวิต ส่วนที่เหลือเป็นเพียงรายละเอียดการใช้งานโครงสร้างพื้นฐาน

อย่างไรก็ตามแอพพลิเคชั่นบางตัวอาจไม่ต้องการสถาปัตยกรรมประเภทนี้ หากแอปพลิเคชันของคุณทั้งหมดเป็นชุดข้อมูล CRUD การดำเนินงาน 'บริสุทธิ์แนวคิดแนวคิด' ของคุณอาจว่างเปล่าจริงและสิ่งที่คุณต้องมีการแก้ไขฐานข้อมูล front-end ในกรณีนี้คุณน่าจะดีกว่ามุ่งเน้นไปที่เลเยอร์ DAL และ UI เท่านั้น

คำตอบสำหรับคำถามนี้คือ (IMHO): "ฉันสามารถแทนที่ DAL ของฉันได้อย่างสมบูรณ์และไม่ต้องเขียนรหัสตรรกะทางธุรกิจของฉันใหม่"

คิดว่ามันเหมือนกับเลเยอร์การนำเสนอของคุณ - เป็นเรื่องธรรมดาที่จะคิดว่าจะเปลี่ยน GUI สำหรับอีกอันหนึ่งเดสก์ท็อป GUI หนาจะถูกสับเปลี่ยนสำหรับเว็บไคลเอ็นต์ซึ่งเปลี่ยนเป็นแอป iPhone มันไม่ธรรมดาที่จะคิดเช่นนี้สำหรับ BLL / DAL เพราะพวกเขาไม่เคยได้รับการแลกเปลี่ยนยกเว้นบางทีสำหรับสิ่งที่คล้ายกันมาก (เช่น SQLServer DB แทนที่ด้วย MySQL หนึ่ง) แต่ถ้าคุณคิดว่าคุณต้องเปลี่ยน DB ของคุณเป็นที่จัดเก็บแบบกระจาย บริการที่เข้าถึงโดยใช้ API คุณอาจได้รับแนวคิดที่ชัดเจนว่าเลเยอร์มาบรรจบกันได้อย่างไร