MVC ต่อต้าน OOP ไม่ใช่หรือ

62

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

ในรูปแบบ Model-View-Controller ข้อมูลและตรรกะ / อัลกอริธึมจะถูกวางไว้ในเอนทิตีที่แตกต่างกันโมเดลและคอนโทรลเลอร์ตามลำดับ ในวิธีการ OOP ที่เทียบเท่ากันไม่ควรวางโมเดลและคอนโทรลเลอร์ไว้ในเอนทิตีแบบโลจิคัลเดียวกัน

design object-oriented mvc

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

11

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

— Robert Harvey

26

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

— Robert Harvey

2

อะไร? การรวมข้อมูลและพฤติกรรมเข้าด้วยกันเป็นสิ่งที่ OOP ให้ความสำคัญ

— Andy

3

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

— Kaz

5

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

— Kaz

45

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

ในทางทฤษฎีวัตถุทั้งหมดสามารถมีพฤติกรรมที่ดำเนินการเกี่ยวกับข้อมูลที่พวกเขามีและว่าข้อมูลและพฤติกรรมยังคงห่อหุ้ม ในทางปฏิบัติวัตถุ OOP ที่กำหนดอาจมีหรือไม่มีตรรกะที่สอดคล้องกับข้อมูลหรืออาจไม่มีตรรกะใด ๆ เลยก็ได้ (เช่นData Transfer Object )

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

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

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

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... และพฤติกรรมนั้นจะถูกห่อหุ้มด้วยวัตถุสกุลเงิน

แต่ถ้าฉันต้องการโอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่งหรือฝากบางสกุลเงินล่ะ? พฤติกรรมนั้นจะถูกห่อหุ้มในวัตถุสกุลเงินด้วยหรือไม่ ไม่มันจะไม่ เงินในกระเป๋าเงินของคุณไม่สามารถโอนออกจากกระเป๋าเงินของคุณไปยังบัญชีธนาคารของคุณได้ คุณต้องการตัวแทนอย่างน้อยหนึ่งราย (พนักงานรับเงินหรือ ATM) เพื่อช่วยในการรับเงินนั้นเข้าสู่บัญชีของคุณ

ดังนั้นพฤติกรรมนั้นจะถูกห่อหุ้มอยู่ในTellerวัตถุและมันจะยอมรับCurrencyและAccountวัตถุเป็นอินพุต แต่มันจะไม่ประกอบด้วยข้อมูลใด ๆ เองยกเว้นอาจจะเป็นบิตของสถานะท้องถิ่น (หรืออาจเป็นTransactionวัตถุ) เพื่อช่วยในการประมวลผลวัตถุอินพุต

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

และควรTellerวางเอนทิตี / แพ็คเกจใดใน ในControllerจากที่Teller'sวิธีการที่เรียกว่าหรือในModelเพราะมันเป็นส่วนหนึ่งของเหตุผลทางธุรกิจหรือไม่

— m3th0dman

TellerไปในModelแม้ว่ามันจะสามารถเรียกได้จากตัวควบคุม มันเป็นส่วนหนึ่งของโดเมนธุรกิจ

— Robert Harvey

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

— Yam Marcovic

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

— Robert Harvey

5

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

— Erik Reppen

73

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

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

— Michael Borgwardt
แหล่งที่มา

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

— m3th0dman

6

@ m3th0dman: คุณกำลังพูดกว้าง ๆ ทั่วไปกวาด เช่นเดียวกับที่ MVC กำจัดฝันร้ายของรหัสสปาเก็ตตี้นั่นคือ Winforms หรือ Webforms

— Robert Harvey

3

@ m3th0dman: นั่นเป็นลักษณะที่เรียบง่ายของ DDD

— Michael Borgwardt

1

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

— จิมมี่ฮอฟฟา

1

@ Robert Harvey จุดประสงค์ของคำถามไม่ได้เกี่ยวกับ MVC ว่าดีหรือไม่ดี มันเกี่ยวกับความจริงที่มีพื้นฐานมาจากหรือไม่ได้อยู่บนหลักการของ OO

— m3th0dman

71

OOP ไม่ได้ จำกัด การโต้ตอบระหว่างวัตถุที่แต่ละคนมีข้อมูลของตัวเองและพฤติกรรมของพวกเขาเอง

