ควรเรียงลอจิกในรูปแบบมุมมองหรือคอนโทรลเลอร์? [ปิด]

157

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้

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

ปิดให้บริการใน6 ปีที่ผ่านมา

ฉันมีรายการแบบหล่นลงที่แสดงค่าจากตารางไปยังผู้ใช้ปลายทาง ฉันต้องการให้ค่าเหล่านี้เรียงตามลำดับตัวอักษร

ตามการออกแบบ MVC ที่เหมาะสมฉันควรวางตรรกะการเรียงลำดับของชั้นใด: แบบจำลองมุมมองหรือตัวควบคุม

แก้ไข : เพื่อตอบสนองต่อคำถามของ LarsH "คุณหมายถึงรหัสที่กำหนดว่าต้องการเรียงลำดับหรือไม่หรือรหัสที่เรียงลำดับได้หรือไม่" ฉันเดิมอ้างถึงรหัสที่กำหนดเรียงลำดับที่ต้องการ

asp.net-mvc model-view-controller

— Ryan Kohn
แหล่งที่มา

6

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

— LarsH

9

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

— Bill K

9

บางทีนี่ควรจะย้ายไปโปรแกรมเมอร์

— Alfredo Osorio

57

แน่นอนในตัวควบคุม ไม่ว่าจะเป็นรูปแบบหรือ หรือมุมมอง

— ม็อบ

2

ในมุมมองที่ไม่เคยไม่เคยไม่เคยเคย

— contactmatt

49

(หมายเหตุ: คำพูดและการอ้างอิงนี้นำมาจากคำตอบของ @ dasblinkenlightแต่เราไม่เห็นด้วยกับการตีความของเราอ่านโพสต์ของเขาและตัดสินใจเอง)

ตามคำอธิบาย MVC ,

คอนโทรลเลอร์สามารถส่งคำสั่งไปยังมุมมองที่เกี่ยวข้องเพื่อเปลี่ยนการนำเสนอมุมมองของโมเดล (ตัวอย่างเช่นโดยการเลื่อนดูเอกสาร) สามารถส่งคำสั่งไปยังโมเดลเพื่ออัพเดตสถานะของโมเดล (เช่นการแก้ไขเอกสาร)

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

— KyleM
แหล่งที่มา

8

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

— s4y

ที่ควรทำในลักษณะเดียวกัน model.SortAscending () และ model.SortDescending () และเรียกใช้โดย Controller

— Brij

1

@Brij ใน MVC ที่เหมาะสมสองมุมมองจะไม่สามารถแบ่งปันโมเดลเดียวกันได้หรือไม่

— KOVIKO

@Sidnicious ถ้ามันมีเหตุผลที่จะมีวิธีการเรียงลำดับหนึ่งที่ใช้พารามิเตอร์ที่แตกต่างกัน เช่นpublic void Sort(bool sortByDescending = false)ถ้าเป็นเท็จมันจะเรียงลำดับจากน้อยไปหามาก หรือมีวิธีการเรียงลำดับที่แตกต่างกันสองวิธีหากตรรกะแตกต่างกันมาก

— MattMcGowan

@Sidnicious มีสองรุ่นที่แตกต่างกันที่มอบทุกอย่าง แต่ตรรกะการเรียงลำดับให้เป็นรุ่นที่สามเดียว docs.google.co.th/drawings/d/…

— rightfold

62

ใครเป็นผู้ควบคุมลำดับการจัดเรียง

แผนผัง MVC อย่างง่าย (จากWikipedia )

1) ลำดับธรรมชาติภายในข้อมูลเอง:

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

2) ผู้ใช้ควรควบคุมวิธีดูข้อมูล:

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

ไม่ว่าในกรณีใด

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

ข้อแม้เล็ก ๆ

ฟังก์ชั่นการเรียงลำดับสามารถใช้งานได้อย่างหมดจดในมุมมองภายใต้สถานการณ์หนึ่ง (ที่ฉันสามารถคิดได้ในทันทีทันใดอาจมีมากกว่า):

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

