ถ้า MVC เป็น“ การแยกความกังวล” ดังนั้นทำไมจึงมีการแนะนำไวยากรณ์ของมีดโกนไว้


22

คำถามของฉันเกี่ยวข้องกับรูปแบบการออกแบบ MVC และมีดโกนที่แนะนำโดย Microsoft

ในขณะที่การเรียนรู้รูปแบบการออกแบบ MVC ผมก็บอกว่าความคิดที่มีพื้นฐานอยู่บนหลักการที่เรียกว่าการแยกความกังวลเกี่ยวกับ

แต่มีดโกน Syntax ช่วยให้เราสามารถใช้ C # ในViewsโดยตรง

ข้อกังวลนี้แยกกันหรือเปล่า


7
เป็นมูลค่าการกล่าวขวัญว่า ASP.NET MVC ไม่ได้ใช้รูปแบบการออกแบบ MVC MVC บอกว่าแบบจำลองนั้นถูกสังเกตโดยมุมมองสำหรับการเปลี่ยนแปลงซึ่งไม่ชัดเจนในกรณีใน ASP.NET MVC
Benjamin Gruenbaum

11
นอกจากนี้ยังอาจช่วยได้หากคุณเปลี่ยนวิธีคิดของ Views มุมมองไม่ใช่รหัสฝั่งไคลเอ็นต์ เป็นเทมเพลตฝั่งเซิร์ฟเวอร์ที่เมื่อประมวลผลแล้วจะสร้าง html ฝั่งไคลเอ็นต์ และเป็นรหัสฝั่งเซิร์ฟเวอร์เป็นที่ยอมรับอย่างสมบูรณ์ว่ามีรหัส C # อยู่ที่นั่น
Eric King

6
@EricKing ยกเว้นส่วนที่ templating ระบบที่อนุญาตให้รหัสโดยพลการมักจะนำผ่านเส้นทางของความต้านทานน้อยที่สุดเพื่อการออกแบบที่ไม่ดีการละเมิด layering ที่น่ากลัวและ unmaintainability น่าเสียดายที่เป็นบทเรียนที่ทุกชุมชนต้องเรียนรู้ด้วยตนเอง
ฮอบส์

12
@ ฮอบส์ว้าวโอเค ไม่ได้อยู่ในประสบการณ์ของฉัน ไม่แน่นอนเสมอไปและ (แน่นอน) มีความรับผิดชอบระดับมืออาชีพที่จำเป็นในส่วนของโปรแกรมเมอร์ ฉันไม่ตำหนิเครื่องมือ
Eric King

7
@BenjaminGruenbaum ไม่เหมือนทุก ๆ "MVC" - การทำงานวันนี้แตกต่างกันไปในวิธีที่พวกเขาจัดการการพึ่งพาซึ่งกันและกัน? ไปยังจุดที่มันไม่ได้ผลิตเพื่อพูดคุยเกี่ยวกับ The One and Only True MVC-Style แต่ที่มันจะเป็นในทางปฏิบัติมากขึ้นในการใช้คำว่าระบบใด ๆ ที่สมควรพาร์ทิชันที่รับผิดชอบในรุ่น , ผู้ชมและควบคุมแต่เหล่านี้มีการพึ่งพาซึ่งกันและกัน?
อเล็กซ์

คำตอบ:


66

คุณกำลังสับสนไวยากรณ์ของมีดโกนด้วยการแยกข้อกังวลออก

การแยกข้อกังวลเกี่ยวข้องกับโครงสร้างของรหัส

ความสามารถในการใช้ C # ในมุมมองไม่ได้ป้องกันสิ่งนั้น มันไม่มีส่วนเกี่ยวข้องกับการแยกข้อกังวลออกไป

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


1
แต่ C # เป็นภาษาฝั่งเซิร์ฟเวอร์
John Strowsky

6
@John - เหรอ? หากคุณต้องการจัดรูปแบบวันที่สำหรับการแสดงผล (และการแสดงผลหมายถึงฝั่งไคลเอ็นต์เสมอ) คุณจะจัดรูปแบบที่ใด นางแบบ? ตัวควบคุมหรือไม่ ทั้ง คุณจะทำในมุมมอง
Oded

16
@John - ดังนั้นวันที่ของคุณจะถูกเก็บไว้ในฐานข้อมูลคุณส่งผ่านโมเดล / คอนโทรลเลอร์ไปยังมุมมองของคุณ คุณจำเป็นต้องมีใน HTML ดังนั้นคุณจะส่งออกไปยัง JS เพื่อจัดรูปแบบแทนการจัดรูปแบบโดยตรงด้วย C #? ทำไม? ทำไมถึงดีกว่า หรือว่าเป็นวิธีการที่แยกมากขึ้นของความกังวลหรือไม่
Oded

25
@ NPSF3000 - ภาษาไม่ใช่ "ฝั่งเซิร์ฟเวอร์" หรือ "ฝั่งไคลเอ็นต์" นั่นคือการแยกสถาปัตยกรรม - และอาจเป็นหนึ่งในการใช้ภาษา (JavaScript เป็นฝั่งเซิร์ฟเวอร์หรือภาษาฝั่งไคลเอ็นต์ - จำ node.js)
Oded

