LINQ-to-SQL กับขั้นตอนการจัดเก็บ? [ปิด]

ฉันดูที่โพสต์ "คู่มือสำหรับผู้เริ่มต้นเพื่อ LINQ" ที่นี่ใน StackOverflow ( คู่มือผู้เริ่มต้นเพื่อ LINQ ) แต่มีคำถามติดตาม:

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

ดังนั้นคำถามคือ: สำหรับการดึงข้อมูลอย่างง่ายวิธีใดดีกว่า LINQ-to-SQL หรือ procs ที่เก็บไว้? มืออาชีพที่เฉพาะเจาะจงหรือแย้ง?

ขอบคุณ

ข้อดีบางประการของ LINQ เหนือ sprocs:

1. ความปลอดภัยประเภท : ฉันคิดว่าเราทุกคนเข้าใจสิ่งนี้
2. Abstraction : นี่คือความจริงโดยเฉพาะอย่างยิ่งกับLINQ เพื่อกิจการ สิ่งที่เป็นนามธรรมนี้ยังช่วยให้กรอบงานสามารถเพิ่มการปรับปรุงเพิ่มเติมที่คุณสามารถใช้ประโยชน์จาก PLINQเป็นตัวอย่างของการเพิ่มการสนับสนุนหลายเธรดใน LINQ การเปลี่ยนแปลงรหัสมีเพียงเล็กน้อยเพื่อเพิ่มการสนับสนุนนี้ มันจะยากกว่านี้หากทำรหัสการเข้าถึงข้อมูลที่เรียกว่า sprocs
3. การสนับสนุนการดีบัก : ฉันสามารถใช้. NET ดีบักเกอร์เพื่อตรวจแก้จุดบกพร่องแบบสอบถาม ด้วย sprocs คุณไม่สามารถดีบัก SQL ได้ง่ายและประสบการณ์นั้นผูกติดอยู่กับผู้จำหน่ายฐานข้อมูลของคุณเป็นส่วนใหญ่ (MS SQL Server มีตัววิเคราะห์แบบสอบถาม แต่บ่อยครั้งที่นั่นไม่เพียงพอ)
4. ผู้ไม่เชื่อเรื่องพระเจ้าของผู้ขาย : LINQ ทำงานกับฐานข้อมูลจำนวนมากและจำนวนฐานข้อมูลที่รองรับจะเพิ่มขึ้นเท่านั้น Sprocs ไม่สามารถเคลื่อนย้ายได้ระหว่างฐานข้อมูลเสมอเนื่องจากอาจมีการเปลี่ยนแปลงทางไวยากรณ์หรือการสนับสนุนคุณสมบัติ (ถ้าฐานข้อมูลรองรับ sprocs เลย)
5. การปรับใช้ : คนอื่น ๆ ได้กล่าวถึงเรื่องนี้ไปแล้ว แต่การปรับใช้ชุดประกอบเดียวง่ายกว่าการปรับใช้ชุด sprocs นอกจากนี้ยังเชื่อมโยงกับ # 4
6. ง่ายกว่า : คุณไม่จำเป็นต้องเรียนรู้ T-SQL เพื่อเข้าถึงข้อมูลและคุณไม่จำเป็นต้องเรียนรู้ data access API (เช่น ADO.NET) ที่จำเป็นสำหรับการเรียก sprocs สิ่งนี้เกี่ยวข้องกับ # 3 และ # 4

ข้อเสียบางประการของ LINQ กับ sprocs:

