การเพิ่มการดูเอกสารในแอปพลิเคชันธุรกิจไม่ได้หมายความเพียงแค่ใส่ PDF ลงใน iframe เท่านั้น ไฟล์ Office, แบบร่าง CAD, ไฟล์อีเมล, และรูปภาพต้องการความสามารถในการเรนเดอร์ที่แตกต่างกัน ในขณะเดียวกันแอปพลิเคชันยังต้องควบคุมการตรวจสอบสิทธิ์, การจัดเก็บ, การอนุญาต, และการเก็บรักษา
Doconut เป็น SDK ตัวดูเอกสาร .NET ที่ออกแบบมาเพื่อฝังการเรนเดอร์และการโต้ตอบของเอกสารในเว็บแอปพลิเคชัน แทนการนำเสนอสูตรโค้ดแหล่งที่มาที่ไม่ได้รับการตรวจสอบ คู่มือนี้อธิบายการตัดสินใจการรวมที่ทีมของคุณควรทำและระบุส่วนประกอบมาตรฐานของ .NET ที่มักล้อมรอบ SDK
ทำไมตัวดูแบบฝังจึงแตกต่างจากการดาวน์โหลดไฟล์
จุดเชื่อมต่อการดาวน์โหลดจะส่งไฟล์ต้นฉบับและปล่อยให้ประสบการณ์การดูเป็นหน้าที่ของซอฟต์แวร์ภายนอกแอปพลิเคชันของคุณ ตัวดูแบบฝังทำให้ผู้ใช้คงอยู่ภายในผลิตภัณฑ์ของคุณและสามารถให้ตำแหน่งที่สอดคล้องสำหรับการนำทาง, การค้นหา, การตรวจสอบ, และคุณลักษณะอื่น ๆ ที่เปิดใช้งานได้
การสร้างชั้นการเรนเดอร์เองทำได้ยากเพราะแต่ละรูปแบบมีกฎของตนเอง:
- ไฟล์ PDF สามารถมีฟอนต์ฝัง, คำอธิบาย, ฟอร์ม, และชุดหน้าจำนวนมาก
- ไฟล์ Word, Excel, และ PowerPoint ต้องการการจัดวางและการจัดการฟอนต์อย่างระมัดระวัง
- แบบร่าง CAD ต้องการการสเกลที่แม่นยำ, ชั้น, และการซูมละเอียด
- รูปแบบอีเมลและรูปภาพนำเข้าการแนบ, เมตาดาต้า, สี, และความละเอียดเป็นข้อกังวล
SDK เฉพาะช่วยให้ทีมแอปพลิเคชันมุ่งเน้นที่การควบคุมการเข้าถึง, เวิร์กโฟลว์, และประสบการณ์ผู้ใช้ แทนการบำรุงรักษาเรนเดอร์แยกต่างหากสำหรับแต่ละรูปแบบที่รองรับ
ขั้นตอนที่ 1: ยืนยันรูปแบบและคุณลักษณะที่ต้องการ
เริ่มต้นด้วยการสำรวจรายการไฟล์ที่ผู้ใช้ของคุณเปิด แยกรูปแบบที่จำเป็นออกจากรูปแบบที่ใช้เป็นครั้งคราว และบันทึกตัวอย่างที่เป็นตัวแทนสำหรับการทดสอบ
รายการตรวจสอบของคุณอาจรวมถึง:
- เอกสาร PDF และ XPS
- เอกสารประมวลผลคำ
- ตารางข้อมูล
- งานนำเสนอ
- แบบร่าง CAD
- ไฟล์อีเมล
- รูปแบบรูปภาพทั่วไป
จากนั้นระบุคุณลักษณะที่สำคัญสำหรับแต่ละเวิร์กโฟลว์ การดู, การค้นหาข้อความ, คำอธิบาย, การพิมพ์, และการแปลงเป็นความสามารถที่แตกต่างและอาจต้องการส่วนประกอบหรือใบอนุญาตของ Doconut ที่แตกต่างกัน
ตรวจสอบขอบเขตผลิตภัณฑ์ปัจจุบันบนหน้า Doconut Viewer page ที่ได้รับการยืนยันก่อนตัดสินใจเลือกรูปแบบหรือคุณลักษณะ ความสามารถของผลิตภัณฑ์อาจเปลี่ยนแปลงได้ ดังนั้นการทดสอบการยอมรับของคุณควรเป็นอำนาจสุดท้ายสำหรับเอกสารที่ลูกค้าจริง ๆ ใช้งาน
ขั้นตอนที่ 2: เลือกแหล่งที่เอกสารเข้าสู่แอปพลิเคชัน
แอปพลิเคชัน ASP.NET สามารถรับเอกสารจากหลายแหล่งที่ควบคุมได้:
- การอัปโหลดที่จัดการเป็น
IFormFileของ ASP.NET Core - ตำแหน่งไฟล์ที่ได้รับการปกป้อง
- ฐานข้อมูลหรือคลังจัดการเอกสาร
- ที่เก็บวัตถุที่เซิร์ฟเวอร์เข้าถึงได้
- บริการภายในที่ส่งคืน
Stream
เวิร์กโฟลว์การดูควรใช้การอ้างอิงเอกสารที่ได้รับการอนุญาตจากเซิร์ฟเวอร์ อย่าใส่ข้อมูลรับรองการจัดเก็บ, เส้นทางไฟล์ที่ไม่มีข้อจำกัด, หรือ URL สาธารณะถาวรในมาร์กอัปฝั่งคลไอเอนท์
หากผู้ใช้อัปโหลดไฟล์ ตรวจสอบความถูกต้องก่อนการเรนเดอร์ ตรวจสอบขนาดไฟล์, ส่วนขยาย, ลายเซ็นไฟล์, และข้อจำกัดเฉพาะธุรกิจ เก็บตัวระบุที่สร้างโดยเซิร์ฟเวอร์แทนการเชื่อถือชื่อไฟล์ต้นฉบับเป็นเส้นทาง
ขั้นตอนที่ 3: กำหนดการตรวจสอบสิทธิ์และการอนุญาต
แอปพลิเคชัน—not ตัวดู UI—ควรตัดสินใจว่าใครได้รับอนุญาตให้เปิดเอกสาร
ใน ASP.NET Core กลไกมาตรฐานเช่น middleware การตรวจสอบสิทธิ์, แอตทริบิวต์ [Authorize], นโยบาย, คลาม, และการอนุญาตแบบอิงทรัพยากรสามารถปกป้องจุดเชื่อมต่อที่เริ่มเซสชันการดู การตัดสินใจการอนุญาตควรรวมทั้งผู้ใช้ปัจจุบันและเอกสารที่ร้องขอ
กระบวนการร้องขอที่ปลอดภัยมีลักษณะดังนี้:
- ผู้ใช้ร้องขอเอกสารโดยใช้ตัวระบุระดับแอปพลิเคชัน
- เซิร์ฟเวอร์ตรวจสอบสิทธิ์ของผู้ใช้
- เซิร์ฟเวอร์ตรวจสอบว่าผู้ใช้สามารถเข้าถึงเอกสารนั้นได้หรือไม่
- เซิร์ฟเวอร์ระบุตำแหน่งการจัดเก็บที่ได้รับการปกป้อง
- ตัวดูรับข้อมูลที่จำเป็นสำหรับเซสชันที่ได้รับการอนุญาตเท่านั้น
ห้ามสมมติว่าการซ่อนปุ่มบนแถบเครื่องมือเป็นการควบคุมการอนุญาต การตรวจสอบการเข้าถึงฝั่งเซิร์ฟเวอร์ยังคงจำเป็นแม้ปุ่มดาวน์โหลดหรือพิมพ์จะไม่แสดงก็ตาม
ขั้นตอนที่ 4: เพิ่ม Doconut ผ่านแหล่งทรัพยากรการรวมอย่างเป็นทางการ
ใช้แพคเกจและคำแนะนำการตั้งค่าปัจจุบันที่จัดหาโดย Doconut หน้า Doconut download page ที่ได้รับการยืนยันให้เข้าถึงทรัพยากรการรวม NuGet, เอกสาร, ตัวอย่าง, และสาธิต
การตั้งค่าที่แม่นยำอาจขึ้นอยู่กับ:
- ประเภทแอปพลิเคชัน ASP.NET หรือ .NET ของคุณ
- ผลิตภัณฑ์และปลั๊กอิน Doconut ที่เลือก
- เวอร์ชันของ Doconut
- ใบอนุญาตของคุณ
- รูปแบบเอกสารและคุณลักษณะที่คุณเปิดใช้งาน
- การกำหนดค่าของเซิร์ฟเวอร์ Windows ของคุณ
ปฏิบัติตามเอกสารที่ตรงกับรุ่นที่ติดตั้ง หลีกเลี่ยงการคัดลอกโค้ดการเริ่มต้นจากบล็อกโพสต์ที่ไม่เกี่ยวข้อง เพราะเนมสเปซ, การกำหนดค่า, เส้นทางทรัพยากร, และ API อาจเปลี่ยนแปลงระหว่างเวอร์ชัน
ขั้นตอนที่ 5: สร้างขอบเขตการดูเอกสารเฉพาะ
ให้การดูเอกสารอยู่หลังบริการแอปพลิเคชันขนาดเล็กแทนการเรียกฟังก์ชัน SDK ตลอดคอนโทรลเลอร์และคอมโพเนนต์ UI
บริการนั้นอาจรับผิดชอบต่อ:
- การระบุตัวเอกสารที่ได้รับการอนุญาต
- การเปิดเอกสารเป็น
Streamที่ควบคุมเมื่อเหมาะสม - การจัดหาการกำหนดค่าการดูที่จำเป็น
- การปล่อยทรัพยากรไฟล์และสตรีม
- การแปลความล้มเหลวทางเทคนิคเป็นข้อผิดพลาดแอปพลิเคชันที่ปลอดภัย
- การบันทึกเมตริกการทำงานโดยไม่บันทึกเนื้อหาเอกสาร
ขอบเขตนี้ทำให้การอัปเกรดง่ายขึ้นและลดความเสี่ยงของการเปิดเผยรายละเอียดการจัดเก็บต่อชั้นการนำเสนอ อีกทั้งยังให้การทดสอบมีจุดที่ชัดเจนสำหรับการแทนที่ด้วยการทำงานที่ปลอดภัย
ขั้นตอนที่ 6: ออกแบบหน้าตัวดู
ตัวดูควรมีพื้นที่เพียงพอเพื่อให้ใช้งานได้ดี การ์ดแคบที่ล้อมรอบด้วยคอนโทรลที่ไม่เกี่ยวข้องทำให้สเปรดชีตขนาดใหญ่และแบบร่าง CAD ยากต่อการตรวจสอบ
วางแผนหน้าตาม:
- ความสูงของตัวดูที่คงที่
- สถานะการโหลด, ว่าง, และข้อผิดพลาดที่ชัดเจน
- ชื่อเอกสารสั้นกระชับ
- คอนโทรลรอบข้างที่เข้าถึงได้ด้วยคีย์บอร์ด
- การจัดวางที่ไม่ซ่อนคอนโทรลสำคัญของตัวดู
- วิธีที่ชัดเจนในการกลับไปยังเวิร์กโฟลว์หลัก
ทดสอบด้วยชื่อไฟล์ยาว, จำนวนหน้ามาก, สเปรดชีตกว้าง, แบบร่างละเอียด, และเอกสารที่ไม่สามารถเรนเดอร์ได้ สถานะข้อผิดพลาดไม่ควรเปิดเผยเส้นทางเซิร์ฟเวอร์, ร่องรอยข้อยกเว้น, หรือ URL การจัดเก็บ
ขั้นตอนที่ 7: จัดการไฟล์และข้อมูลชั่วคราว
กำหนดนโยบายการเก็บรักษาก่อนการปรับใช้ พิจารณาไฟล์ต้นฉบับ, ข้อมูลเรนเดอร์ชั่วคราว, แคช, การส่งออก, คำอธิบาย, และบันทึกแยกกัน
มาตรการป้องกันที่เป็นประโยชน์รวมถึง:
- ไดเรกทอรีชั่วคราวเฉพาะที่มีสิทธิ์จำกัด
- ชื่อที่สร้างโดยเซิร์ฟเวอร์แบบไม่ซ้ำกัน
- การทำความสะอาดหลังเซสชันสำเร็จและล้มเหลว
- กระบวนการกำหนดเวลาสำหรับไฟล์ชั่วคราวที่ถูกละทิ้ง
- โควต้าการจัดเก็บและการเฝ้าติดตาม
- การเข้ารหัสที่พักตามนโยบายความปลอดภัยของคุณ
ทำให้การทำความสะอาดเป็นที่สังเกตได้ หากการลบล้มเหลวโดยเงียบไฟล์ชั่วคราวอาจสะสมและกลายเป็นปัญหาการดำเนินงานและความปลอดภัย
ขั้นตอนที่ 8: กำหนดค่าการป้องกันในสภาพแวดล้อมการผลิต
การเรนเดอร์เอกสารอาจใช้ CPU, หน่วยความจำ, และพื้นที่ดิสก์ชั่วคราว ปกป้องแอปพลิเคชันด้วยขีดจำกัดที่ชัดเจน:
- ขนาดอัปโหลดสูงสุด
- งานเรนเดอร์พร้อมกันสูงสุด
- เวลาในการร้องขอและประมวลผลที่หมดเวลา
- ขีดจำกัดคิวเมื่อการเรนเดอร์ทำแบบอะซิงโครนัส
- โควต้าที่เก็บชั่วคราว
- การตรวจสอบสุขภาพและการเฝ้าติดตามข้อผิดพลาดแบบโครงสร้าง
สำหรับภาระงานที่ใหญ่หรือไม่คาดคิด ให้แยกการเรนเดอร์ออกจากกระบวนการแอปพลิเคชันที่ต้องการความหน่วงต่ำ วัดผลด้วยเอกสารที่คล้ายกับลูกค้าจริงแทนพึ่งไฟล์ทดสอบขนาดเล็กเท่านั้น
ขั้นตอนที่ 9: ทดสอบเวิร์กโฟลว์ทั้งหมด
การทดสอบการรวมที่สำเร็จควรครอบคลุมมากกว่าการ “หน้าหนึ่งปรากฏขึ้น”
ทดสอบ:
- ทุกรูปแบบไฟล์ที่ต้องการ
- ไฟล์ขนาดเล็ก, ขนาดใหญ่, หลายหน้า, และไฟล์เสีย
- เอกสารที่มีฟอนต์แปลก
- ไฟล์ที่ป้องกันด้วยรหัสผ่านเมื่อเวิร์กโฟลว์ของคุณรองรับ
- ผู้ใช้ที่ได้รับอนุญาตและไม่ได้รับอนุญาต
- เซสชันการดูพร้อมกันหลายรายการ
- การรีสตาร์ทแอปพลิเคชันและการร้องขอที่ถูกขัดจังหวะ
- การทำความสะอาดหลังความสำเร็จและความล้มเหลว
- คุณลักษณะของตัวดูที่รวมอยู่ในการกำหนดค่าผลิตภัณฑ์ที่คุณเลือก
เก็บชุดเอกสารทดสอบที่ทำความสะอาดและเวอร์ชันไว้ ควรรันใหม่เมื่ออัปเกรด Doconut, .NET, Windows Server, โครงสร้างการจัดเก็บ, หรือการพึ่งพาที่เกี่ยวข้องอื่น ๆ
รายการตรวจสอบความปลอดภัย
ก่อนปล่อยให้ตรวจสอบว่า:
- ทุกคำขอการดูต้องมีการตรวจสอบสิทธิ์ตามความเหมาะสม
- มีการตรวจสอบการอนุญาตสำหรับเอกสารเฉพาะ
- อินพุตที่ผู้ใช้ควบคุมไม่สามารถกลายเป็นเส้นทางไฟล์เซิร์ฟเวอร์ที่ไม่มีข้อจำกัดได้
- ข้อมูลรับรองการจัดเก็บไม่เคยถึงฝั่งคลไอเอนท์
- มีการเปิดใช้งานขีดจำกัดและการตรวจสอบอัปโหลด
- ไฟล์ชั่วคราวมีการเข้าถึงจำกัดและนโยบายทำความสะอาดที่ทดสอบแล้ว
- บันทึกไม่รวมเนื้อหาเอกสาร, ความลับ, หรือ URL ที่สำคัญ
- ข้อความแสดงข้อผิดพลาดต่อผู้ใช้ถูกทำความสะอาด
- คอนโทรลของ SDK สามารถสนับสนุนเวิร์กโฟลว์ธุรกิจของคุณได้ แต่ไม่สามารถป้องกันการจับภาพทุกรูปแบบเมื่อข้อมูลปรากฏต่อผู้ใช้ที่ได้รับอนุญาต ใช้ร่วมกับการควบคุมการเข้าถึงและนโยบายการปกป้องข้อมูลที่เหมาะสม
Doconut อยู่ในตำแหน่งใด
Doconut ให้ความสามารถในการดูเอกสารภายในแอปพลิเคชัน .NET ของคุณ ในขณะที่แอปของคุณยังคงรับผิดชอบต่อการระบุตัวตน, การอนุญาต, การจัดเก็บไฟล์, การเก็บรักษา, การตรวจสอบ, และเวิร์กโฟลว์รอบข้าง
การแบ่งหน้าที่นี้มอบเส้นทางที่เป็นประโยชน์ให้ทีม .NET รองรับเอกสารธุรกิจโดยไม่ต้องสร้างเครื่องยนต์เรนเดอร์หลายตัวจากศูนย์ อีกทั้งยังทำให้รายละเอียดการรวมที่เฉพาะผลิตภัณฑ์ถูกผูกกับเอกสารอย่างเป็นทางการสำหรับเวอร์ชันที่คุณปรับใช้
สำรวจ Doconut .NET document viewer SDK แล้วใช้ official download and documentation resources เพื่อประเมินด้วยเอกสารของคุณเอง
สรุป
ตัวดูเอกสารแบบฝังที่เชื่อถือได้เริ่มต้นด้วยข้อกำหนดรูปแบบที่ชัดเจนและกระบวนการเอกสารฝั่งเซิร์ฟเวอร์ที่ปลอดภัย ตรวจสอบอินพุต, อนุญาตทุกคำขอเอกสาร, แยกการเข้าถึง SDK ไว้หลังบริการแอปพลิเคชัน, วางแผนการทำความสะอาดไฟล์ชั่วคราว, และทดสอบด้วยไฟล์ที่เป็นจริง
ด้วยพื้นฐานเหล่านี้ Doconut สามารถจัดหาชั้นการดูให้กับเว็บแอปพลิเคชัน .NET บน Windows ของคุณ ในขณะที่ทีมของคุณยังคงควบคุมสถาปัตยกรรมแอปพลิเคชันและวงจรชีวิตของเอกสารได้อย่างเต็มที่.