การเขียน Data Access / Data Mapping Layer ของคุณเป็นแนวคิดที่“ ดี” หรือไม่?

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

เรามีแอปพลิเคชั่นรุ่นเก่า (ASP.NET + SQL Server) ที่ซึ่ง data-layer & business-layer ถูกบดเข้าด้วยกันอย่างน่าเสียดาย ระบบไม่ซับซ้อนโดยเฉพาะอย่างยิ่งในแง่ของการเข้าถึงข้อมูล มันอ่านข้อมูลจากกลุ่มขนาดใหญ่ (35-40) ของตารางที่เกี่ยวข้องระหว่างจัดการกับมันในหน่วยความจำและบันทึกมันกลับไปที่ตารางอื่น ๆ ในรูปแบบสรุป ตอนนี้เรามีโอกาสในการปรับโครงสร้างใหม่และกำลังมองหาเทคโนโลยีที่จะใช้ในการแยกและจัดโครงสร้างการเข้าถึงข้อมูลของเราอย่างเหมาะสม

เทคโนโลยีใดก็ตามที่เราตัดสินใจเราต้องการ:

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

เห็นได้ชัดว่ามีหลายสิ่งในนี้อยู่แล้วในแง่ของรูปแบบและกรอบ ฯลฯ

ส่วนตัวผมกำลังผลักดันให้มีการใช้ EF ร่วมกับADO.NET หน่วยทดสอบ Repository Generator / POCO Entity ปั่นไฟ สามารถตอบสนองความต้องการทั้งหมดของเราสามารถรวมเข้ากับรูปแบบ Repo / UnitOfWork ได้อย่างง่ายดายและโครงสร้างฐานข้อมูลของเรานั้นมีความเป็นผู้ใหญ่ที่สมเหตุสมผล