1. การรับส่งข้อมูลเครือข่าย : sprocs ต้องการ serialize ชื่อ sproc-name และข้อมูลอาร์กิวเมนต์ผ่านสายขณะที่ LINQ ส่งแบบสอบถามทั้งหมด สิ่งนี้อาจแย่ได้ถ้าคำค้นหานั้นซับซ้อนมาก อย่างไรก็ตามสิ่งที่เป็นนามธรรมของ LINQ ช่วยให้ Microsoft สามารถปรับปรุงสิ่งนี้ได้ตลอดเวลา
2. ความยืดหยุ่นน้อยลง : Sprocs สามารถใช้ประโยชน์อย่างเต็มที่จากคุณสมบัติของฐานข้อมูล LINQ มีแนวโน้มที่จะเป็นเรื่องธรรมดามากขึ้นในการสนับสนุน สิ่งนี้เป็นเรื่องปกติในสิ่งที่เป็นนามธรรมของภาษา (เช่น C # กับแอสเซมเบลอร์)
3. recompiling : ถ้าคุณต้องการที่จะเปลี่ยนแปลงวิธีที่คุณทำการเข้าถึงข้อมูลที่คุณจำเป็นต้องคอมไพล์, รุ่นและโยกย้ายกำลังการชุมนุมของคุณ sprocs สามารถบางครั้งช่วยให้ DBA การปรับแต่งขั้นตอนการเข้าถึงข้อมูลโดยไม่จำเป็นต้องโยกย้ายกำลังคนอะไร

ความปลอดภัยและการจัดการเป็นสิ่งที่ผู้คนทะเลาะกัน

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

ฉันเคยเป็นผู้ชาย sproc ใหญ่ แต่ฉันเริ่มเอนเอียงไปที่ LINQ เป็นทางเลือกที่ดีกว่าโดยทั่วไป หากมีบางพื้นที่ที่ sprocs ชัดเจนดีกว่าฉันจะยังคงเขียน sproc แต่เข้าถึงโดยใช้ LINQ :)

โดยทั่วไปแล้วฉันเป็นผู้สนับสนุนให้ใส่ทุกอย่างไว้ในกระบวนการจัดเก็บด้วยเหตุผลทั้งหมดที่ DBA ได้รับมานานหลายปี ในกรณีของ Linq มันเป็นความจริงที่ว่าจะไม่มีความแตกต่างด้านประสิทธิภาพกับการสืบค้น CRUD แบบง่าย ๆ

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

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

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

บางทีวิธี hybird น่าจะดีกับ Linq? แน่นอน Linq สามารถใช้เรียกขั้นตอนการจัดเก็บได้

Linq ถึง Sql

เซิร์ฟเวอร์ Sql จะแคชแผนแบบสอบถามดังนั้นจึงไม่มีประสิทธิภาพที่เพิ่มขึ้นสำหรับ sprocs

ในทางกลับกันข้อความสั่ง linq ของคุณจะเป็นส่วนหนึ่งของเหตุผลและทดสอบกับแอปพลิเคชันของคุณ Sprocs นั้นแยกออกจากกันเล็กน้อยและยากต่อการบำรุงรักษาและทดสอบ

หากฉันกำลังทำงานกับแอปพลิเคชันใหม่ตั้งแต่เริ่มต้นตอนนี้ฉันจะใช้ Linq โดยไม่มีสครูก

สำหรับการดึงข้อมูลพื้นฐานฉันจะไปหา Linq โดยไม่ลังเล

ตั้งแต่ย้ายมาที่ Linq ฉันพบข้อดีดังต่อไปนี้:

1. การดีบัก DAL ของฉันง่ายกว่าที่เคย
2. รวบรวมความปลอดภัยของเวลาเมื่อสคีมาของคุณเปลี่ยนแปลงนั้นไม่มีค่า
3. การปรับใช้ง่ายขึ้นเพราะทุกอย่างถูกรวบรวมไว้ใน DLL ไม่มีการจัดการสคริปต์การปรับใช้อีกต่อไป
4. เนื่องจาก Linq สามารถรองรับการสืบค้นข้อมูลใด ๆ ที่ใช้งานอินเทอร์เฟซ IQueryable คุณจะสามารถใช้ไวยากรณ์เดียวกันเพื่อสืบค้น XML วัตถุและแหล่งข้อมูลอื่น ๆ โดยไม่ต้องเรียนรู้ไวยากรณ์ใหม่

LINQ จะขยายแคชโพรซีเดอร์

