ทำไมทุกคนถึงนำคอนโทรลเลอร์ไปไว้ในโฟลเดอร์เดียวและอีกมุมมองหนึ่ง?

ฉันพร้อมที่จะโค้งงอจาก asp และเป็นกรอบ mvc, asp.net mvc หรือแนนซี่ เมื่อใดก็ตามที่ฉันไปฉันเห็นโฟลเดอร์สำหรับตัวควบคุม / โมดูลและโฟลเดอร์สำหรับมุมมอง นี่เป็นเพียงภาพเคลื่อนไหวของ pavlovian ในการจัดเรียงสิ่งต่าง ๆ ตามประเภทหรือมีการดำเนินงานอย่างลึกซึ้งยิ่งขึ้น? ฉันมีโปรเจ็กต์การพิสูจน์แนวคิดเล็กน้อยที่ฉันเก็บไฟล์ที่ฉันน่าจะเปิดด้วยกันไว้ด้วยกันซึ่งเป็นความสะดวกสบายที่สำคัญมาก เนื่องจากไฟล์เหล่านี้มีแนวโน้มที่จะเรียกซึ่งกันและกันไฟล์จึงสามารถทำได้โดยใช้ลิงก์ที่สั้นลงและเปราะน้อยกว่า รูปแบบนี้ถูกท้าทายโดย mvc เนื่องจากเส้นทางโฟลเดอร์จะไม่สอดคล้องกับเส้นทาง url โดยอัตโนมัติอีกต่อไปและใน asp.net mvc เทมเพลตโครงการและการกำหนดเส้นทางจะบังคับใช้ views \ controllers \ schism

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

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

มีคนอื่นต่อสู้สิ่งนี้หรือไม่? เคล็ดลับใด ๆ

ฉันต้องการจะบอกว่ามันคือการเขียนโปรแกรมลัทธิสินค้าแต่มีเหตุผลทางเทคนิคสำหรับโครงสร้างนี้ Asp.Net MVC จัดการประชุมผ่านวิธีการตั้งค่าเกือบทุกอย่าง ตามค่าเริ่มต้นเอ็นจิ้นมุมมองมีดโกนจะค้นหาViewsไดเร็กทอรีเพื่อแก้ไขมุมมองที่จะส่งคืนจากคอนโทรลเลอร์ อย่างไรก็ตามมีแฮ็กเล็กน้อยที่จะได้รับโครงสร้างโครงการที่แตกต่างกันและ Microsoft ยังมีคุณสมบัติ MVC ที่เรียกว่าพื้นที่เพื่อให้เราสร้างโครงสร้างโครงการที่มีสติมากขึ้น คุณสามารถใช้เครื่องมือดูของคุณเองเพื่อระบุตำแหน่งที่จะมองหา

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

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

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

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

ไม่ว่าด้วยเหตุผลใดก็ตามนี่คือการฝึกฝนที่ไม่ดี มันเป็น anti-OO มากเพราะแพ็คเกจหรือโฟลเดอร์ (สิ่งที่คุณต้องการเรียกพวกเขา) ควรมีการพึ่งพาระหว่างกันที่อ่อนแอ คลาส (หรือไฟล์) ในนั้นควรมีการพึ่งพาระหว่างกันอย่างมาก

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

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

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

• ในการทำซ้ำสถาปัตยกรรมโลจิคัล (โมเดลมุมมองคอนโทรลเลอร์) ด้วยโฟลเดอร์ที่ตรงกันและโครงสร้างเนมสเปซ

• ออกจากการประชุมและความสะดวกสบายในการติดตามเทมเพลตโครงการ ASP.net MVC

• จัดกลุ่มตามเนมสเปซเนื่องจากControllers/โฟลเดอร์จะนำไปสู่.Controllersเนมสเปซ

• อาจเปิดใช้งานบางสถานการณ์ใน DI / IoC โดยที่ตัวควบคุมคลาสจะถูกสอบถาม / สแกนจากเนมสเปซที่มี / ลงท้ายด้วย 'ตัวควบคุม' (อาจเป็นสิ่งที่ผิด)

• เพื่ออนุญาตให้เทมเพลต T4 สแกนและจำลองโมเดลและตัวควบคุมเพื่อสร้างมุมมอง

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

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

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

