คำถามติดแท็ก dry

ฉันพยายามทำตามหลักการของDRYอย่างเคร่งครัดในที่ทำงานเสมอ ทุกครั้งที่ฉันทำซ้ำรหัสจากความเกียจคร้านมันกัดอีกครั้งในภายหลังเมื่อฉันต้องการรักษารหัสนั้นในสองแห่ง แต่บ่อยครั้งที่ฉันเขียนวิธีเล็ก ๆ (อาจเป็นรหัส 10 - 15 บรรทัด) ที่ต้องนำมาใช้ซ้ำในสองโครงการที่ไม่สามารถอ้างอิงซึ่งกันและกัน วิธีอาจเป็นสิ่งที่ต้องทำกับระบบเครือข่าย / สาย / MVVM ฯลฯ และเป็นวิธีที่มีประโยชน์โดยทั่วไปไม่เฉพาะเจาะจงกับโครงการที่ตั้งอยู่ในตอนแรก วิธีมาตรฐานในการนำรหัสนี้มาใช้ซ้ำจะเป็นการสร้างโครงการที่เป็นอิสระสำหรับรหัสที่ใช้ซ้ำได้และอ้างอิงโครงการนั้นเมื่อคุณต้องการ ปัญหาเกี่ยวกับสิ่งนี้คือเราจบลงในหนึ่งในสองสถานการณ์ที่ไม่เป็นอุดมคติ: เราจบลงด้วยโครงการเล็ก ๆ นับสิบ / ร้อยคน - แต่ละหลังมีชั้นเรียน / วิธีการเล็ก ๆ น้อย ๆ ซึ่งเราจำเป็นต้องนำมาใช้ซ้ำ มันคุ้มค่าที่จะสร้างรหัสใหม่.DLLเพียงเล็กน้อยหรือไม่? เราจบลงด้วยโครงการเดียวที่รวบรวมวิธีและชั้นเรียนที่ไม่เกี่ยวข้องเพิ่มมากขึ้น วิธีนี้เป็นสิ่งที่ บริษัท ที่ฉันเคยทำงานด้วย พวกเขามีโปรเจ็กต์base.commonที่มีโฟลเดอร์สำหรับสิ่งต่าง ๆ เช่นที่ฉันกล่าวถึงข้างต้น: เครือข่าย, การจัดการสตริง, MVVM ฯลฯ มันมีประโยชน์อย่างเหลือเชื่อ แต่การอ้างอิงมันลากโดยไม่จำเป็นด้วยรหัสที่ไม่เกี่ยวข้องทั้งหมดที่คุณไม่ต้องการ ดังนั้นคำถามของฉันคือ: ทีมซอฟต์แวร์ทำงานอย่างไรดีที่สุดเกี่ยวกับการนำรหัสขนาดเล็กไปมาระหว่างโครงการ ฉันสนใจเป็นพิเศษหากใครก็ตามที่ทำงานใน บริษัท …

102 project-management  code-reuse  projects-and-solutions  dry 

ค่อนข้างง่ายทำไมฉันจึงต้องการเขียนโค้ดที่ใช้กับทุกกรณีและข้อมูลที่ปรับขนาดได้เมื่อสิ่งที่ฉันต้องทำคือทำซ้ำกระบวนการเดียวกันสองสามครั้งด้วยการปรับแต่งเล็กน้อย ฉันไม่น่าจะต้องแก้ไขอีกในเร็ว ๆ นี้ ดูเหมือนว่าจะมีงานน้อยลงที่จะไป ... function doStuff1(){/*.a.*/} function doStuff2(){/*.b.*/} function doStuff3(){/*.c.*/} และถ้าฉันต้องการเพิ่มอะไรบางอย่าง ... function doStuff4(){/*.d.*/} และถ้าฉันต้องการลบฉันก็จะลบมัน เป็นการยากที่จะหาวิธีที่จะทำให้สิ่งเหล่านี้เป็นรูปแบบตรงไปข้างหน้าเดียวที่ฉันสามารถป้อนข้อมูลและจัดการกับทุกกรณีและทำการเปลี่ยนแปลงมากมายฉันไม่รู้สึกว่าฉันจะมี ทำ. ทำไมต้องเป็น DRY เมื่อดูเหมือนว่าการตัดแปะ + แบบเร็วจะทำงานได้น้อยลงมาก