หากแอปพลิเคชันใช้ LINQ กับ SQL และการสืบค้นเกี่ยวข้องกับการใช้สตริงที่สามารถเปลี่ยนแปลงความยาวได้สูงแคชโพรซีเดอร์ SQL Server จะกลายเป็น bloated พร้อมกับเคียวรีเวอร์ชันเดียวสำหรับทุกความยาวสตริงที่เป็นไปได้ ตัวอย่างเช่นพิจารณาแบบสอบถามแบบง่าย ๆ ต่อไปนี้ที่สร้างขึ้นจากตาราง Person.AddressTypes ในฐานข้อมูล AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

หากมีการเรียกใช้แบบสอบถามทั้งสองนี้เราจะเห็นรายการสองรายการในแคชโพรซีเดอร์ SQL Server: รายการที่ถูกผูกไว้กับ NVARCHAR (7) และรายการอื่นที่มี NVARCHAR (11) ตอนนี้ลองคิดดูว่ามีอินพุตสตริงที่แตกต่างกันหลายร้อยหรือหลายพันทั้งหมดมีความยาวต่างกัน โพรซีเดอร์แคชจะเต็มไปด้วยแผนที่แตกต่างกันโดยไม่จำเป็นสำหรับแบบสอบถามเดียวกันทุกประเภท

เพิ่มเติมได้ที่นี่: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

ฉันคิดว่าอาร์กิวเมนต์ LINQ pro น่าจะมาจากคนที่ไม่มีประวัติกับการพัฒนาฐานข้อมูล (โดยทั่วไป)

โดยเฉพาะอย่างยิ่งหากใช้ผลิตภัณฑ์เช่น VS DB Pro หรือ Team Suite ข้อโต้แย้งมากมายที่เกิดขึ้นที่นี่จะไม่มีผลบังคับใช้ตัวอย่างเช่น:

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

LINQ ทำให้การทดสอบหน่วยจริงเป็นไปไม่ได้เพราะ (ในใจของฉัน) มันล้มเหลวในการทดสอบกรด

การดีบักง่ายขึ้นใน LINQ: เพราะอะไร VS อนุญาตให้เต็มขั้นตอนจากรหัสที่ได้รับการจัดการและการดีบัก SP แบบปกติ

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

ไม่ต้องเรียนรู้ TSQL ด้วย LINQ: ไม่คุณไม่ได้ แต่คุณต้องเรียนรู้ LINQ - คุณจะได้รับประโยชน์ที่ไหน?

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

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

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

แก้ไข: LINQ ไปยัง SQL ขั้นตอนการจัดเก็บด้านของสิ่งต่าง ๆ เป็นสิ่งที่ฉันยังคงต้องอ่านเพิ่มเติม - ขึ้นอยู่กับสิ่งที่ฉันพบฉันอาจเปลี่ยน diatribe ข้างต้นของฉัน;)

LINQ เป็นของใหม่และมีสถานที่ LINQ ไม่ได้คิดค้นเพื่อแทนที่กระบวนงานที่เก็บไว้

ที่นี่ฉันจะมุ่งเน้นไปที่บางตำนานประสิทธิภาพ & CONS เพียงสำหรับ "LINQ กับ SQL" แน่นอนฉันอาจผิดทั้งหมด ;-)

(1) ผู้คนบอกว่าสถานะของ LINQ สามารถ "แคช" ในเซิร์ฟเวอร์ SQL ดังนั้นจึงไม่สูญเสียประสิทธิภาพ จริงบางส่วน "LINQ ไปยัง SQL" จริง ๆ แล้วเป็นรันไทม์การแปลไวยากรณ์ LINQ เป็น TSQL statment ดังนั้นจากมุมมองด้านประสิทธิภาพคำสั่ง ADO.NET SQL แบบฮาร์ดโค้ดไม่มีความแตกต่างจาก LINQ

(2) ยกตัวอย่าง UI บริการลูกค้ามีฟังก์ชัน "การโอนบัญชี" ฟังก์ชั่นนี้อาจอัพเดทตาราง 10 DB และส่งคืนข้อความในนัดเดียว ด้วย LINQ คุณจะต้องสร้างชุดคำสั่งและส่งเป็นชุดเดียวไปยังเซิร์ฟเวอร์ SQL ประสิทธิภาพของชุดการแปล LINQ-> TSQL นี้แทบจะไม่ตรงกับขั้นตอนการจัดเก็บ เหตุผล? เนื่องจากคุณสามารถปรับแต่งหน่วยที่เล็กที่สุดของคำสั่งในโพรซีเดอร์ Stored โดยใช้เครื่องมือสร้างโปรไฟล์ SQL และเครื่องมือแผนปฏิบัติการในตัวคุณจึงไม่สามารถทำได้ใน LINQ

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