— Izkata
แหล่งที่มา

58

มุมมองสามารถดูผู้ใช้!?

— Farzher

41

โมเดลอัปเดตมุมมอง!

— หลอกลวง

13

บทความวิกิพีเดียนั้น sucks: ส่วน "การปฏิสัมพันธ์ขององค์ประกอบ" ขัดแย้งกับแผนภาพที่แสดงทางด้านขวา (ซึ่งคุณเพิ่งโพสต์ที่นี่) ประการที่สองรูปแบบไม่ "อัพเดท" มุมมอง มันแจ้งมุมมองเมื่อมีการเปลี่ยนแปลงสถานะ มุมมองจะตัดสินวิธีการอัปเดต ฮึ. คุณสงสัยว่าทำไมมี 1,000 คำตอบสำหรับคำถามนี้เมื่อมีข้อมูลที่ไม่ชัดเจนลอยอยู่รอบ ๆ

— KyleM

4

@ แน่ใจว่า เราสามารถตกลงกันได้ว่ากราฟของ Wikipedia ค่อนข้างแปลกใช่ไหม? :)

— หลอกลวง

6

@StephenSarcsamKamenar และคนอื่น ๆ : ไม่ภาพมีความสมบูรณ์แบบ: มันแสดงการไหลของข้อมูลไม่ใช่การเชื่อมต่อรหัส

— Izkata

18

ตามคำอธิบาย MVC ,

คอนโทรลเลอร์สามารถส่งคำสั่งไปยังมุมมองที่เกี่ยวข้องเพื่อเปลี่ยนการนำเสนอมุมมองของโมเดล (ตัวอย่างเช่นโดยการเลื่อนดูเอกสาร) สามารถส่งคำสั่งไปยังโมเดลเพื่ออัพเดตสถานะของโมเดล (เช่นการแก้ไขเอกสาร)

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

แก้ไข:เพื่อชี้แจงความเข้าใจผิดหลายครั้งที่เปล่งออกมาในความคิดเห็น "ตรรกะการเรียงลำดับ" ไม่ใช่รหัสที่ดำเนินการเรียงลำดับ มันเป็นรหัสที่กำหนดการเรียงลำดับ ตรรกะการเรียงลำดับจะเปรียบเทียบแต่ละไอเท็มซึ่งกันและกันเพื่อสร้างคำสั่งซื้อ (เช่นผ่านอินสแตนซ์ของIComparator<T>) หรือมีตรรกะที่สร้างวัตถุที่จะใช้สำหรับการสั่งซื้อโดยระบบภายนอก (เช่นผ่านอินสแตนซ์ของIOrderedQueryable<T>) ตรรกะนี้อยู่ในตัวควบคุมของคุณเนื่องจากต้องการความรู้ที่เกี่ยวข้องกับด้าน "ธุรกิจ" ของแอปพลิเคชันของคุณ มันก็เพียงพอที่จะดำเนินการทั้งหมดเรียงลำดับ แต่มันจะแยกจากรหัสที่จริงการดำเนินการมัน. รหัสที่เรียงลำดับอาจอยู่ในมุมมองของคุณในแบบจำลองของคุณหรือแม้แต่ในชั้นการเก็บข้อมูลที่สนับสนุนโมเดลของคุณ (เช่นฐานข้อมูล SQL ของคุณ)

— dasblinkenlight
แหล่งที่มา

12

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

— tereško

3

@ tereškoคุณจัดการเพื่อสรุปจากคำตอบของฉันได้อย่างไรว่าคอนโทรลเลอร์ต้องการดึงข้อมูลจากโมเดล โดย "การเรียงลำดับตรรกะ" ผมหมายถึงเพียงตรรกะที่มีความจำเป็นต้องสร้างการสั่งซื้อ - เงื่อนไขใน C #, IComparer<T>ที่ให้การดำเนินการของ "กลศาสตร์สำเร็จรูป" ที่เหลืออยู่ของการเรียงลำดับรวมถึงการดึงข้อมูลจากแบบจำลองขึ้นอยู่กับมุมมอง

