คุณควรจัดเก็บข้อมูลใน Windows Registry เมื่อใดและทำไม

ในฐานะนักพัฒนาเครื่องมือที่เก็บการกำหนดค่า / ตัวเลือกต่างๆในรีจิสทรีถือเป็นสารพิษในชีวิตของฉัน ฉันไม่สามารถติดตามการเปลี่ยนแปลงของตัวเลือกเหล่านั้นได้อย่างง่ายดายไม่สามารถโอนจากเครื่องไปยังเครื่องได้อย่างง่ายดายและทั้งหมดนี้ทำให้ฉันรู้สึกโหยหาวันเก่า ๆ ที่ดีของไฟล์. INI ...

เมื่อเขียนแอปพลิเคชันของตัวเองฉันควรเลือกที่จะใส่ลงในรีจิสทรีแทนที่จะเป็นไฟล์การกำหนดค่าแบบเก่าและเพราะเหตุใด

• การกำหนดค่า (WIN3) เดิมถูกเก็บไว้ในไฟล์ WIN.INI ในไดเร็กทอรี windows
• ปัญหา: WIN.INI ใหญ่เกินไป
• โซลูชัน (Win31): ไฟล์ INI แต่ละไฟล์ในไดเร็กทอรีเดียวกับโปรแกรม
• ปัญหา: โปรแกรมนั้นอาจติดตั้งบนเครือข่ายและมีคนจำนวนมากใช้ร่วมกัน
• โซลูชัน (Win311): ไฟล์ INI แต่ละไฟล์ในไดเร็กทอรี Window ของผู้ใช้
• ปัญหา: หลายคนอาจแชร์โฟลเดอร์ windows และควรเป็นแบบอ่านอย่างเดียวอยู่ดี
• โซลูชัน (Win95): รีจิสทรีที่มีส่วนแยกกันสำหรับผู้ใช้แต่ละคน
• ปัญหา: รีจิสทรีมีขนาดใหญ่เกินไป
• โซลูชัน (WinXP): ข้อมูลส่วนบุคคลจำนวนมากถูกย้ายไปยังโฟลเดอร์ Application Data ของผู้ใช้เอง
• ปัญหา: เหมาะสำหรับข้อมูลจำนวนมาก แต่ค่อนข้างซับซ้อนสำหรับจำนวนน้อย
• โซลูชัน (.NET): ข้อมูลคงที่และอ่านอย่างเดียวจำนวนเล็กน้อยที่จัดเก็บในไฟล์. config (Xml) ในโฟลเดอร์เดียวกับแอปพลิเคชันโดยมี API เพื่ออ่าน (อ่าน / เขียนหรือข้อมูลเฉพาะของผู้ใช้อยู่ในรีจิสทรี)

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

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

อ็อพชันที่กำหนดค่าได้หรือ dll ที่ต้องการเป็นต้นหากไม่ได้แชร์ควรอยู่ในไดเร็กทอรีย่อยของไดเร็กทอรีการติดตั้งเพื่อให้ย้ายการติดตั้งทั้งหมดได้อย่างง่ายดาย

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

นโยบายของ Microsoft:

• ก่อน windows 95 เราใช้ไฟล์ ini สำหรับข้อมูลแอปพลิเคชัน
• ในยุค windows 95 - XP เราใช้รีจิสทรี
• จาก windows Vista เราใช้ไฟล์ ini แม้ว่าตอนนี้จะใช้ xml แล้วก็ตาม

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

เมื่อไหร่ - คุณถูกบังคับเนื่องจากการรวมระบบเดิมหรือเนื่องจากผู้ดูแลระบบของลูกค้าของคุณบอกว่า "จะต้องเป็นเช่นนั้น" หรือเนื่องจากคุณกำลังพัฒนาในภาษาที่เก่ากว่าทำให้ใช้ XML ได้ยากขึ้น

ทำไม - ส่วนใหญ่เป็นเพราะรีจิสทรีไม่พกพาได้เหมือนกับการคัดลอกไฟล์กำหนดค่าที่อยู่ถัดจากแอปพลิเคชัน (และเรียกว่าเกือบจะเหมือนกัน)