(3) "LINQ to SQL" ทำให้ newbies สามารถแนะนำ hogs ประสิทธิภาพได้อย่างง่ายดาย ผู้อาวุโส TSQL ทุกคนสามารถบอกคุณได้ว่าจะไม่ใช้ CURSOR เมื่อใด (โดยทั่วไปคุณไม่ควรใช้ CURSOR ใน TSQL ในกรณีส่วนใหญ่) ด้วย LINQ และวง "foreach" ที่มีเสน่ห์ด้วยข้อความค้นหามันเป็นเรื่องง่ายมากสำหรับมือใหม่ที่จะเขียนโค้ดดังกล่าว:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

คุณสามารถเห็นรหัสที่ดีง่าย ๆ นี้น่าสนใจมาก แต่ภายใต้ประทุน. NET runtime เพียงแปลสิ่งนี้เป็นชุดการปรับปรุง หากมีเพียง 500 บรรทัดนี่เป็นชุด 500 บรรทัด TSQL หากมีล้านเส้นนี่เป็นเพลงฮิต แน่นอนว่าผู้ใช้ที่มีประสบการณ์จะไม่ใช้วิธีนี้ในการทำงานนี้ แต่ประเด็นคือมันง่ายที่จะตกหล่นในลักษณะนี้

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

LINQ มีสถานที่ในฐานข้อมูลเฉพาะแอปพลิเคชันและในธุรกิจขนาดเล็ก

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

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

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

IMHO, RAD = LINQ, RUP = Procs ที่เก็บไว้ ฉันทำงานให้กับ บริษัท ฟอร์จูน 500 ขนาดใหญ่เป็นเวลาหลายปีในหลายระดับรวมถึงการจัดการและตรงไปตรงมาฉันจะไม่จ้างนักพัฒนา RUP เพื่อพัฒนา RAD พวกเขาเงียบมากจนไม่รู้ว่าจะต้องทำอะไรในระดับอื่นของกระบวนการ ด้วยสภาพแวดล้อมที่เงียบทำให้รู้สึกได้ว่าให้ DBA ควบคุมข้อมูลผ่านจุดเข้าใช้งานที่เฉพาะเจาะจงเพราะผู้อื่นไม่ทราบวิธีที่ดีที่สุดในการจัดการข้อมูลให้สำเร็จ

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

บางครั้งฉันคิดว่า DBA นั้นมีอคติกับ LINQ เพราะพวกเขารู้สึกว่ามันคุกคามความมั่นคงในงานของพวกเขา แต่นั่นคือธรรมชาติของสัตว์ร้ายสุภาพสตรีและสุภาพบุรุษ

ฉันคิดว่าคุณต้องไปกับ procs สำหรับอะไรจริง

A) การเขียนลอจิกทั้งหมดของคุณใน linq หมายความว่าฐานข้อมูลของคุณมีประโยชน์น้อยกว่าเพราะมีเพียงแอปพลิเคชันของคุณเท่านั้นที่สามารถใช้งานได้

B) ฉันไม่เชื่อว่าการสร้างแบบจำลองวัตถุดีกว่าการสร้างแบบจำลองเชิงสัมพันธ์อยู่ดี

C) การทดสอบและพัฒนากระบวนงานที่เก็บไว้ใน SQL เป็นนรกเร็วกว่ารอบการแก้ไขที่รวบรวมในสภาพแวดล้อม Visual Studio ใด ๆ คุณเพิ่งแก้ไข F5 และกดเลือกและคุณจะออกไปแข่ง

D) ง่ายต่อการจัดการและปรับใช้ขั้นตอนการจัดเก็บกว่าชุดประกอบ .. คุณเพียงแค่วางไฟล์บนเซิร์ฟเวอร์และกด F5 ...