อย่างไรก็ตามคนอื่น ๆ ในกลุ่มกำลังแนะนำให้สถาปนิก / กลิ้ง DAL ของเราเองอย่างสมบูรณ์ตั้งแต่เริ่มต้น (DataMappers แบบกำหนดเอง, DataContexts, Repository, อินเทอร์เฟซทุกที่, overkill การพึ่งพาการพึ่งพาเพื่อสร้างออบเจกต์คอนกรีต, การแปลคำสั่ง LINQ-to-Underlying แบบกำหนดเอง, การนำแคชแบบกำหนดเองไปใช้ ฉันเป็นบ้า

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

ดังนั้น devs / สถาปนิกที่มีประสบการณ์สูงของคุณออกมามีคำใด ๆ ของภูมิปัญญาที่อาจช่วยให้ฉันคัดท้ายผลิตภัณฑ์นี้ออกไปจากสิ่งที่ฉันคิดว่ามันจะเป็นหายนะที่สมบูรณ์ ฉันอดไม่ได้ที่จะคิดว่าผลประโยชน์ใด ๆ ที่ได้รับจากการหลบปัญหาของ EF จะหายไปอย่างรวดเร็วด้วยการพยายามคิดค้นล้อใหม่

ทั้งสองข้อโต้แย้งกับ ORM ที่มีอยู่ไม่ถูกต้อง:

"อย่างน้อยเราก็สามารถควบคุมรหัสของเราได้"

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

"โอ้ฉันใช้ L2S / EF ในโครงการก่อนหน้านี้และมันก็ไม่มีอะไรนอกจากปวดหัว"

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

ดังนั้นคุณต้องเขียน ORM ของคุณเองหรือไม่?

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

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

แน่นอนว่าไม่มีอะไรห้ามให้คุณเขียน ORM ของคุณเองออกมาจากความอยากรู้อยากเห็นเพื่อเรียนรู้สิ่งต่าง ๆ แต่คุณไม่ควรทำในโครงการเชิงพาณิชย์

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

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

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

บรรทัดล่างคือมันสามารถทำให้รู้สึกภายใต้เงื่อนไขที่เหมาะสม เงื่อนไขเหล่านี้โดยทั่วไปรวมถึง:

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

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

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

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

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

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

แก้ไข:

ถ้าฉันต้องการที่จะน่ารังเกียจโดยเฉพาะอย่างยิ่ง (หรือ "การศึกษา" - ยากที่จะบอกความแตกต่างในกรณีนี้) ฉันอยากให้คุณแต่ละคนพยายามประเมินการพัฒนาโดยรวมทั้งการใช้ ORM / DAL ที่มีอยู่และการพัฒนา ของคุณเอง แม้ว่ามันจะเป็นเพียงการคาดเดา แต่ฉันเดาได้ทันทีว่าคนส่วนใหญ่ที่มีแผนยิ่งใหญ่สำหรับการกลิ้งของตัวเองจะไม่สนใจที่จะหันมาประมาณการ - เมื่อถึงเวลาที่พวกเขามาถึงการประเมินความพยายามโดยรวม (และสมจริง) พวกเขารู้ว่าไม่มีทางที่พวกเขาจะได้ใกล้เคียงกับการแข่งขันโดยใช้รหัสที่มีอยู่ ในขณะเดียวกันก็ '

แก้ไข 2: (เรียงลำดับตามคำแนะนำของ @ CmdKey): แม้ว่าจะไม่ได้กล่าวถึงอย่างชัดเจน แต่ฉันถือว่าการประมาณการจะรวมถึงการประเมินความเสี่ยงโดยปริยาย โดยเฉพาะอย่างยิ่งการประมาณเวลาควรมีหมายเลขสไตล์ PERT:

1. การประเมินกรณีที่ดีที่สุดเกี่ยวกับความเร็วที่ทำได้ถ้าทุกอย่างถูกต้อง
2. ค่าประมาณ "ปกติ" - ระยะเวลาที่คุณคาดว่าจะใช้
3. การประเมินกรณีที่เลวร้ายที่สุดที่ยาวที่สุดอาจเกิดขึ้นได้หากทุกอย่างผิดพลาด

แน่นอนการประมาณการที่ดีที่สุดและแย่ที่สุดไม่ควรรวมสิ่งต่าง ๆ เช่นการแทรกแซงจากพระเจ้าโดยตรง แต่ควรรวมอะไรก็ตามที่สั้น

โดยปกติแล้วมันไม่ใช่ความคิดที่ดีที่จะบูรณาการล้อและการทำเช่นนี้มักจะเป็นข้อบ่งชี้สำหรับความไม่รู้ทางเทคนิค ("ฉันไม่รู้อะไรเลยและไม่ต้องการเรียนรู้") หรือความหยิ่ง ("X โง่มากฉันสามารถ เขียนเครื่องมือของฉันเองในอีกสองสัปดาห์! "); มีเครื่องมือสำหรับผู้ใหญ่ที่สามารถทำสิ่งต่าง ๆ ได้ดีกว่าสิ่งที่นักพัฒนาซอฟต์แวร์ทั่วไปสามารถแฮ็คด้วยกันได้ในสองสามสัปดาห์

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

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

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

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

ฉันจะบอกว่าการเปิดตัว ORM ของคุณเป็นความคิดที่ไม่ดี - ถ้าคุณไม่มีเหตุผลที่ดีมากในการทำเช่นนั้น (btw. สิ่งที่คุณอ้างไม่ดีพอ :)

ฉันทำผิดพลาดเมื่อมีคนอื่นโน้มน้าวให้ฉันไม่ใช้ ORM และฉันสามารถบอกคุณได้ว่าการเขียน DAL ทั้งหมดทำให้เราช้าลงจริง ๆ และแทนที่จะใช้คุณลักษณะที่สำคัญสำหรับธุรกิจที่เราใช้เวลากับ DAL (มันทำงานได้มากขึ้น กว่าที่เห็น)

EF ใหม่นั้นค่อนข้างดี แต่ถ้าคุณต้องการการควบคุมที่มากขึ้น - ฉันชอบที่ ORM / s เช่น: Drapper http://code.google.com/p/dapper-dot-net/หรือ PetaPOCO http : //www.toptensoftware.com/petapoco/

คุณยังสามารถมิกซ์แอนด์แมทช์ - ใช้ EF สำหรับสิ่งของและ Drapper จำนวนมากเพื่อการปรับจูน

อย่างไรก็ตามนั่นเป็นเพียง 2c ของฉัน;)