หากคุณใช้. Net2 + แสดงว่าคุณมีไฟล์ App.Config และ User.Config และคุณไม่จำเป็นต้องลงทะเบียน DLL ในรีจิสทรีดังนั้นอย่าอยู่ห่างจากมัน

ไฟล์กำหนดค่ามีปัญหาในตัวเอง (ดูด้านล่าง) แต่ไฟล์เหล่านี้สามารถเข้ารหัสได้และคุณสามารถปรับเปลี่ยนสถาปัตยกรรมของคุณได้

• ปัญหา: แอปพลิเคชันต้องการการตั้งค่าที่กำหนดค่าได้
• วิธีแก้ไข: จัดเก็บการตั้งค่าในไฟล์ (WIN.INI) ในโฟลเดอร์ Windows - ใช้ส่วนหัวเพื่อจัดกลุ่มข้อมูล (Win3.0)
• ปัญหา: ไฟล์ WIN.INI ใหญ่เกินไป (และยุ่ง)
• วิธีแก้ไข: จัดเก็บการตั้งค่าในไฟล์ INI ไว้ในโฟลเดอร์เดียวกับแอปพลิเคชัน (Win3.1)
• ปัญหา: ต้องการการตั้งค่าเฉพาะผู้ใช้
• วิธีแก้ไข: จัดเก็บการตั้งค่าผู้ใช้ในไฟล์ INI เฉพาะผู้ใช้ในไดเร็กทอรี Window ของผู้ใช้ (Win3.11) หรือส่วนเฉพาะผู้ใช้ในไฟล์ INI ของแอปพลิเคชัน
• ปัญหา: ความปลอดภัย - การตั้งค่าแอปพลิเคชันบางอย่างจำเป็นต้องอ่านอย่างเดียว
• วิธีแก้ไข: รีจิสทรีที่มีการรักษาความปลอดภัยตลอดจนส่วนเฉพาะผู้ใช้และทั้งเครื่อง (Win95)
• ปัญหา: รีจิสทรีมีขนาดใหญ่เกินไป
• วิธีแก้ไข: รีจิสตรีเฉพาะผู้ใช้ย้ายไปที่ user.dat ในโฟลเดอร์ "Application Data" ของผู้ใช้เองและโหลดเฉพาะเมื่อเข้าสู่ระบบ (WinNT)
• ปัญหา: ในสภาพแวดล้อมขององค์กรขนาดใหญ่คุณเข้าสู่ระบบหลายเครื่องและต้องตั้งค่าแต่ละเครื่อง
• วิธีแก้ไข: แยกความแตกต่างระหว่างโปรไฟล์ภายใน (Local Settings) และโรมมิ่ง (ข้อมูลแอปพลิเคชัน) (WinXP)
• ปัญหา: xcopy ใช้งานหรือย้ายแอปพลิเคชันไม่ได้เหมือนกับ. Net ที่เหลือ
• วิธีแก้ไข: ไฟล์ APP.CONFIG XML ในโฟลเดอร์เดียวกับแอปพลิเคชัน - อ่านง่ายเคลื่อนย้ายง่ายเคลื่อนย้ายง่ายสามารถติดตามได้หากมีการเปลี่ยนแปลง (.Net1)
• ปัญหา: ยังคงต้องจัดเก็บข้อมูลเฉพาะผู้ใช้ในลักษณะที่คล้ายกัน (เช่น xcopy deploy)
• วิธีแก้ไข: ไฟล์ USER.CONFIG XML ในโฟลเดอร์โลคัลหรือโรมมิ่งของผู้ใช้และพิมพ์อย่างแน่นหนา (.Net2)
• ปัญหา: ไฟล์ CONFIG เป็นแบบตรงตามตัวพิมพ์เล็กและใหญ่ (ไม่ใช้งานง่ายสำหรับมนุษย์) ต้องการ "แท็ก" แบบเปิด / ปิดที่เฉพาะเจาะจงมากไม่สามารถตั้งค่าสตริงการเชื่อมต่อในขณะทำงานได้โครงการติดตั้งไม่สามารถเขียนการตั้งค่าได้ (ง่ายเหมือนรีจิสตรี) ไม่สามารถระบุได้อย่างง่ายดาย ไฟล์ user.config และการตั้งค่าผู้ใช้จะถูกเป่าเมื่อมีการติดตั้งการแก้ไขใหม่แต่ละครั้ง
• วิธีแก้ไข: ใช้สมาชิก ITEM เพื่อตั้งค่าสตริงการเชื่อมต่อที่รันไทม์เขียนโค้ดในคลาส Installer เพื่อเปลี่ยน App.Config ระหว่างการติดตั้งและใช้การตั้งค่าแอพพลิเคชั่นเป็นค่าเริ่มต้นหากไม่พบการตั้งค่าของผู้ใช้