E) Linq ถึง sql ยังคงเขียนโค้ดเส็งเคร็งในบางครั้งเมื่อคุณไม่คาดหวัง

สุจริตฉันคิดว่าสิ่งที่ดีที่สุดสำหรับ MS คือการเพิ่ม t-sql เพื่อให้สามารถฉายภาพแบบเข้าร่วมโดยนัยในแบบที่ linq ทำ t-sql ควรรู้ว่าคุณต้องการสั่ง order.lineitems.part หรือไม่

LINQ ไม่ได้ห้ามการใช้โพรซีเดอร์ที่เก็บไว้ ผมเคยใช้โหมดผสมกับ LINQ-SQL และLINQ-StoredProc โดยส่วนตัวฉันดีใจที่ฉันไม่ต้องเขียน procs ที่เก็บไว้ .... pwet-tu

นอกจากนี้ยังมีปัญหาการย้อนกลับ 2.0 ที่เป็นไปได้ เชื่อใจฉันมันเกิดขึ้นกับฉันสองสามครั้งดังนั้นฉันมั่นใจว่ามันเกิดขึ้นกับคนอื่น ๆ

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

ฉันสมมติว่าคุณหมายถึง Linq ถึง Sql

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

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

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

โดยสรุปการเลือกระหว่างรถจักรยานยนต์หรือรถยนต์นั้นขึ้นอยู่กับเส้นทางของคุณ (ธุรกิจ) ความยาว (เวลา) และผู้โดยสาร (ข้อมูล)

หวังว่ามันจะช่วยฉันอาจผิด : D

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

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

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

แม้ว่าเราพบว่าดีหวานน่าสนใจ ฯลฯ ในขณะที่ทำงานกับ LINQ แต่ก็มีข้อเสียในการทำให้ผู้พัฒนาขี้เกียจ :) และได้รับการพิสูจน์ 1,000 ครั้งว่าเป็นผลงานที่แย่ (อาจแย่ที่สุด) เมื่อเปรียบเทียบกับ Procs ที่เก็บไว้

หยุดขี้เกียจ ฉันพยายามอย่างหนัก :)

สำหรับการดำเนินงาน CRUD อย่างง่าย ๆ ด้วยจุดเชื่อมต่อข้อมูลเดียวฉันจะบอกว่าไปหา LINQ ถ้าคุณรู้สึกสบายใจกับไวยากรณ์ สำหรับตรรกะที่ซับซ้อนกว่านี้ฉันคิดว่า sprocs นั้นมีประสิทธิภาพที่ดีกว่าถ้าคุณเก่งใน T-SQL และมีการดำเนินการขั้นสูงกว่า นอกจากนี้คุณยังได้รับความช่วยเหลือจากจูนที่ปรึกษา, ผู้สร้างโปรไฟล์เซิร์ฟเวอร์ SQL, การดีบักการสอบถามของคุณจาก SSMS เป็นต้น

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

ผลการวิจัยสรุปได้ดังนี้

LinqToSql สำหรับไซต์ขนาดเล็กและต้นแบบ ช่วยประหยัดเวลาในการทำต้นแบบ

Sps: Universal ฉันสามารถปรับแต่งคำถามของฉันและตรวจสอบ ActualExecutionPlan / EstimatedExecutionPlan ได้ตลอดเวลา

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

ทั้ง LINQ และ SQL มีตำแหน่งของมัน ทั้งสองมีข้อเสียและข้อดี

บางครั้งสำหรับการดึงข้อมูลที่ซับซ้อนคุณอาจต้องใช้โปรแกรมจัดเก็บ และบางครั้งคุณอาจต้องการให้คนอื่นใช้ proc ที่เก็บไว้ใน Sql Server Management Studio

Linq to Entities ยอดเยี่ยมสำหรับการพัฒนา CRUD ที่รวดเร็ว

แน่นอนว่าคุณสามารถสร้างแอปได้ด้วยแอพเดียวเท่านั้น หรือคุณสามารถผสมมันขึ้นมา ทุกอย่างมาตามความต้องการของคุณ แต่ procs ที่เก็บไว้ของ SQL จะไม่หายไปในเร็ว ๆ นี้