รู้เบื้องต้นเกี่ยวกับ Ruby on Rails Patterns และ Anti-patterns

ยินดีต้อนรับสู่โพสต์แรกในซีรีส์ของเราเกี่ยวกับ Ruby on Rails Patterns และ Anti-patterns ในแต่ละโพสต์ เราจะเจาะลึกถึงรูปแบบต่างๆ ที่คุณอาจพบขณะใช้งานแอป Rails

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

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

ใช่ คุณเป็นนักออกแบบ

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

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

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

รูปแบบการออกแบบคืออะไร

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

รูปแบบการออกแบบจะแสดงให้คุณเห็นถึงวิธีการแก้ปัญหา แต่จะไม่ให้โค้ดที่พร้อมจะเสียบเข้ากับซอฟต์แวร์ที่เหลือของคุณ คิดว่า apattern เป็นแนวทางในการเขียนโค้ดที่ออกแบบมาอย่างดี แต่คุณต้องมาพร้อมกับการใช้งาน การใช้รูปแบบในการเขียนโค้ดแบบวันต่อวันเกิดขึ้นในช่วงปลายยุค 80 โดยที่ Kent Beck และ Ward Cunningham ได้เกิดแนวคิดในการใช้ 'ภาษาที่มีรูปแบบ'

แนวคิดเรื่องภาษารูปแบบเกิดขึ้นในช่วงปลายทศวรรษที่ 70 โดยคริสโตเฟอร์ อเล็กซานเดอร์ในหนังสือของเขา ภาษารูปแบบ คุณอาจจะแปลกใจ แต่หนังสือเล่มนี้ไม่ได้เกี่ยวกับวิศวกรรมซอฟต์แวร์ แต่เป็นสถาปัตยกรรมของอาคาร ภาษาของรูปแบบคือชุดของรูปแบบที่เป็นระเบียบและสอดคล้องกัน ซึ่งแต่ละชุดจะอธิบายถึงปัญหาและแก่นของโซลูชันที่สามารถนำมาใช้ได้หลายวิธี เสียงที่คุ้นเคย? (คำใบ้:กรอบงาน คำใบ้อื่น:Rails)

ต่อมา รูปแบบการออกแบบในวิศวกรรมซอฟต์แวร์เริ่มโด่งดังจากผู้ชมจำนวนมากหลังจากหนังสือในตำนาน Design Patterns โดย the Gang Of Four ตีพิมพ์ในปี 1994 ในหนังสือมีคำอธิบายและคำจำกัดความของรูปแบบที่ใช้อยู่ในปัจจุบัน ได้แก่ Factory, Singleton, Decorator เพียงเพื่อชื่อ เล็กน้อย

เยี่ยมมาก ตอนนี้เราได้ทำความคุ้นเคยหรือฟื้นฟูความรู้เกี่ยวกับการออกแบบและรูปแบบแล้ว มาดูกันว่าการต่อต้านรูปแบบคืออะไร

การออกแบบต่อต้านรูปแบบคืออะไร

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

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

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

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

สิ่งเหล่านี้เกิดขึ้นและจะเกิดขึ้น คนดีหันไปซื้อของไม่ดี และในทางกลับกัน แต่รูบี้กับเรลส์เหมาะกับภาพนี้ที่ไหนกันนะ

Ruby ก่อน แล้วก็ Rails

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

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

ฉันมีปัญหานี้และฉันแน่ใจว่าผู้เริ่มต้นและผู้เริ่มต้นขั้นสูงจำนวนมากต้องทนทุกข์กับมัน คุณเริ่มต้นด้วยกรอบงานในมือ คุณสร้างมันขึ้นมา และเมื่อคุณพยายามเพิ่มสิ่งที่กำหนดเองอย่างสูง คุณทำไม่ได้ เพราะคุณใช้จุดวิเศษทั้งหมดจากกรอบงานนั้นแล้ว เมื่อถึงจุดนั้น คุณต้องกลับไปที่จุดเริ่มต้นและเรียนรู้พื้นฐาน การกลับไปไม่ใช่เรื่องใหญ่เกิดขึ้นกับสิ่งที่ดีที่สุดของเรา แต่ปัญหาจะยิ่งมีนัยสำคัญมากขึ้นหากคุณเดินหน้าต่อไปโดยไม่ได้เรียนรู้สิ่งสำคัญ เช่น ใน Ruby หนังสือดีเล่มหนึ่งที่ช่วยคุณได้ในเรื่องนี้คือ The Well-Grounded Rubyist

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

MVC:ขนมปังและเนยของ Rails

ตกลง แต่แล้ว MVC ล่ะ รูปแบบ Model-View-Controller มีอยู่ในอาหารสัตว์ มีการใช้เฟรมเวิร์กมากมายในภาษาต่างๆ เช่น Ruby (Rails), Python (Django), Java (Play, Spring MVC) แนวคิดคือการมีองค์ประกอบที่แยกจากกันซึ่งแต่ละส่วนทำงาน:

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

ฟังดูดีในทางทฤษฎี และจะดีมากเมื่อตรรกะมีน้อยและเว็บไซต์ของคุณไม่มีตรรกะที่ซับซ้อน นั่นคือสิ่งที่ยาก แต่เราจะไปถึงที่นั่นในไม่กี่วินาที