โลกจะถึงจุดจบหรือไม่หากคุณเก็บตำแหน่งหน้าต่างสองสามตำแหน่งและรายการที่ใช้ล่าสุดในรีจิสทรีของ Windows? มันใช้งานได้สำหรับฉันจนถึงตอนนี้

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

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

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

หากคุณกำลังพัฒนาแอพใหม่และคุณสนใจเกี่ยวกับการพกพาคุณไม่ควรพลาดเก็บข้อมูลไว้ใน Windows Registry เนื่องจาก OS อื่นไม่มีรีจิสทรี (windows) (duh note - สิ่งนี้อาจชัดเจน แต่มักถูกมองข้าม)

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

นอกประเด็นเล็กน้อย แต่เนื่องจากฉันเห็นผู้คนกังวลเกี่ยวกับการพกพาวิธีที่ดีที่สุดที่ฉันเคยใช้คือคลาส QSettings ของ Qt เป็นนามธรรมการจัดเก็บการตั้งค่า (รีจิสทรีบน Windows, ไฟล์การกำหนดลักษณะ XML บน Mac OS และไฟล์ Ini บน Unix) ในฐานะลูกค้าของชั้นเรียนฉันไม่ต้องใช้วงจรสมองสงสัยเกี่ยวกับรีจิสทรีหรือสิ่งอื่นใดมันใช้งานได้ (tm)

http://doc.trolltech.com/4.4/qsettings.html#details

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

ถ้าฉันดูที่โฟลเดอร์เอกสารและการตั้งค่าของฉันฉันเห็นโปรแกรมมากมายที่ใช้สัญลักษณ์ Unix dot สำหรับการตั้งค่าโฟลเดอร์: .p4qt .sqlworkbench .squirrel-sql.SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (ฯลฯ )

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

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

ใน. NET นั้นไม่จำเป็นเลย

ต่อไปนี้เป็น 2 ตัวอย่างที่แสดงวิธีการใช้พร็อพเพอร์ตี้โครงการเพื่อดำเนินการนี้

ตัวอย่างเหล่านี้ทำได้โดย Windows User Project Properties แต่ Application ก็สามารถทำได้เช่นกัน

เพิ่มเติมที่นี่:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(ล่าช้าในการอภิปราย แต่) คำตอบสั้น ๆ : นโยบายกลุ่ม

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

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

ฉันเชื่อว่า Windows Registry เป็นความคิดที่ดี แต่เนื่องจากการละเมิดอย่างมากจากผู้พัฒนาแอปพลิเคชันและนโยบายมาตรฐานที่ Microsoft ไม่สนับสนุน / ได้รับคำสั่งจาก Microsoft ทำให้กลายเป็นสัตว์ร้ายที่ไม่สามารถจัดการได้ ฉันเกลียดการใช้มันด้วยเหตุผลที่คุณพูดถึง แต่มีบางครั้งที่ใช้มัน:

• ทิ้งร่องรอยของแอปพลิเคชันของคุณหลังจากถอนการติดตั้งแอปพลิเคชันของคุณแล้ว (เช่นจดจำการตั้งค่าของผู้ใช้ในกรณีที่มีการติดตั้งแอปพลิเคชันอีกครั้ง)
• แบ่งปันการตั้งค่าการกำหนดค่าระหว่างแอปพลิเคชันต่างๆ - ส่วนประกอบ