อีกเหตุผลหนึ่งคือทำให้มี "ธีม" และสลับเทมเพลตทั้งหมดได้ง่ายขึ้นโดยทำการเปลี่ยนแปลงเล็กน้อยในพา ธ มุมมอง

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

"คัปปลิ้งคับ" ควรมีเพียง:

1. ตัวแปรที่ส่งไปยังมุมมองโดยคอนโทรลเลอร์
2. เขตข้อมูลฟอร์มหรือการกระทำในมุมมองส่งกลับไปยังตัวควบคุม

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

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

    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

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

พิจารณาว่ามุมมองเป็นเพียงวิธีการจัดรูปแบบข้อมูลไม่ว่าจะเป็น json, xml, csv หรือ html สิ่งนี้ช่วยได้อย่างยิ่งหากคุณต้องการให้แอปพลิเคชันของคุณทำงานเป็น API พยายามแยกมุมมองออกจากข้อมูลโดยใช้ชื่อตัวแปรทั่วไปเพื่อให้คุณสามารถใช้เทมเพลตเดียวกันสำหรับตัวควบคุมหรือรุ่นจำนวนมาก (หรือใช้รวมถึงเพื่อลดจำนวนรหัสที่คุณต้องบำรุงรักษา)

ไม่จำเป็นว่าทุกคนจะทำสิ่งนี้ ตัวอย่างเช่นกรอบ Django ของ python มีแนวคิดของแอพซึ่งโมดูลย่อยของแอปพลิเคชันของคุณอาศัยอยู่ในไดเรกทอรีของตัวเองด้วยโมเดลและมุมมองและเทมเพลตของตัวเอง (มุมมองเป็นสิ่งที่ Django เรียกว่าคอนโทรลเลอร์เป็นหลัก) ฉันชอบที่จะทำสิ่งต่าง ๆ มากกว่าเพราะนั่นหมายความว่าฉันสามารถจัดแพคเกจ "แอพ" ได้อย่างง่ายดายและนำมาใช้ซ้ำในโครงการต่างๆเพียงแค่ใส่ไว้ในรายการแอพในการตั้งค่าโครงการของฉัน นอกจากนี้ยังง่ายต่อการค้นหาว่าส่วนต่าง ๆ อยู่ที่ไหน ถ้าฉันดูไฟล์ urls.py และเห็นบางอย่างurl(r'^users/', include('my_site.users.urls'))ฉันรู้ว่าโมดูลนั้นmy_site.usersมีรหัสทั้งหมดที่จัดการกับผู้ใช้ ฉันรู้ที่จะดูโมดูลmy_site.users.viewsและmy_site.users.modelsเมื่อฉันต้องการดูว่าผู้ใช้สร้างและรับรองความถูกต้องอย่างไร my_site.users.urlฉันรู้ว่าเส้นทางของฉันทั้งหมดที่กำหนดไว้ใน

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

โปรดจำไว้ว่าเป็นวิธีที่Microsoft แนะนำเพื่อให้ตัวควบคุมและมุมมองต่าง ๆ อยู่ในโฟลเดอร์ที่แตกต่างกันดังนั้นหลายคนจะปฏิบัติตามโครงสร้างที่แนะนำ

1. เหตุผลหนึ่งอาจเป็นตัวควบคุมไม่ได้มีความสัมพันธ์แบบหนึ่งต่อหนึ่งกับมุมมองเสมอโดยเฉพาะมุมมองบางส่วนสามารถใช้ร่วมกันระหว่างตัวควบคุมได้
2. อีกเหตุผลหนึ่งอาจเกิดขึ้นเมื่อโครงการของคุณเติบโตคุณอาจต้องการดึงตัวควบคุมและการทดสอบหน่วยออกไปยังโครงการอื่น แต่มันก็ยากที่จะทำเช่นเดียวกันสำหรับมุมมองรวมถึง views / js / css ด้วยกันเนื่องจากพวกเขาอ้างถึงกันและกัน

ต้องบอกว่ามีการโพสต์จำนวนมากเกี่ยวกับการทำมันด้วยวิธีของคุณเช่นนี้

สำหรับบันทึก

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

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

การพยายามเลียนแบบพฤติกรรมของโครงการ (หน้าร้าน) คือลัทธิขนส่งสินค้า