จะแบ่งชั้นข้อมูลและชั้นออบเจ็กต์ธุรกิจอย่างไร มีหน้าที่ที่เหมาะสมในแต่ละส่วนอย่างไร?

ดูเหมือนว่าความรับผิดชอบระหว่างระดับจะสับสนเล็กน้อย ชั้นข้อมูลฟังดูค่อนข้างเป็นมาตรฐาน ชั้นธุรกิจ ("ที่เรียกว่า") คือจุดที่สิ่งต่างๆ สับสน

ความคิดบางประการเกี่ยวกับ Business Layer:

• ดูเหมือนว่าจะมีการนำเสนอข้อมูลจำนวนมาก คุณพูดถึง DataTables, DataSets, Data Transfer Objects แนวทางมาตรฐานสำหรับแอปพลิเคชันทั้งหมดจะดีกว่า

• วิธีการชั้นธุรกิจที่มีชื่อเช่น ReturnNthRecordSetFromStoredProcFoo และ ReturnDataSet นั้นไม่มีความหมายและไม่ได้จัดเตรียมสิ่งที่เป็นนามธรรมในระดับที่เหมาะสมสำหรับบริการทางธุรกิจ (บางทีนั่นอาจเป็นเพียงตัวอย่างที่ได้รับการคัดเลือกไม่ดีซึ่งไม่ได้มาจากแอปพลิเคชัน)

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

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

• ฉันคิดว่าการพึ่งพานั้นใช้ได้ - ไม่มีการอ้างอิงถึง Web.UI หรือ SQLClient จากเลเยอร์ธุรกิจ

• กฎการอนุญาตก็โอเคเช่นกัน ฉันจะขยายให้รวมการรักษาความปลอดภัยไม่ใช่แค่การอนุญาตเท่านั้น นอกจากนี้ ฉันไม่เห็นตรรกะทางธุรกิจเลย แค่อยากรู้ว่าตรรกะทางธุรกิจอยู่ในขั้นตอนการจัดเก็บหรือไม่ ถ้าฉันจะเดา ฉันจะตอบว่าใช่ เนื่องจากวิธีการทางธุรกิจแต่ละวิธีเรียกใช้ขั้นตอนการจัดเก็บเพียงขั้นตอนเดียวเท่านั้น ถ้าเป็นเช่นนั้นก็ถือว่าไม่ใหญ่สำหรับฉัน

ฉันจะไม่รวมชั้นธุรกิจและข้อมูลเข้าด้วยกัน ฉันต้องการแยกชั้นตรรกะทางธุรกิจและชั้นการเข้าถึงข้อมูลออกจากกัน เมื่อมีตัวเลือกระหว่างการรวมพวกมันเข้ากับการพยายามแยกความรับผิดชอบให้มากขึ้นอีกหน่อย ฉันจึงเอนเอียงไปทางอย่างหลัง

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

คำถามอื่นๆ ที่ควรคำนึงถึงคือ อะไรคือประเด็นหลักที่คุณต้องการแก้ไข? พวกมันใช้งานได้หรือไม่ (เช่น จุดบกพร่อง ขาดเสถียรภาพ)? หรือเกี่ยวข้องกับประสิทธิภาพ? หรือมันเป็นสถาปัตยกรรม? หรืออาจเกี่ยวข้องกับการบำรุงรักษา คุณจำเป็นต้องเพิ่มฟังก์ชันการทำงานใหม่แต่พบว่าทำได้ยากหรือไม่? คุณมีกรอบเวลาหรืองบประมาณหรือไม่? หากคุณสามารถตอบคำถามเหล่านี้บางข้อได้ อาจช่วยแนะนำคุณได้

ขึ้นอยู่กับโหลดเซิร์ฟเวอร์ของคุณควรกำหนดจำนวนเลเยอร์ทางกายภาพ จำนวนเลเยอร์ลอจิคัลเป็นทางเลือกส่วนตัวมากกว่า

ในองค์กรของเรา เราใช้ กรอบงาน CSLA เป็นเฟรมเวิร์กออบเจ็กต์ทางธุรกิจที่มุ่งมั่นที่จะสร้าง UI ที่มีข้อมูลจำนวนมากและง่ายต่อการใช้งานและบำรุงรักษา ในขณะเดียวกันก็ให้ความยืดหยุ่นในชั้นข้อมูล

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

"dataportal" (บทความเก่ากว่าแต่ยังคงมีความเกี่ยวข้อง) ช่วยให้คุณสามารถย้ายการเข้าถึงข้อมูลไปยังเลเยอร์ของตัวเองได้อย่างง่ายดายโดยใช้ความพยายามเพียงเล็กน้อย และไม่มีการเปลี่ยนแปลงโค้ด

DNRtv มีพ็อดวิดีโอบางส่วนที่ Rockford Lhotka ผู้ออกแบบ CSLA แสดงการทำงานของแอปพลิเคชันตัวอย่าง . ส่วนที่ 1 และ ส่วนที่ 2

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

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