81 code-quality  dry 

ตัวอย่างเช่นลองพิจารณาฉันมีคลาสสำหรับคลาสอื่นเพื่อขยาย: public class LoginPage { public String userId; public String session; public boolean checkSessionValid() { } } และคลาสย่อยบางส่วน: public class HomePage extends LoginPage { } public class EditInfoPage extends LoginPage { } ในความเป็นจริง subclass ไม่มีวิธีการใด ๆ ที่จะแทนที่ฉันจะไม่เข้าถึง HomePage ด้วยวิธีทั่วไปเช่น: ฉันจะไม่ทำสิ่งที่ชอบ: for (int i = 0; i < loginPages.length; i++) { …

36 inheritance  composition  dry 

ฉันมีรหัสบางอย่างที่เกือบจะเหมือนกัน แต่ใช้ประเภทที่แตกต่างกันอย่างสิ้นเชิงโดยไม่มีการสืบทอดระหว่างตัวแปรหลัก โดยเฉพาะฉันเขียนวิเคราะห์ด้วย Roslyn สำหรับ C # และ VB.NET ด้วยประเภทต่อไปนี้: Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax ฉันสงสัยว่าเนื่องจากรหัสกำลังทำสิ่งเดียวกันฉันควรเก็บไว้เป็น DRY เท่าที่จะทำได้โดยแยกออกน้อยที่สุดเท่าที่จะทำได้เป็นวิธีแยกต่างหาก (แต่เหมือนกันนอกเหนือจากชนิด) หรือแยกออกจากกันอย่างสิ้นเชิงเพราะทั้งสองวิธี การเปลี่ยนแปลงที่ไม่เกี่ยวข้องและในอนาคตอาจบังคับให้รุ่นหนึ่งเปลี่ยนแปลง แต่ไม่ใช่รุ่นอื่น ๆ (แม้ว่าจะไม่น่าเป็นไปได้) แก้ไข:หนึ่งปีหรือหลังจากนั้นฉันก็ตีปัญหาเดียวกันนี้และทีม Roslyn ช่วยฉันแก้ปัญหา: เขียนคลาสพื้นฐานที่ใช้ชื่อสามัญและมีTAttributeSyntaxพารามิเตอร์ที่ใช้งานได้เกือบทั้งหมด จากนั้นให้เขียนคลาสที่ได้รับมาพร้อมกับข้อมูลขั้นต่ำสุดที่จำเป็นต้องใช้ประเภทเฉพาะ

33 c#  design  dry 

ฉันสงสัยว่าอะไรจะดีไปในแง่ของการออกแบบ OOP ที่ดีทำความสะอาดโค้ดมีความยืดหยุ่นและหลีกเลี่ยงการดมกลิ่นของรหัสในอนาคต สถานการณ์รูปภาพที่คุณมีวัตถุที่คล้ายกันจำนวนมากที่คุณต้องการแสดงเป็นคลาส คลาสเหล่านี้ไม่มีฟังก์ชั่นเฉพาะใด ๆ เพียงแค่คลาสข้อมูลและแตกต่างกันตามชื่อ (และบริบท) ตัวอย่าง: Class A { String name; string description; } Class B { String name; String count; String description; } Class C { String name; String count; String description; String imageUrl; } Class D { String name; String count; } Class E { …

24 object-oriented  inheritance  dry 

ฉันมีหลายคลาสที่สืบทอดมาจากคลาสพื้นฐานทั่วไป Tชั้นฐานมีการเก็บรวบรวมวัตถุหลายของชนิด แต่ละคลาสเด็กต้องสามารถคำนวณค่าที่สอดแทรกจากการรวบรวมวัตถุ แต่เนื่องจากคลาสย่อยใช้ชนิดที่แตกต่างกันการคำนวณจึงแตกต่างกันเล็กน้อยจากคลาสหนึ่งไปอีกชั้น จนถึงตอนนี้ฉันได้คัดลอก / วางรหัสของฉันจากชั้นหนึ่งไปอีกชั้นหนึ่งและทำการแก้ไขเล็กน้อยกับแต่ละรายการ แต่ตอนนี้ฉันกำลังพยายามลบรหัสที่ซ้ำกันและแทนที่ด้วยวิธีการแก้ไขทั่วไปในคลาสพื้นฐานของฉัน อย่างไรก็ตามนั่นเป็นการพิสูจน์ว่าเป็นเรื่องยากมากและวิธีแก้ปัญหาทั้งหมดที่ฉันคิดว่าดูเหมือนซับซ้อนเกินไป ฉันเริ่มคิดว่าหลักการ DRY ไม่ได้นำไปใช้มากในสถานการณ์แบบนี้ แต่ฟังดูเหมือนเป็นการดูหมิ่น ความซับซ้อนเท่าไหร่เมื่อพยายามลบการทำสำเนารหัสมากเกินไป? แก้ไข: ทางออกที่ดีที่สุดที่ฉันสามารถทำได้คือ: ชั้นฐาน: protected T GetInterpolated(int frame) { var index = SortedFrames.BinarySearch(frame); if (index >= 0) return Data[index]; index = ~index; if (index == 0) return Data[index]; if (index >= Data.Count) return Data[Data.Count - 1]; return …

24 c#  code-quality  complexity  code-reuse  dry 

พิจารณาวิธีการเหล่านี้: public List<Employee> GetAllEmployees() { using (Entities entities = new Entities()) { return entities.Employees.ToList(); } } public List<Job> GetAllJobs() { using (Entities entities = new Entities()) { return entities.Jobs.ToList(); } } public List<Task> GetAllTasksOfTheJob(Job job) { using (Entities entities = new Entities()) { return entities.Tasks.Where(t => t.JobId == job.Id).ToList(); } …

23 c#  design-patterns  dry 

ฉันกำลังสร้าง REST API เพื่อแสดงการทำงานส่วนใหญ่ของ Java API ที่มีอยู่ API ทั้งสองมีไว้สำหรับใช้ภายในองค์กรของฉัน ฉันไม่ต้องออกแบบเพื่อใช้ภายนอก ฉันมีอิทธิพลเหนือ API ทั้งคู่ แต่กำลังใช้งาน REST อยู่ Java API จะยังคงใช้งานต่อไปสำหรับแอปพลิเคชันในพื้นที่ (ไม่ใช่ "เลิกใช้") แต่ REST API จะใช้สำหรับการพัฒนาใหม่ที่สำคัญ บางคลาส Java API เป็นเพียงข้อมูล (beans ที่มีคุณสมบัติ, getters, setters) และอย่างน้อยสิ่งเหล่านี้ก็เหมาะสมที่จะส่งผ่าน (ในบางรูปแบบ) ผ่าน REST API เป็นข้อมูล (ซึ่งจะถูกจัดให้อยู่ในรูปแบบ XML หรือ JSON) ตัวอย่างเช่นคลาสที่เก็บข้อมูลเกี่ยวกับเครื่องเซิร์ฟเวอร์ ฉันกำลังเผชิญกับตัวเลือกต่อไปนี้สำหรับคลาสข้อมูลเหล่านี้: ฉัน ... เปิดเผยคลาส Java ดั้งเดิม …

19 java  api  rest  coupling  dry 

ฉัน 100% ในคณะกรรมการที่มีกรณีที่หนึ่งควร แน่นอนใช้ทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ด้านการตรวจสอบข้อมูล อย่างไรก็ตามในกรอบงานและสภาพแวดล้อมที่ฉันได้ทำงานวิธีที่ฉันเห็นไม่เคยแห้ง เวลาส่วนใหญ่ไม่มีแผนหรือรูปแบบ - การตรวจสอบความถูกต้องถูกเขียนในสเป็คโมเดลและการตรวจสอบความถูกต้องจะถูกเขียนในแบบฟอร์มในมุมมอง (หมายเหตุ: ประสบการณ์มือแรกของฉันส่วนใหญ่คือ Rails, Sinatra และ PHP w / jQuery) ดูเหมือนว่ามันจะไม่ยากที่จะสร้างเครื่องกำเนิดไฟฟ้าซึ่งได้รับชุดการตรวจสอบความถูกต้อง (เช่นชื่อรุ่นเขตข้อมูลสภาพ) สามารถผลิตวัสดุทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ที่จำเป็น อีกทางหนึ่งเครื่องมือดังกล่าวสามารถทำการตรวจสอบความถูกต้องฝั่งเซิร์ฟเวอร์ (เช่นvalidatesรหัสในรูปแบบ ActiveRecord) และสร้างการตรวจสอบความถูกต้องฝั่งไคลเอ็นต์ (เช่นปลั๊กอิน jQuery ซึ่งจะถูกนำไปใช้กับแบบฟอร์ม เห็นได้ชัดว่าข้างต้นเป็นเพียง "เฮ้ฉันมีความคิดนี้" รำพึงและไม่ใช่ข้อเสนออย่างเป็นทางการ สิ่งนี้เป็นเรื่องยากกว่าที่คิดเมื่อฉันคิด นั่นนำมาสู่คำถาม: คุณจะออกแบบเทคนิค "การเขียนครั้งเดียวทำงานบนเซิร์ฟเวอร์และไคลเอนต์" ได้อย่างไรเพื่อการตรวจสอบข้อมูล หัวข้อย่อยที่เกี่ยวข้อง: เครื่องมือเช่นนี้มีอยู่สำหรับเฟรมเวิร์กเฉพาะหรือเทคโนโลยีไคลเอ็นต์เซิร์ฟเวอร์หรือไม่? gotchas หรือความท้าทายที่สำคัญด้วยการพยายามรักษาชุดตรวจสอบเพียงชุดเดียวคืออะไร

17 design  validation  dry  client-server 

ฉันเพิ่งเจอบทความ " Rule of Three " ในวิกิพีเดีย กฎข้อที่สามคือกฎการเปลี่ยนรหัสใหม่ของหัวแม่มือเพื่อตัดสินใจว่าเมื่อใดควรเปลี่ยนชิ้นส่วนของรหัสที่ทำซ้ำโดยขั้นตอนใหม่ มันระบุว่าสามารถคัดลอกรหัสหนึ่งครั้ง แต่เมื่อใช้รหัสเดียวกันสามครั้งมันจะถูกแยกลงในกระบวนการใหม่ กฎดังกล่าวได้รับการแนะนำโดย Martin Fowler ใน Refactoring และอ้างถึง Don Roberts ฉันรู้ว่านี่เป็นเพียงกฎของหัวแม่มือ แต่ทำไมมันแนะนำให้ refactor หลังจากทำซ้ำที่สอง? มีข้อเสียใด ๆ ในการปรับโครงสร้างเมื่อเราเขียนการทำซ้ำครั้งแรก

16 refactoring  dry  rule-of-three 

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

16 coding-standards  validation  dry 

สมมติว่าเรามีโมดูลซอฟต์แวร์ A ที่ใช้ฟังก์ชั่น F. โมดูล B อื่นใช้ฟังก์ชั่นเดียวกับ F ' มีหลายวิธีในการกำจัดรหัสที่ซ้ำกัน: ให้ใช้ F 'จาก B ให้ B ใช้ F จาก A ใส่ F ลงในโมดูล C ของตัวเองและปล่อยให้ทั้ง A และ B ใช้งาน ตัวเลือกเหล่านี้ทั้งหมดสร้างการพึ่งพาเพิ่มเติมระหว่างโมดูล พวกเขาใช้หลักการ DRY ที่ค่าใช้จ่ายของการมีเพศสัมพันธ์ที่เพิ่มขึ้น เท่าที่ฉันเห็นการมีเพศสัมพันธ์จะเพิ่มขึ้นเสมอหรือเมื่อถูกเช่าไปในระดับที่สูงขึ้นเมื่อใช้ DRY ดูเหมือนจะมีข้อขัดแย้งระหว่างหลักการพื้นฐานสองข้อที่สำคัญที่สุดของการออกแบบซอฟต์แวร์ (ที่จริงแล้วฉันไม่คิดว่ามันน่าแปลกใจที่มีความขัดแย้งเช่นนั้นนี่อาจเป็นสิ่งที่ทำให้การออกแบบซอฟต์แวร์ที่ดีเป็นเรื่องยากมากฉันรู้สึกประหลาดใจที่โดยทั่วไปแล้วความขัดแย้งเหล่านี้ไม่ได้ระบุไว้ในตำราเบื้องต้น) แก้ไข (เพื่อความกระจ่าง): ฉันคิดว่าความเท่าเทียมกันของ F และ F 'ไม่ใช่แค่เรื่องบังเอิญ หาก F ต้องได้รับการแก้ไข F 'จะต้องได้รับการแก้ไขในลักษณะเดียวกัน

14 design  architecture  dry  coupling 

ฉันกำลังมองหาคำแนะนำเกี่ยวกับ DRY กับการแต่งงานกันของ Code ฉันไม่ชอบที่จะทำซ้ำรหัสของฉันและฉันก็ไม่ชอบการเชื่อมต่อโค้ดระหว่างโมดูลที่ไม่เกี่ยวข้อง ดังนั้นฉันจึง refactor รหัสที่ซ้ำกันถ้าฉันพบรหัสที่ซ้ำกันเหมือนกันหนึ่งปีหลังจากที่มีการแนะนำการทำซ้ำ อย่างไรก็ตามฉันมีประสบการณ์ที่มากขึ้นซึ่งโลกแห่งความจริงนั้นไม่อาจคาดเดาได้มากขึ้นและหลังจากการปรับรหัสให้ใหม่แล้ว ตัวอย่างเช่นหากฉันมีรหัสเพื่อจัดการรถยนต์เบนซิน SUV เบนซินรถยนต์ไฟฟ้าและ SUV ไฟฟ้าสมมติว่าฉันได้รับรหัสซ้ำลงในลำดับชั้น "น้ำมัน" และลำดับชั้น "ไฟฟ้า" ทั้งคู่ลงมาจากลำดับ "ยานพาหนะ" จนถึงตอนนี้ดีมาก จากนั้น บริษัท ของฉันแนะนำรถยนต์ไฮบริดและไฮบริดกึ่งซึ่งจะต้องมีการเปลี่ยนแปลงหลักในลำดับชั้นดั้งเดิมของฉันเอง อาจจะต้องมี "องค์ประกอบ" ระหว่างน้ำมันเบนซินและลำดับชั้นไฟฟ้า เห็นได้ชัดว่าการทำสำเนารหัสไม่ดีเพราะเพิ่มเวลาในการดำเนินการเปลี่ยนแปลงร่วมกับผลิตภัณฑ์ทั้งหมดข้างต้น แต่การปรับเปลี่ยนรหัสทั่วไปทำให้ยากที่จะแนะนำรูปแบบเฉพาะของผลิตภัณฑ์และนำไปสู่ ​​"การกระโดดแบบคลาส" เป็นจำนวนมากเมื่อต้องค้นหาบรรทัดของรหัสเพื่อแก้ไขข้อบกพร่อง - การเปลี่ยนแปลงในระดับผู้ปกครองระดับสูงขึ้นสามารถทำได้ ทริกเกอร์การถดถอยข้อบกพร่องในหมู่ลูกหลานทั้งหมด หนึ่งจะสมดุลระหว่าง DRY และการมีเพศสัมพันธ์รหัสที่ไม่พึงประสงค์ได้อย่างไร

14 design  dry  coupling 

สำหรับการหลีกเลี่ยงการทำซ้ำที่ไม่เกี่ยวข้องกับ C ++ const มีกรณีที่ const_cast จะทำงานได้ แต่ฟังก์ชั่น const ส่วนตัวที่ส่งกลับไม่ใช่ const จะไม่? ในรายการC ++ ของ Scott Meyers ที่มีประสิทธิผล 3 เขาแนะนำว่า const_cast ที่รวมกับการส่งสัญญาณคงที่นั้นเป็นวิธีที่มีประสิทธิภาพและปลอดภัยในการหลีกเลี่ยงรหัสซ้ำเช่น const void* Bar::bar(int i) const { ... return variableResultingFromNonTrivialDotDotDotCode; } void* Bar::bar(int i) { return const_cast<void*>(static_cast<const Bar*>(this)->bar(i)); } เมเยอร์สอธิบายต่อไปว่าการใช้ฟังก์ชัน const เรียกฟังก์ชันที่ไม่ใช่ const นั้นเป็นอันตราย รหัสด้านล่างคือตัวอย่างที่แสดงให้เห็น: ตรงกันข้ามกับข้อเสนอแนะของเมเยอร์สบางครั้ง const_cast รวมกับตัวบล็อกคงเป็นอันตราย บางครั้งฟังก์ชั่น …

14 c++  dry  const 

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

13 database  orm  validation  dry