ลองนึกถึงมดและมดกลุ่มเปรียบเทียบ: พฤติกรรมของมดแต่ละตัว (วิ่งไปรอบ ๆ ทั้งวันนำอาหาร) แตกต่างจากพฤติกรรมของอาณานิคมโดยรวม (หาสถานที่ที่ต้องการมากที่สุดสร้างมดมากขึ้น) รูปแบบ MVC อธิบายโครงสร้างทางสังคมที่ต้องการของฝูงมดในขณะที่ OOP เป็นแนวทางในการออกแบบมดแต่ละตัว

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

5

+1: ฉันมักจะไม่ชอบคำอธิบายผ่านการเปรียบเทียบ แต่อันนี้ยอดเยี่ยม

— Michael Borgwardt

@Caleb นี่เป็นจุดที่ยอดเยี่ยมขอบคุณมาก!

— dasblinkenlight

19

OOP ยังเกี่ยวกับการแยกความกังวลนั่นคือการแยกบทบาท / ความรับผิดชอบที่แตกต่างกันในวัตถุที่แตกต่างกัน

MVC แยกออกเป็นองค์ประกอบเหล่านี้:

รุ่น: ข้อมูลและตรรกะทางธุรกิจ
มุมมอง: การแสดงข้อมูล
ตัวควบคุม: การประสานงานระหว่างโมเดลและมุมมอง

ดังนั้นความรับผิดชอบเหล่านี้มีความแตกต่างอย่างชัดเจนและควรแยกออกเป็นหลาย ๆ หน่วยงานอย่างแน่นอน

— marco-Fiset
แหล่งที่มา

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

— แม็กเคเล็บ

@Caleb ใช่ฉันเข้าใจว่าคุณหมายถึงอะไร บางทีมันอาจจะถูกใช้ถ้อยคำใหม่ แต่คุณได้คะแนน

— marco-fiset

18

ในรูปแบบ Model-View-Controller ข้อมูลและตรรกะ / อัลกอริธึมจะถูกวางไว้ในเอนทิตีที่แตกต่างกันโมเดลและคอนโทรลเลอร์ตามลำดับ

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

คิดแบบนี้: ถ้าวัตถุไม่สามารถส่งผ่านข้อมูลไปมาโดยไม่ทำลาย encapsulation คุณสามารถมีเพียงวัตถุเดียว!

ในวิธีการ OOP ที่เทียบเท่ากันไม่ควรวางโมเดลและคอนโทรลเลอร์ไว้ในเอนทิตีแบบโลจิคัลเดียวกัน

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

— คาเลบ
แหล่งที่มา

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

— Matthew Flynn

1

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

— Caleb

1

@ MattFenwick นั่นคือสิ่งที่ฉันหมายถึง 'รสชาติ' ... สิ่งที่คุณเก็บไว้ในคอนโทรลเลอร์และสิ่งที่อยู่ในรูปแบบนั้นเป็นเรื่องของรสนิยมและการประชุม ใน Cocoa / Cocoa Touch เป็นเรื่องปกติที่จะเก็บสิ่งต่าง ๆ เช่นการเลือกปัจจุบันและแม้กระทั่งการตั้งค่าของผู้ใช้ในคอนโทรลเลอร์ MVC ตามที่ใช้ในบางเฟรมเวิร์คของเว็บอาจทำให้เกือบทุกอย่างในโมเดลและน้อยมากในคอนโทรลเลอร์ YMMV

— แม็กเคเล็บ

4

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

— Erik Reppen

1

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

— Jan Hudec

4

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

— Jonathan Weatherhead
แหล่งที่มา

2

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

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

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

2

เลเยอร์โมเดลไม่ได้เป็นเพียงข้อมูลใด ๆ ที่มากกว่าเลเยอร์ควบคุมเท่านั้นเป็นเพียงลอจิก

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

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

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

— Michael K
แหล่งที่มา

2

จุด OOP คือการจัดกลุ่มข้อมูลและการทำงานที่อยู่ด้วยกัน การคำนวณที่ขึ้นอยู่กับชิ้นส่วนของข้อมูลบางอย่างไม่ได้เสมออยู่กับข้อมูลที่

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