MVC แผ่กระจายไปทั่วชุมชนการพัฒนาเว็บอย่างไฟป่า ไลบรารี่อย่าง React ซึ่งเป็นที่นิยมอย่างมากในทุกวันนี้ มีการอธิบายว่าเป็นเลเยอร์มุมมองของเว็บแอปของคุณ ไม่มีรูปแบบอื่นใดที่ได้รับความนิยมมากจนไม่สามารถสลัดออกได้ Rails ได้เพิ่มPublish-Subscribewith ActionCable โดยที่แนวคิดของช่องถูกอธิบายว่าเป็นผู้ควบคุมรูปแบบ MVC

แต่รูปแบบการต่อต้านมีอะไรบ้าง ในรูปแบบที่ใช้กันอย่างแพร่หลาย? มาดูรูปแบบการต่อต้านที่พบบ่อยที่สุดบางส่วนสำหรับแต่ละส่วนของรูปแบบ MVC กัน

ปัญหาเกี่ยวกับโมเดล

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

รูปแบบ 'Fat Model, Skinny Controller' ที่มีชื่อเสียงระบุว่าเป็นคนเลวและเป็นคนดี เราจะบอกว่าการมีไขมันแบบใดแบบหนึ่งเป็นการต่อต้านรูปแบบ เพื่อให้เข้าใจดีขึ้น มาดูตัวอย่างกัน ลองนึกภาพว่าเรามีบริการสตรีมมิ่งอย่าง Spotify หรือ Deezer ข้างในมีโมเดลเพลงแบบนี้:

class Song < ApplicationRecord
  belongs_to :album
  belongs_to :artist
  belongs_to :publisher
 
  has_one :text
  has_many :downloads
 
  validates :artist_id, presence: true
  validates :publisher_id, presence: true
 
  after_update :alert_artist_followers
  after_update :alert_publisher
 
  def alert_artist_followers
    return if unreleased?
 
    artist.followers.each { |follower| follower.notify(self) }
  end
 
  def alert_publisher
    PublisherMailer.song_email(publisher, self).deliver_now
  end
 
  def includes_profanities?
    text.scan_for_profanities.any?
  end
 
  def user_downloaded?(user)
    user.library.has_song?(self)
  end
 
  def find_published_from_artist_with_albums
    ...
  end
 
  def find_published_with_albums
    ...
  end
 
  def to_wav
    ...
  end
 
  def to_mp3
    ...
  end
 
  def to_flac
    ...
  end
end

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

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

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

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

class NotifyFollowers < ApplicationJob
  def perform(followers)
    followers.each { |follower| follower.notify }
  end
end
 
class NotifyPublisher < ApplicationJob
  def perform(publisher, song)
    PublisherMailer.song_email(publisher, self).deliver_now
  end
end

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

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

class SongDecorator < Draper::Decorator
  delegate_all
 
  def includes_profanities?
    object.text.scan_for_profanities.any?
  end
 
  def user_downloaded?(user)
    object.user.library.has_song?(self)
  end
end

จากนั้นให้เรียก decorate ในคอนโทรลเลอร์ของคุณ เช่น:

def show
  @song = Song.find(params[:id]).decorate
end

และใช้ในมุมมองของคุณดังนี้:

<%= @song.includes_profanities? %>
<%= @song.user_downloaded?(user) %>

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

module SongFinders
  def find_published_from_artist_with_albums
    ...
  end
 
  def find_published_with_albums
    ...
  end
end
 
module SongConverter
  def to_wav
    ...
  end
 
  def to_mp3
    ...
  end
 
  def to_flac
    ...
  end
end

โมเดลเพลงจะขยาย SongFinders โมดูล ดังนั้นเมธอดของมันจึงพร้อมใช้งานเป็นเมธอดของคลาส โมเดลเพลงจะมี SongConverter โมดูล ดังนั้นเมธอดของมันจึงมีอยู่ในอินสแตนซ์ของโมเดล

ทั้งหมดนี้น่าจะทำให้โมเดล Song ของเราดูเพรียวบางและตรงประเด็น:

class Song < ApplicationRecord
  extend SongFinders
  include SongConverter
 
  belongs_to :album
  belongs_to :artist
  belongs_to :publisher
 
  has_one :text
  has_many :downloads
 
  validates :artist_id, presence: true
  validates :publisher_id, presence: true
 
  after_update :alert_artist_followers, if: :published?
  after_update :alert_publisher
 
  def alert_artist_followers
    NotifyFollowers.perform_later(self)
  end
 
  def alert_publisher
    NotifyPublisher.perform_later(publisher, self)
  end
end

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

ดูปัญหา

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

ไม่ว่าในกรณีใด การต้องจัดการกับ HTML, CSS, JS และ Ruby ในที่เดียวกันอาจทำให้เกิดความยุ่งเหยิงได้ สิ่งที่ยุ่งยากในการสร้างมุมมอง Rails คือบางครั้งสามารถพบตรรกะของโดเมนได้ในมุมมอง นี่เป็นสิ่งที่ไม่ควรทำ เนื่องจากเป็นการทำลายรูปแบบ MVC สำหรับการเริ่มต้น

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

ปัญหาคอนโทรลเลอร์

ตัวควบคุม Rails อาจประสบปัญหาต่างๆ มากมาย หนึ่งในนั้นคือ Anti-pattern ของ Fat Controller

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

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

บทสรุป

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

รอตอนต่อไป เชียร์!

ป.ล. หากคุณต้องการอ่านโพสต์ Ruby Magic ทันทีที่ออกจากสื่อ สมัครรับจดหมายข่าว Ruby Magic ของเราและไม่พลาดแม้แต่โพสต์เดียว!