ควรอนุญาตให้ใช้ตรรกะทางธุรกิจเท่าใดในชั้นควบคุม

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

อีกตัวอย่างหนึ่งคือชุดของฟังก์ชันยูทิลิตี้ที่มีอยู่ในตัวควบคุมที่อาจทำงานเพื่อจัดรูปแบบหรือฆ่าเชื้อข้อมูลที่ส่งคืนจากแบบจำลองตามชุดของกฎทางธุรกิจ

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

คำถามของฉันคือจำนวนตรรกะทางธุรกิจที่ควรได้รับอนุญาตในตัวควบคุมและในสถานการณ์ใดถ้ามี?

เป็นการดีที่ไม่มี

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

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

การสร้างระบบที่มีอยู่เป็นเอกเทศเป็นเป้าหมาย หากคุณเริ่มเขียนตรรกะทางธุรกิจที่เฉพาะเจาะจงกับวิธีที่ทั้งสองระบบโต้ตอบกันซึ่งเป็นปัญหา หากไม่ได้มองเพิ่มเติมฉันไม่สามารถแสดงความคิดเห็นได้

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

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

น้อยที่สุด ไม่มีใครดีกว่า

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

ในกระบวนการนั้น "ตรรกะทางธุรกิจ" ทั้งหมดควรมีอยู่ในบริการโดเมน

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

คำว่า "ตรรกะทางธุรกิจ" เป็นคำที่มักจะสับสนเพราะผู้คนมีความคิดเห็นที่แตกต่างกันเกี่ยวกับความหมายของสิ่งนี้ ในมุมมองของฉันคำว่า "ตรรกะทางธุรกิจ" ครอบคลุมสองด้าน

• ลอจิกโดเมน
• แอปพลิเคชันลอจิก

Domain Logic เป็นตรรกะที่เกี่ยวข้องกับพื้นที่หลักที่ธุรกิจของคุณเกี่ยวข้องดังนั้นหากเขียนแอปพลิเคชันสำหรับนักบัญชีกฎภาษีกฎการเก็บหนังสือ ฯลฯ เป็นส่วนหนึ่งของตรรกะโดเมน

แอปพลิเคชันตรรกะเป็นตรรกะที่เกี่ยวข้องกับข้อเท็จจริงที่ว่าคุณกำลังเรียกใช้โปรแกรมคอมพิวเตอร์ สิ่งนี้อาจเป็นสิ่งเช่นการส่งออกนำเข้า CSV ตัวช่วยสร้าง ฯลฯ อาจมีสิ่งต่าง ๆ เช่นการสร้างอีเมลรหัสผ่านที่ลืม

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

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

ตัวควบคุมควรมีน้ำหนักเบาในตรรกะของโดเมน

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

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

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

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

ตัวเลือกที่สามคือการอ้างอิงรายการยูทิลิตี้เป็นคลาสยูทิลิตี้แยกต่างหาก แต่มันค่อนข้างขัดแย้งกับรูปแบบเช่นกันในความเห็นของหลาย ๆ คน

นอกจากนี้เพียงเพราะคุณไม่ได้ทำตามรูปแบบอย่างเคร่งครัดคุณไม่จำเป็นต้องมีความเจ้าชู้กับภัยพิบัติ หากคุณไม่คาดหวังว่าจะมีการใช้รหัสจำนวนมากในการนำโปรเจ็กต์นี้กลับมาใช้ใหม่ฉันจะกังวลมากขึ้นเกี่ยวกับโปรเจ็กต์ที่สอดคล้องกับตัวมันเอง (เช่น: อย่า flip-flop กว่าเขียนใหม่ด้วยเหตุผลบางอย่างต้องการบันทึกส่วนหนึ่งของกลางโครงการ เอกสาร / ความคิดเห็นที่ & สาเหตุที่คุณเบี่ยงเบนจากรูปแบบทั่วไปและกำหนดรูปแบบที่คาดหวังสำหรับแอปพลิเคชันนี้

MVC เป็นส่วนเบี่ยงเบนจากรูปแบบที่กำหนดไว้ในจุดหนึ่ง

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

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

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

• ควรใช้ตรรกะเท่าไรในคอนโทรลเลอร์?

• มุมมองควรมีตรรกะตามเงื่อนไขหรือไม่?

• โมเดลควรมีข้อมูลเพิ่มเติมใด ๆ ที่ไม่พบในองค์กรธุรกิจโดยตรงหรือไม่

ทั้งหมดนี้เป็นคำถามที่เกิดจากความพยายามในการปรับรหัสให้เหมาะกับแนวคิดแนวคิดของ MVC อย่างแม่นยำและครบถ้วน

คำตอบของฉันสำหรับคุณคืออย่าพยายาม MVC จัดเตรียมโครงสร้าง สร้างแอปพลิเคชันของคุณรอบ ๆ รากฐานนี้ แต่อย่าคาดหวังให้มันลงตัว จะมีการเบี่ยงเบนเป็นเรื่องปกติ เพียงแค่เฝ้าดูให้อยู่ภายใต้การควบคุม