14
@FreeAsInBeer - นี่คือตรรกะชนิดหนึ่งที่อยู่ในฝั่งไคลเอ็นต์ - บางคนในฝรั่งเศสต้องการเห็นวันที่ (และสกุลเงิน / ตัวเลข) ที่จัดรูปแบบแตกต่างจากคนในสหรัฐอเมริกา ลูกค้าจะ "รู้" อย่างดีที่สุดว่าควรจะแสดงสิ่งเหล่านี้อย่างไร นี่คือตรรกะการนำเสนอและเป็นเช่นนี้อยู่ในมุมมอง
Oded

35

แทนที่จะตอบคำถามโดยตรงฉันจะตอบคำถามตามสมมติฐานที่ตั้งไว้ นั่นคือสมมติฐานที่ว่ามีดโกนถูกสร้างขึ้นสำหรับ MVC นั้นไม่ถูกต้อง ฉันทำงานที่ Microsoft ในทีม ASP.NET และมีความรู้ตรงนี้

มีดโกนไม่เริ่มต้นเป็นเครื่องมือดูสำหรับ MVC มันถูกสร้างขึ้นสำหรับASP.NET เว็บเพจซึ่งอาจเป็นไปได้ว่าคุณสามารถไปยังด้านที่เกี่ยวข้องน้อยที่สุดของสเปกตรัม มันถูกสร้างขึ้นเป็นทางเลือกที่ทันสมัยในการ ASP.NET Web Forms / Classic ASP และแน่นอนกรอบการเขียนโปรแกรมเซิร์ฟเวอร์ที่คล้ายกันอื่น ๆ อีกมากมาย แนวคิดของมีดโกนคือการสร้างช่วงการเปลี่ยนภาพที่ราบรื่นระหว่าง HTML (มาร์กอัป) และ C # (รหัส)

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

ในแง่ของว่ามีดโกนเปิดใช้งาน, ขัดขวาง, ปรับปรุงหรือเปลี่ยนแปลงแนวคิดของการแยกข้อกังวลใน ASP.NET MVC หรือไม่คำตอบของ Odedก็เปิดอยู่


2
Yay, downvote โดยไม่มีความคิดเห็น ฉันแก้ไขคำตอบของฉันเพื่อให้ชัดเจนว่าฉันกำลังตั้งสมมติฐานในคำถามเดิม อย่างที่ฉันเห็นมันคำถามไม่สามารถตอบได้โดยตรงเพราะมันมีหลักฐานที่ไม่ถูกต้อง
Eilon

จากการอยากรู้อยากเห็นเครื่องยนต์ Templating อื่น ๆ ได้รับการพิจารณาสำหรับ ASP MVC หรือไม่?
NWard

2
@ ไม่เคยมีเอ็นจิ้นการดูจากบุคคลที่สามจำนวนมากสำหรับ ASP.NET MVC ในเวลานั้น แต่เราไม่ได้คิดว่ามันแรงเกินไป เรารู้สึกว่ามีดโกนนั้นง่ายต่อการเข้าใจ (HTML คือ HTML, C # คือ C #) และยังทำให้เกิดเสียงที่ดีขึ้นกับโครงการ ASP.NET เว็บเพจ
Eilon

1
@Alex โอ้แน่นอนฉันไม่สามารถใช้เครดิตสำหรับมีดโกนทั้งหมด แต่ฉันขอขอบคุณความคิดเห็นของคุณ!
Eilon

1
@ateri หลังจากนั้นไม่นานก็มีจำนวนมากที่ด้านบนซ้ายของคำตอบ
Mark Hurd

9

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


สิ่งนี้ดูเหมือนจะไม่เสนออะไรมากเกินกว่าที่ทำคะแนนและอธิบายไว้ในคำตอบก่อนหน้านี้
ริ้น

4
+1 สูตรในวิธีที่กระชับและชัดเจนและมีจุดเน้นที่แตกต่างของคำอธิบายกว่าคำตอบก่อนหน้า
อเล็กซ์

@gnat ฉันแค่ต้องการทำให้ชัดเจนว่าความสับสนของเขาวางอยู่ที่ไหนแล้วอธิบายได้อย่างรวดเร็วว่าการแยกความกังวลหลักนำไปใช้กับรูปแบบการออกแบบ MVC อย่างไร บางทีฉันควรจะใช้เวลามากขึ้นในการ "แยกข้อกังวล" หมายถึงอะไร?
whoisthemachine

0

ฉันนึกถึงDon't do itตัวอย่างที่สมบูรณ์แบบ

ช่วยบอกว่าเรามี ProductController:

public class ProductController()
{
    public ViewResult Discontinued()
    {
        var db = new ProductsDb();
        var products = db.Products.Where(x => x.Discontinued).ToList();
        return new ViewResult(products);
    }
}

ด้วยมีดโกนเรามีทางเลือก

public class ProductController()
{
    public ViewResult Discontinued()
    {
        var db = new ProductsDb();
        var products = db.Products.ToList();
        return new ViewResult(products);
    }
}

และในมุมมองของเรา:

@model IEnumerable<Product> 

@foreach (var item in Model.Where(x => x.Discontinued)) {
    ....
}

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

และอย่าลืม: ความสามารถในการใช้ C # ในมุมมองไม่ใช่คุณลักษณะของมีดโกนก็เป็นไปได้ด้วยมุมมอง ASP.NET เช่นกัน ด้วยมีดโกนมันง่ายกว่านิดหน่อย

หากคุณกำลังค้นหาเอ็นจิ้นเทมเพลตซึ่งเป็นรางมากกว่าคุณควรดู nancy.fx ด้วยเอ็นจิ้นการดูที่เรียบง่ายสุด ๆ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.