— dasblinkenlight

3

".. ตรรกะการเรียงลำดับอยู่ในคอนโทรลเลอร์ .. "นี่หมายความว่าอย่างไร

— tereško

3

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

— ซามูเอลเอ็ดวินวอร์ด

1

@ KyleM แต่มุมมองไม่ได้มีความรู้เพียงพอที่จะมีตรรกะการเรียงลำดับ ตัวอย่างเช่นพิจารณาข้อมูลที่มีรหัสตัวเลขตรงกับหนึ่งใน {Unknown, Pass, Fail}enums สันนิษฐานว่าUnknownจะต้องเรียงลำดับสุดท้ายเสมอโดยไม่คำนึงถึงลำดับที่ขึ้นหรือลงที่ผู้ใช้เลือก การวางตรรกะนี้ในมุมมองจะบอกมุมมองของคุณมากเกินไปเกี่ยวกับลักษณะธุรกิจของข้อมูลในเขตcodeข้อมูล มุมมองไม่ควรรู้: ทั้งหมดที่รู้ก็คือผู้ใช้ดำเนินการ "เรียงลำดับ" ท่าทาง (เช่นคลิกส่วนหัว) ส่วนที่เหลือขึ้นอยู่กับตัวควบคุม

— dasblinkenlight

10

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

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

ในกรณีดังกล่าวการเรียงลำดับคือ "ในคอนโทรลเลอร์" แต่โค้ดของตัวเองที่ทำการเรียงลำดับไม่ควรนำมาใช้ในคอนโทรลเลอร์เรียกใช้จากที่นั่นเท่านั้น

— นนท์
แหล่งที่มา

5

ฉันเพิ่งได้รับแจ้งว่าบางคนพิจารณา "service layer" (ตรรกะทางธุรกิจ) เพื่อเป็นส่วนหนึ่งของโมเดล

— Marvo

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

— ไม่

แล้วตรรกะทางธุรกิจ "สด" ในรูปแบบ MVC อยู่ที่ไหน

— Marvo

2

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

— ไม่

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

— Marvo

8

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

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

หากการสั่งซื้อเป็นส่วนหนึ่งของโดเมนมันควรจะอยู่ในรูปแบบ

— Jens Schauder
แหล่งที่มา

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

— dasblinkenlight

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

— Jens Schauder

6

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

ดังนั้นทางเลือกคือ - คุณคิดว่านี่เป็นส่วนหนึ่งของตรรกะทางธุรกิจโดเมนหรือตรรกะการนำเสนอ

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

แต่เนื่องจากคุณใช้การตีความ ASP.NET MVC ของรูปแบบ MVC ซึ่งแตกต่างกันเล็กน้อยจาก MVC มาตรฐานของคุณอินสแตนซ์ ViewModel ควรขอข้อมูลที่สั่งจากเลเยอร์โมเดล (ด้วยเหตุผลบางอย่างกรอบ ASP.NET คิดว่าแม่แบบควรจะเรียกว่า "มุมมอง" และมุมมองควรเรียกว่า "viewmodels" .. มันแปลก)

— tereško
แหล่งที่มา

12

คุณได้ลดคำตอบลงหลายคำโดยใช้สมมติฐานของคุณเองว่าพวกเขามีความหมายอย่างไรกับ สมมติฐานของคุณไม่ถูกต้องอย่างสมบูรณ์ - ตรรกะการเรียงลำดับไม่รวมถึงการดึงข้อมูล

— dasblinkenlight

1

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

— tereško

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

— dasblinkenlight

@dasblinkenlight naah .. ฉันโกรธเกี่ยวกับความคิดเห็นของฉันซึ่งในหัวข้อนี้เกิดขึ้นหายไป

— tereško

5

