1. ตัวเลือก SqlDataRead และ Dataset ข้อดีของ Sqldataread: การอ่านข้อมูลทำได้รวดเร็วมาก หากข้อมูลที่ส่งคืนไม่ต้องการการประมวลผลจำนวนมาก ขอแนะนำให้ใช้ SqlDataReader ซึ่งมีประสิทธิภาพดีกว่าชุดข้อมูลมาก ข้อเสีย: ไม่สามารถปิดการเชื่อมต่อกับฐานข้อมูลได้จนกว่าจะอ่านข้อมูล
(SqlDataReader อ่านข้อมูลในทิศทางกรอไปข้างหน้า คลาส SqlDataReader จัดเตรียมวิธีการอ่านสตรีมข้อมูลแบบส่งต่อเท่านั้นที่ดึงมาจากฐานข้อมูล SQL Server โดยจะใช้ของ SQL Server รูปแบบการส่งข้อมูลเครือข่ายดั้งเดิมจะอ่านข้อมูลโดยตรงจากการเชื่อมต่อฐานข้อมูล DataReader จะต้องปิดอย่างชัดเจนทันเวลาจึงจะปล่อยการเชื่อมต่อข้อมูลได้ทันเวลา)
ชุดข้อมูลจะอ่านข้อมูลและแคชไว้ในหน่วยความจำ ข้อเสีย: การใช้หน่วยความจำสูง หากคุณต้องการประมวลผลข้อมูลที่ส่งคืนเป็นจำนวนมาก ควรใช้ Dataset เพื่อลดการดำเนินการเชื่อมต่อกับฐานข้อมูล ข้อดี: คุณจะต้องเชื่อมต่อเพียงครั้งเดียวเพื่อปิดการเชื่อมต่อกับฐานข้อมูล
โดยทั่วไป หากคุณต้องการอ่านข้อมูลจำนวนมากและไม่ประมวลผลข้อมูลที่ส่งคืนมากนัก ให้ใช้ SqlDataReader สำหรับข้อมูลจำนวนมาก การประมวลผลข้อมูลที่ส่งคืนจะเหมาะสมกว่าที่จะใช้ชุดข้อมูล ทางเลือกของ SqlDataReader และชุดข้อมูลขึ้นอยู่กับการใช้งานฟังก์ชันของโปรแกรม
2. ExecuteNonQuery และ ExecuteScalar
ไม่จำเป็นต้องส่งคืนชุดผลลัพธ์เมื่ออัปเดตข้อมูล ขอแนะนำให้ใช้ ExecuteNonQuery เนื่องจากไม่มีการส่งคืนชุดผลลัพธ์ จึงสามารถละเว้นการส่งข้อมูลเครือข่ายได้ เพียงแต่ส่งคืนจำนวนแถวที่ได้รับผลกระทบ หากคุณต้องการอัปเดตข้อมูลเท่านั้น ค่าใช้จ่ายด้านประสิทธิภาพของ ExecuteNonQuery นั้นค่อนข้างน้อย
ExecuteScalar ส่งคืนเฉพาะคอลัมน์แรกของแถวแรกในชุดผลลัพธ์ ใช้เมธอด ExecuteScalar เพื่อดึงค่าเดียว (เช่น หมายเลข ID) จากฐานข้อมูล การดำเนินการนี้ต้องใช้รหัสน้อยกว่าการใช้วิธี ExecuteReader เพื่อดำเนินการที่จำเป็นในการสร้างค่าเดียวในข้อมูลที่ส่งคืน
*เพียงอัปเดตข้อมูลโดยใช้ ExecuteNonQuery การสืบค้นค่าเดียวจะใช้ตัวเลือกการผูกข้อมูล ExecuteScalar
3 การผูกข้อมูล DataBinder
วิธีการผูกทั่วไป <%# DataBinder.Eval(Container.DataItem, "field name") %> ใช้ DataBinder.eval การผูก ไม่สนใจแหล่งข้อมูล (Dataread หรือชุดข้อมูล) คุณไม่ต้องกังวลเกี่ยวกับประเภทของข้อมูล eval จะแปลงออบเจ็กต์ข้อมูลนี้เป็นสตริง มีงานจำนวนมากในการเย็บขอบด้านล่าง โดยใช้ความสามารถในการสะท้อนกลับ เพียงเพราะมันสะดวกในการใช้งานก็ส่งผลต่อประสิทธิภาพของข้อมูล มาดูที่ <%# DataBinder.Eval(Container.DataItem, "field name") %> เมื่อผูกเข้ากับชุดข้อมูล DataItem จะเป็น DataRowView จริงๆ (หากผูกไว้กับตัวอ่านข้อมูล (dataread) จะเป็น IdataRecord) ดังนั้น การแปลงเป็น DataRowView โดยตรงจะช่วยปรับปรุงประสิทธิภาพได้อย่างมาก
<%# ctype(Container.DataItem,DataRowView).Row("field name") %>
*ขอแนะนำให้ใช้ <%# ctype(Container.DataItem,DataRowView).Row("field name") %> สำหรับข้อมูล มีผลผูกพัน เมื่อข้อมูลมีปริมาณมาก ความเร็วก็จะเพิ่มขึ้นได้หลายร้อยเท่า ให้ความสนใจกับสองประเด็นเมื่อใช้งาน: 1. คุณต้องเพิ่ม <%@ Import namespace="System.Data"%> ลงในเพจ 2. ให้ความสนใจกับตัวพิมพ์ของชื่อฟิลด์ (ให้ความสนใจเป็นพิเศษ) หากไม่สอดคล้องกับแบบสอบถาม ในบางกรณีจะช้ากว่า <%# DataBinder.Eval(Container.DataItem, "field name") %> หากคุณต้องการปรับปรุงความเร็วเพิ่มเติม คุณสามารถใช้เมธอด <%# ctype(Container.DataItem,DataRowView).Row(0) %> อย่างไรก็ตามความสามารถในการอ่านไม่สูงนัก
ข้างต้นคือวิธีการเขียนของ vb.net ใน c#: <@% ((DataRowView)Container.DataItem)["field name"] %>
วิธีที่ง่ายที่สุดในการดูสถานะของกระบวนการดำเนินการแต่ละกระบวนการบนเพจ: คุณสามารถดูรายละเอียดได้หากแอตทริบิวต์การติดตามของเพจคือ จริง.
1. ใช้ขั้นตอนการจัดเก็บ:
1. ประสิทธิภาพ: ขั้นตอนการจัดเก็บมีคุณสมบัติขั้นสูงมากมายที่ไม่พบในภาษา SQL มาตรฐาน ความสามารถในการส่งผ่านพารามิเตอร์และดำเนินการนิพจน์เชิงตรรกะช่วยให้นักออกแบบแอปพลิเคชันจัดการงานที่ซับซ้อนได้ นอกจากนี้ กระบวนการที่เก็บไว้จะถูกจัดเก็บไว้ในเซิร์ฟเวอร์ภายในเครื่อง ช่วยลดแบนด์วิดท์การรับส่งข้อมูลเครือข่ายและเวลาดำเนินการที่จำเป็นในการดำเนินการตามขั้นตอน (ขั้นตอนที่เก็บไว้ได้คอมไพล์คำสั่ง sql ไว้ล่วงหน้า ดังนั้นความเร็วในการดำเนินการจึงเร็วกว่าการดำเนินการคำสั่ง sql ในโปรแกรมมาก)
2. โครงสร้างโปรแกรม: จากมุมมองของความสามารถในการปรับขนาดของโปรแกรม การใช้ขั้นตอนที่เก็บไว้จะส่งผลต่อการแก้ไขโปรแกรมในอนาคต เพื่อความสะดวก ตัวอย่างเช่น หากโครงสร้างของฐานข้อมูลเปลี่ยนแปลง คุณเพียงแค่ต้องแก้ไขโครงสร้างหน่วยเก็บข้อมูลที่เกี่ยวข้องและส่วนที่เรียกใช้ของโปรแกรมเท่านั้น ส่วนนี้ไม่อยู่ในขอบเขตของบทความนี้และเป็นของการออกแบบโครงสร้างของโปรแกรม ดังนั้นฉันจะไม่ขยายความที่นี่
3. ความปลอดภัยของโปรแกรม: สามารถหลีกเลี่ยงการโจมตี SQL Injection ได้โดยใช้ขั้นตอนการจัดเก็บ
2. การเพิ่มประสิทธิภาพคำสั่งสืบค้น (สำหรับ sql server2000)
หลายๆ คนเขียนคำสั่ง sql เพื่อจุดประสงค์เท่านั้น โดยไม่คำนึงถึงประสิทธิภาพในการดำเนินการของคำสั่ง sql ที่นี่ฉันเพียงให้วิธีการเพิ่มประสิทธิภาพลำดับของตารางเท่านั้น (การเพิ่มประสิทธิภาพและหลักการของคำสั่ง SQL จะกล่าวถึงในบันทึกการศึกษา SQL Server2000 ของฉัน)
เพื่อประสิทธิภาพในการดำเนินการของคำสั่ง SQL คุณสามารถใช้ตัววิเคราะห์แบบสอบถามของ SQL Server2000 เพื่อ ดูกระบวนการดำเนินการของคำสั่ง
ปรับลำดับตารางให้เหมาะสม: ภายใต้สถานการณ์ปกติ sqlserver จะปรับการเชื่อมต่อตารางให้เหมาะสมโดยอัตโนมัติ ตัวอย่างเช่น เลือก name,no จาก A เข้าร่วม B บน A. id=B.id เข้าร่วม C บน C.id=A.id โดยที่ name='wang'แม้ว่า
ตาราง A จะแสดงเป็นอันดับแรกใน From จากนั้น B และสุดท้าย มันเป็นซี แต่เซิร์ฟเวอร์ sql อาจใช้ตาราง c ก่อน หลักการเลือกคือการจำกัดการสืบค้นให้เหลือเพียงแถวเดียวหรือสองสามแถว เพื่อลดจำนวนข้อมูลทั้งหมดที่ค้นหาในตารางอื่นจะลดลง ในกรณีส่วนใหญ่ SQL Server จะเลือกตัวเลือกที่เหมาะสมที่สุด แต่ถ้าคุณพบว่าแบบสอบถามการรวมที่ซับซ้อนช้ากว่าที่คาดไว้ คุณสามารถใช้คำสั่ง SET FORCEPLAN เพื่อบังคับให้ SQL Server ใช้ตารางตามลำดับที่ปรากฏได้ ดังตัวอย่างข้างต้น ให้เพิ่ม: SET FORCEPLAN ON.......SET FORCEPLAN OFF ดูประสิทธิภาพการดำเนินการ 2 รายการใน Query Analyzer เพื่อเลือกลำดับที่จะรวมตาราง
*ใช้ SET FORCEPLAN เพื่อเลือกลำดับการเชื่อมต่อตาราง
3. การเพิ่มประสิทธิภาพเพจ (.aspx)
เน้นไปที่คุณลักษณะต่างๆ ของเพจเป็นหลัก
1. EnableViewState (สถานะมุมมองของเพจ) ตั้งค่าเป็นเท็จหากไม่มีข้อกำหนดพิเศษ ด้วย ViewState แต่ละออบเจ็กต์จะต้องถูกทำให้เป็นอนุกรมใน ViewState ก่อน จากนั้นจึงทำการดีซีเรียลไลซ์ผ่าน postback ดังนั้นจึงไม่มีค่าใช้จ่ายในการใช้ ViewState ใช้วัตถุให้น้อยที่สุดเท่าที่จะทำได้ และหากเป็นไปได้ ให้ลดจำนวนวัตถุที่คุณใส่ใน ViewState โดยพื้นฐานแล้ว Viewstate สามารถปิดใช้งานได้ในสถานการณ์ต่อไปนี้:
(1) การควบคุมหน้า (.ascx)
(2) หน้าจะไม่ถูกส่งกลับไปยังหน้านั้นเอง
(3) ไม่จำเป็นต้องมีการประมวลผลเหตุการณ์สำหรับการควบคุม
(4) การควบคุมไม่มีค่าคุณสมบัติแบบไดนามิกหรือข้อมูลผูก (หรือถูกจัดการในรหัสสำหรับแต่ละ postpack)
ปิดการใช้งาน ViewState สำหรับหน้าเดียวหรือสำหรับแต่ละหน้าดังต่อไปนี้: หน้าเดียว: <%@ Page EnableViewState=" False" %> แต่ละเพจ: ใน web.config <Pages EnableViewState="false" /> EnableSessionState สามารถเก็บค่าเริ่มต้นไว้ได้ (จะใช้ทรัพยากรเฉพาะในกรณีที่เพจใช้ sessionstate) EnableViewStateMac หากไม่มีข้อกำหนดด้านความปลอดภัยพิเศษ ให้คงค่าเริ่มต้นไว้
2. รูปแบบเค้าโครงหน้า ขอแนะนำให้ใช้ Flowlayout (องค์ประกอบจะถูกเพิ่มโดยไม่มีคุณลักษณะการวางตำแหน่งที่แน่นอน) Gridlayout (คุณลักษณะการวางตำแหน่งสัมบูรณ์) จะสร้างโค้ดมากกว่า Flowlayout เนื่องจากการใช้การวางตำแหน่งแบบสัมบูรณ์ ซึ่งส่วนใหญ่เป็นข้อมูลการวางตำแหน่งของตัวควบคุม
3. เมื่อปล่อยโปรเจ็กต์ อย่าลืมปล่อยสถานะ Debug ของเพจด้วย
4. การเพิ่มประสิทธิภาพของภาษา Html คำแนะนำของฉันคือต้องมีความเชี่ยวชาญใน Html/JavaScript และใช้โค้ดที่น้อยลงซึ่งสร้างขึ้นโดยอัตโนมัติโดย vs.net2003 มันจะสร้างโค้ด html ที่ไม่มีประโยชน์ขึ้นมาโดยอัตโนมัติ
5. การตั้งค่าการนำทางอัจฉริยะเป็นจริงสามารถปรับปรุงประสิทธิภาพผู้ใช้ได้อย่างมาก การเปิดใช้งานคุณสมบัตินี้มีผลกระทบเพียงเล็กน้อยต่อไคลเอนต์และเซิร์ฟเวอร์ โดยสามารถอัปเดตส่วนที่จำเป็นต้องอัปเดตได้อย่างชาญฉลาด
4. การเลือกการควบคุม:
ตัวเลือกการควบคุม Html และการควบคุมเซิร์ฟเวอร์ ความสะดวกสบายและการใช้งานที่มาจากการควบคุมเซิร์ฟเวอร์นั้นไม่มีใครเทียบได้กับการควบคุม HTML แต่ได้มาจากค่าใช้จ่ายของทรัพยากรฝั่งเซิร์ฟเวอร์ คำแนะนำส่วนตัวของฉัน: หากการควบคุม html ไม่สามารถบรรลุฟังก์ชันที่ต้องการได้ และไม่สามารถทำได้เมื่อรวมกับภาษาสคริปต์บางภาษา (เช่น javascrpt/vbscript) จากนั้นจึงจะเลือกการควบคุมเซิร์ฟเวอร์ หลังจากเลือกการควบคุมเซิร์ฟเวอร์แล้ว ให้ลองปรับการควบคุมให้เหมาะสม เช่น การยกเลิกสถานะเพจบางส่วน เป็นต้น (ดูการเพิ่มประสิทธิภาพของการควบคุมโดยเฉพาะ)
การเลือกตัวควบคุมเซิร์ฟเวอร์: อธิบายการควบคุมข้อมูลทั่วไปหลายประการเป็นหลัก:
DataGrid: มาพร้อมกับตัวควบคุมที่ทรงพลังที่สุด การแสดงข้อมูล ตัวควบคุมมีฟังก์ชันการใช้งานจริงมากมายในตัว เช่น การแก้ไข การลบ การเพิ่ม และการแบ่งเพจข้อมูล หากคุณต้องการแสดงข้อมูลเท่านั้นอย่าพยายามเลือก DataGrid (จะเก็บข้อมูลทั้งหมดไว้ใน viewstate) อย่าใช้ฟังก์ชันเพจจิ้งในตัว Microsoft ได้ทำงานมากมายในชั้นล่างสุดของเพจจิ้งอัตโนมัติ สะดวกต่อการใช้งาน โอเวอร์เฮดด้านประสิทธิภาพมีมาก
DataList: มีฟังก์ชันน้อยกว่า DataGrid มาก แต่ปรับแต่งได้มากกว่ามาก การแสดงข้อมูลหลายบรรทัดอันเป็นเอกลักษณ์ทำให้เรามีความสะดวกสบายอย่างมาก โดยพื้นฐานแล้วมันสามารถนำฟังก์ชันที่ DataGrid สามารถทำได้มาใช้ ดังนั้นจึงแนะนำให้ใช้
Repeater: ใช้งานได้น้อยที่สุด แต่ปรับแต่งได้มาก ขอแนะนำให้ใช้หากคุณต้องการแสดงข้อมูลเท่านั้น เนื่องจากการลดฟังก์ชันหลายอย่างลง ประสิทธิภาพของเซิร์ฟเวอร์จึงมีน้อย ดังนั้นหากต้องการแสดงข้อมูล โดยพื้นฐานแล้วฉันจะเลือก Repeater จากนั้น DataList และสุดท้าย DataGrid
* พยายามเลือกตัวควบคุม html ฟังก์ชั่นที่สามารถนำมาใช้บนไคลเอนต์นั้นจะถูกนำไปใช้บนไคลเอนต์ (มีความเชี่ยวชาญในจาวาสคริปต์) ซึ่งช่วยลดแรงกดดันต่อเซิร์ฟเวอร์ ลำดับการเลือกการควบคุมข้อมูล: Repeater, DataList, DataGrid
5. การเพิ่มประสิทธิภาพการควบคุมเซิร์ฟเวอร์:
1.
สถานะวิวของการควบคุม Viewstate นั้นโดยพื้นฐานแล้วจะเหมือนกับสถานะของวิวของเพจ ใช้เพื่อบันทึกบางสถานะของการควบคุม หลักการประมวลผลเหมือนกับการประมวลผลสถานะการดูของเพจ หากคุณสนใจ คุณสามารถใช้ Datagrid เพื่อผูกข้อมูลเพื่อทดสอบจำนวนข้อมูลที่บันทึกไว้โดย viewstate โดยพื้นฐานแล้วข้อมูลที่บันทึกไว้จะเหมือนกับจำนวนข้อมูลที่แสดงโดย Datagrid
2.
ค่าเริ่มต้นของ Ispostpack เป็นเท็จ จะต้องตั้งค่าเป็นจริงเมื่อจำเป็นต้องสร้างเหตุการณ์
การเพิ่มประสิทธิภาพของตัวควบคุมส่วนใหญ่ขึ้นอยู่กับความคุ้นเคยของคุณกับการควบคุมนี้ ยิ่งคุณเข้าใจการทำงานภายในของตัวควบคุมมากเท่าไร คุณก็ยิ่งสามารถปรับให้เหมาะสมได้อย่างเหมาะสมมากขึ้นเท่านั้น
การเพิ่มประสิทธิภาพประสิทธิภาพไม่สามารถอธิบายได้เพียงไม่กี่ประโยค สิ่งที่ฉันเขียนเป็นเพียงส่วนเล็ก ๆ เท่านั้น การเพิ่มประสิทธิภาพประสิทธิภาพขึ้นอยู่กับการสั่งสมประสบการณ์ในแต่ละวันและความเข้าใจอย่างต่อเนื่องในหลักการทำงานของโปรแกรม
6. ปัญหาข้อยกเว้น
ไม่จำเป็นต้องมีข้อยกเว้นสำหรับปัญหาทั่วไป เช่น ปัญหาที่ไม่มีผู้ใช้อยู่ในฟอรัม รหัสผ่านผู้ใช้ไม่ถูกต้อง เป็นต้น เนื่องจากการสร้างอินสแตนซ์ข้อยกเว้นต้องใช้ทรัพยากรจำนวนมากและต้องกรอกรายละเอียด ข้อมูลข้อยกเว้น (ประเภทข้อยกเว้น ตำแหน่งข้อยกเว้นที่มีการโยนข้อยกเว้น) ฯลฯ แน่นอนว่าไม่ใช่เพื่อหลีกเลี่ยงการใช้ข้อยกเว้น แต่เพื่อจัดการกับข้อยกเว้นที่จำเป็น หลักการสำหรับข้อยกเว้นคือ: อย่าใช้หากทำได้ และอย่าสร้างข้อยกเว้นของคุณเองหากคุณสามารถใช้ข้อยกเว้นที่มีอยู่ในระบบได้