MVC ไม่ได้ขัดแย้งกับ OOP แต่จริง ๆ แล้วได้มาจากการใช้หลักการเชิงวัตถุที่ถูกต้อง

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

0

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

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

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

IMO ไม่มีอะไรบอกว่าคอนโทรลเลอร์ไม่สามารถรวมวัตถุที่มีมุมมองและแบบจำลองเป็นวัตถุรวมภายในได้ เรื่องนี้เหมาะสมถ้าคุณใช้ MVC ในระดับที่เล็กกว่าเช่นโรงงานวิดเจ็ต UI เนื่องจากคอนโทรลเลอร์เป็นสถานที่ที่เหมาะที่จะเปิดเผยส่วนต่อประสานไปยังวัตถุแอประดับสูงในขณะที่ฝังข้อมูลและรายละเอียดตรรกะในการโต้ตอบกับ View and Model มันไม่สมเหตุสมผลกับวัตถุแอปโมโนลิ ธ ที่ตัวควบคุมเป็นวัตถุระดับสูงสุดจริงๆ

— Erik Reppen
แหล่งที่มา

0

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

ตัวอย่างเช่นจุดทั้งหมดของ OOP / OOD คือการทำให้โค้ดของคุณเป็นแบบแยกส่วนและสามารถใช้ซ้ำได้ ใช่?

ซึ่งเป็นเป้าหมายของสถาปัตยกรรมตามส่วนประกอบอย่างแน่นอน ดังนั้นพวกเขาจึงเหมือนกันมากกว่าสิ่งอื่นใด

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

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

ฉันว่า MVC และ Component-Based Architecture เป็นรูปแบบการออกแบบที่ไม่ได้อยู่นอกขอบเขตของวิธีการของ OOP ในขณะที่ OOD / OOP เป็นเพียงความสับสนและการปะทะกันของโรงเรียนแห่งความคิดและ malacademia เกี่ยวกับวิธีการใช้การเขียนโปรแกรมที่มีพรมแดนติดกัน สร้างอย่างถูกต้อง การเปรียบเทียบสองประเภทของสิ่งนั้นเปรียบเสมือนการเปรียบเทียบกำลังสองกับปากกาที่คุณใช้ในการวาดสี่เหลี่ยม

— Erik Reppen

-1

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

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

(และบางทีฉันจะได้รับคะแนนลงบ้าง)

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

-1

ไม่ต่อต้าน แต่ยังไม่จำเป็นต้องใช้ OOP สำหรับ MVC

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

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

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

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

ฮ่าฮ่าฉันเห็นบางคนมีอาการปวดใน ** เมื่อเผชิญกับข้อเท็จจริง มีความพยายามมากเกินไปในการทำเฟรมเวิร์กของตัวเองด้วย OOP หรือไม่? ไม่สามารถยืนเวลาที่หายไป? คำตอบที่ง่ายที่สุดคือคำตอบที่ดีที่สุด

— luke1985

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

— mwilcox

-3

ในความเห็นของฉัน OOPs มีข้อเสียเปรียบที่เนื่องจาก (ข้อมูลและพฤติกรรม) ถูกหล่อหลอมเป็นเอนทิตีหนึ่ง (คลาส) สิ่งนี้แสดงให้เห็นถึงผลของการมีเพศสัมพันธ์มากกว่าการทำงานร่วมกัน ในขณะที่ MVC มีรูปแบบที่ประกอบด้วย ... (ถั่ว, DAOs, คลาสลอจิกอื่น ๆ ), ตัวควบคุมที่ระบุวิธีที่ตัวควบคุมต้องเดินทางและมุมมองเพื่อกำหนดวิธีการแสดงข้อมูลที่ได้รับในลักษณะแยก จากเรื่องนี้ไม่ว่าโครงการจะใหญ่เกินไปที่จะเตรียมความพร้อมสามารถแยกเป็นเอนทิตี้อื่น ๆ ได้ง่ายกว่าการผสมแบบไม่เหมือนกับ OOP ปัญหาได้รับการแก้ไขในรูปแบบเชิงตรรกะเช่นเดียวกับการแบ่งกลยุทธ์การพิชิตและ MVC ทำตามนี้มากที่สุด

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

นี่เป็นเพียงความคิดเห็นของคุณหรือคุณสามารถสำรองข้อมูลได้

— ริ้น