ฉันมักจะทำในคอนโทรลเลอร์เพื่อให้สอดคล้องกับรูปแบบตามคำตอบอื่น ๆ ดูเหตุผลด้านล่าง

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

มันเป็นแอปพลิเคชั่นขนาดกลาง / ใหญ่และ / หรือมีหลาย UI ที่เชื่อมโยงกับมัน (เช่น Windows App, เว็บอินเตอร์เฟสและโทรศัพท์อินเตอร์เฟส)

ในกรณีนี้ฉันอาจจะสร้างเลเยอร์บริการและวางไว้ในวัตถุธุรกิจแล้วเรียกวิธีการที่เหมาะสมจากตัวควบคุม

หากเป็นเว็บไซต์ UI เดียวที่กำหนดไว้อย่างดีและคุณกำลังใช้บางสิ่งบางอย่างเช่น EF Code First และคุณไม่มีหรือไม่ต้องการสร้างเลเยอร์บริการและวางแผนในการใช้วิธีขยายออกจากกล่องอย่างง่าย ๆ เพื่อให้บรรลุ:

ในกรณีนี้ฉันอาจจะใส่มันไว้ในคอนโทรลเลอร์เพราะมันเหมาะสมที่สุดกับเวลา / งบประมาณ

ถ้ามันเหมือนกับ BUT ข้างต้นไม่สามารถใช้งานได้ด้วยวิธีการขยายออกนอกกรอบ

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

เพื่อสรุป:

คำตอบที่ดันทุรัง: บริการชั้น

คำตอบในทางปฏิบัติ: โดยปกติแล้วตัวควบคุม

— ลุคแบนฮาน
แหล่งที่มา

คำจำกัดความตัวควบคุมใดที่รับผิดชอบในการ "เตรียมข้อมูลสำหรับการดู"

— tereško

1

@ tereško: โดยที่โมเดลเป็น "passive" ดังที่ได้อธิบายไว้ที่นี่msdn.microsoft.com/en-us/library/ff649643.aspxในส่วนชุดรูปแบบ ดู "HTTP เป็นตัวอย่างของสิ่งนี้" ในขณะที่คนพิถีพิถันอาจโต้แย้งเรื่องนี้มันจะง่ายขึ้นสำหรับผู้เริ่มต้นเริ่มต้นใน MVC ที่พวกเขาอาจจะใช้ EF หรือรุ่นอื่น ๆ โดยตรงในตัวควบคุมและไม่ผ่าน BAL ที่จะคิดว่ามันเป็นวิธีลดอุปสรรคในการทำความเข้าใจรูปแบบต่อไป

— Luke Baughan

1

สิ่งที่คุณกำลังพูดถึงคือ "แบบจำลองโลหิตจาง"

— tereško

ข้อสังเกต: ฉันได้ลบคำอธิบายการละเมิดตามที่คุณแนะนำ ไชโยสำหรับการป้อนข้อมูล!

— Luke Baughan

3

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

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

— B0nk3r
แหล่งที่มา

2

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

แต่ ... คำตอบเหล่านี้ดูเหมือนจะไม่ได้คำนึงถึงความก้าวหน้าในเทคโนโลยี ORM ฉันสามารถพูดคุยเกี่ยวกับ Entity Framework (ขอหลีกเลี่ยงการโต้แย้งว่านี่เป็น ORM จริงไม่ใช่ประเด็น) จาก Microsoft เป็น นั่นคือสิ่งที่ฉันใช้ แต่ฉันแน่ใจว่า ORM อื่น ๆ มีฟังก์ชันการทำงานที่คล้ายกัน

ถ้าฉันสร้างมุมมองที่พิมพ์อย่างแน่นหนาสำหรับคลาสผลิตภัณฑ์โดยใช้ MS MVC และ Entity Framework และมีความสัมพันธ์กับคีย์ต่างประเทศระหว่างตารางผลิตภัณฑ์และรูปภาพ (เช่น FK_Product_Image_ProductId) ฉันจะสามารถจัดเรียงกล่องได้อย่างรวดเร็ว ภาพในระหว่างการแสดงผลของพวกเขาโดยใช้สิ่งนี้ในมุมมอง:

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

มีการกล่าวถึงชั้น Business Logic ที่เฉพาะเจาะจงซึ่งฉันยังใช้เพื่อดำเนินการตรรกะทางธุรกิจของฉัน 80% แต่ฉันจะไม่เขียนฟังก์ชันการเรียงลำดับลงในชั้น Business Logic ของฉันที่เลียนแบบบางสิ่งที่ออกมานอกกรอบ จาก Entity Framework

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

— ปล้น
แหล่งที่มา

ฉันคิดในสิ่งเดียวกันคำตอบที่นี่ดูเหมือนจะไม่ได้นำมาพิจารณา ORM และวิธีการขยาย ในกรณีส่วนใหญ่ตรรกะการเรียงลำดับจะง่ายเหมือนmyList.OrderBy(x => x.CreationDate)- ไม่จำเป็นต้องแนะนำเลเยอร์พิเศษใด ๆ ที่ไม่จำเป็นเพียงแค่ทำสิ่งนี้ ในการเพิ่มสิ่งนี้พวกเขาจะทำอย่างไรถ้าพวกเขาต้องการข้อมูลเพจและจัดเรียง? ค้นหาตารางทั้งหมดเรียงลำดับจากนั้นรักษาสิ่งที่ต้องการ หนึ่งสามารถโทรmyList.OrderBy(x => x.Date).Skip((page-1)*pageSize).Take(pageSize)และไม่มีการดึงข้อมูลที่ไม่จำเป็น

— Balázs

1

สมมติว่าคุณมีเว็บไซต์ MVC เว็บไซต์ WebForms และแอปพลิเคชันมือถือ

หากคุณต้องการเรียงลำดับให้สอดคล้องกันระหว่างเลเยอร์การนำเสนอเหล่านี้ฉันจะบอกว่าเรียงลำดับนอกเลเยอร์การนำเสนอ การบริการจะเป็นตัวเลือกที่ดี

มิฉะนั้นฉันจะเก็บตรรกะนั้นไว้ในมุมมองโมเดล ทำไม? เพราะมันจะสามารถนำมาใช้ซ้ำได้และทดสอบได้ง่าย

0

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

— Dismissile
แหล่งที่มา

2

นั่นจะทำให้ตรรกะมากกว่านี้ในด้านโมเดลใช่ไหม?

— Ryan Kohn

ใช่ความเข้าใจของฉันเกี่ยวกับ "ชั้นบริการ" คือมันเป็นส่วนหนึ่งของแบบจำลอง

— Marvo

0

นี่เป็นคำถามที่ถามกับ asp.net ในใจ แต่เนื่องจากมีคนพูดถึง Rails ฉันคิดว่ามันน่าสนใจที่จะพิจารณาปัญหาในบริบทนั้น ใน Rails มันเป็นเรื่องธรรมดาและค่อนข้างธรรมดาที่จะทำการจัดเรียงพร้อมกับการดึงข้อมูลเป็นแอ็คชั่นคอนโทรลเลอร์เนื่องจากเฟรมเวิร์กและบทบัญญัติของ ActiveRecord / ActiveQuery api ในทางกลับกันมันเป็นไปได้ที่จะกำหนดลำดับการเรียงลำดับแบบกำหนดเองสำหรับไอเท็มแบบสแตติกและวางไว้ในโมเดลที่จะใช้โดยคอนโทรลเลอร์ดังนั้นโมเดลสามารถมีส่วนร่วมในตรรกะการเรียงลำดับแม้ว่ามันจะไม่ได้ดำเนินการ การดำเนินการโดยตรง ไม่ว่าจะเป็นอะไรก็ตามสามารถพูดได้ว่าการวางตรรกะการเรียงลำดับไว้ในมุมมองนั้นเป็นเรื่องที่ขมวดคิ้ว

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

— prusswan
แหล่งที่มา