Khi nào - và tại sao - bạn nên lưu trữ dữ liệu trong Windows Registry?

Là một nhà phát triển, các công cụ lưu trữ cấu hình / tùy chọn trong sổ đăng ký là nguyên nhân sống còn của tôi. Tôi không thể dễ dàng theo dõi các thay đổi đối với các tùy chọn đó, không thể dễ dàng chuyển chúng từ máy này sang máy khác và tất cả đều khiến tôi thực sự khao khát những ngày tốt đẹp của các tệp .INI ...

Khi viết các ứng dụng của riêng tôi, tôi nên chọn cái gì - nếu có - trong các tập tin cấu hình lỗi thời, và tại sao?

• Cấu hình ban đầu (WIN3) được lưu trữ trong tệp WIN.INI trong thư mục windows.
• Vấn đề: WIN.INI phát triển quá lớn.
• Giải pháp (Win31): các tệp INI riêng lẻ trong cùng thư mục với chương trình.
• Vấn đề: Chương trình đó có thể được cài đặt trên mạng và được nhiều người chia sẻ.
• Giải pháp (Win311): các tệp INI riêng lẻ trong thư mục Window của người dùng.
• Vấn đề: Nhiều người có thể chia sẻ một thư mục windows và dù sao nó cũng chỉ nên đọc.
• Giải pháp (Win95): Đăng ký với các phần riêng biệt cho mỗi người dùng.
• Vấn đề: Đăng ký phát triển quá lớn.
• Giải pháp (WinXP): Khối lớn dữ liệu riêng lẻ được chuyển sang thư mục Dữ liệu ứng dụng của người dùng.
• Vấn đề: Tốt cho số lượng lớn dữ liệu, nhưng khá phức tạp đối với số lượng nhỏ.
• Giải pháp (.NET): một lượng nhỏ dữ liệu cố định, chỉ đọc được lưu trữ trong các tệp .config (Xml) trong cùng thư mục với ứng dụng, với API để đọc. (Đọc / ghi hoặc dữ liệu cụ thể của người dùng vẫn ở trong sổ đăng ký)

Xuất phát từ điều này cả từ góc độ người dùng và quan điểm lập trình viên, tôi sẽ phải nói rằng thực sự không có một lý do tốt nào để đưa một cái gì đó vào sổ đăng ký trừ khi đó là một cái gì đó giống như liên kết tệp hoặc cài đặt cụ thể của máy.

Tôi đến từ trường phái cho rằng một chương trình nên được chạy từ bất cứ nơi nào nó được cài đặt, rằng cài đặt phải hoàn toàn có thể di chuyển trong một máy, hoặc thậm chí đến một máy khác và không ảnh hưởng đến hoạt động của nó.

Bất kỳ tùy chọn cấu hình, hoặc dlls cần thiết, v.v., nếu chúng không được chia sẻ nên nằm trong thư mục con của thư mục cài đặt, để toàn bộ cài đặt dễ dàng di chuyển.

Tôi sử dụng rất nhiều tiện ích nhỏ hơn như các chương trình, vì vậy nếu nó không thể được cài đặt trên thanh usb và cắm vào máy khác và chỉ chạy, thì nó không dành cho tôi.

Chính sách của Microsoft:

• Trước windows 95, chúng tôi đã sử dụng các tệp ini cho dữ liệu ứng dụng.
• Trong kỷ nguyên windows 95 - XP, chúng tôi đã sử dụng sổ đăng ký.
• Từ windows Vista, chúng tôi sử dụng các tệp ini mặc dù chúng hiện dựa trên xml.

Việc đăng ký phụ thuộc vào máy. Tôi chưa bao giờ thích nó bởi vì nó đang chậm lại và gần như không thể tìm thấy thứ bạn cần. Đó là lý do tại sao tôi thích ini đơn giản hoặc các tệp cài đặt khác. Bạn biết vị trí của chúng (thư mục ứng dụng hoặc thư mục người dùng) để chúng dễ dàng mang theo và người có thể đọc được.

Khi nào - Bạn bị buộc phải do tích hợp di sản hoặc vì sysadmin của khách hàng của bạn nói rằng "nó sẽ như vậy" hoặc do bạn đang phát triển bằng ngôn ngữ cũ khiến việc sử dụng XML trở nên khó khăn hơn.

Tại sao - Chủ yếu là vì sổ đăng ký không khả dụng như sao chép tệp cấu hình nằm bên cạnh ứng dụng (và được gọi là gần giống nhau).

Nếu bạn đang sử dụng .Net2 + bạn đã có các tệp App.Config và User.Config và bạn không cần phải đăng ký DLL trong sổ đăng ký, vì vậy hãy tránh xa nó.

Các tệp cấu hình có các vấn đề riêng của chúng (xem bên dưới), nhưng chúng có thể được mã hóa xung quanh và bạn có thể thay đổi kiến ​​trúc của mình.

• Vấn đề: Ứng dụng cần cài đặt cấu hình.
• Giải pháp: Lưu trữ cài đặt trong một tệp (WIN.INI) trong thư mục Windows - sử dụng các tiêu đề của phần để nhóm dữ liệu (Win3.0).
• Vấn đề: Tệp WIN.INI đã phát triển quá lớn (và trở nên lộn xộn).
• Giải pháp: Lưu trữ cài đặt trong các tệp INI trong cùng thư mục với ứng dụng (Win3.1).
• Vấn đề: Cần cài đặt dành riêng cho người dùng.
• Giải pháp: Lưu trữ cài đặt người dùng trong các tệp INI dành riêng cho người dùng trong thư mục Window của người dùng (Win3.11) hoặc các phần dành riêng cho người dùng trong tệp INI của ứng dụng.
• Vấn đề: Bảo mật - một số cài đặt ứng dụng cần ở chế độ chỉ đọc.
• Giải pháp: Đăng ký với bảo mật cũng như các phần dành riêng cho người dùng và toàn máy (Win95).
• Vấn đề: Đăng ký phát triển quá lớn.
• Giải pháp: Sổ đăng ký dành riêng cho người dùng đã chuyển sang user.dat trong thư mục "Dữ liệu ứng dụng" của người dùng và chỉ được tải khi đăng nhập (WinNT).
• Vấn đề: Trong môi trường doanh nghiệp lớn, bạn đăng nhập vào nhiều máy và phải thiết lập MACHI MỘT.
• Giải pháp: Phân biệt giữa cấu hình cục bộ (Cài đặt cục bộ) và chuyển vùng (Dữ liệu ứng dụng) (WinXP).
• Vấn đề: Không thể triển khai xcopy hoặc di chuyển các ứng dụng như phần còn lại của .Net.
• Giải pháp: Tệp XML APP.CONFIG trong cùng thư mục với ứng dụng -, dễ đọc, dễ thao tác, dễ di chuyển, có thể theo dõi nếu thay đổi (.Net1).
• Vấn đề: Vẫn cần lưu trữ dữ liệu cụ thể của người dùng theo cách tương tự (ví dụ: triển khai xcopy).
• Giải pháp: USER.CONFIG Tệp XML trong thư mục cục bộ hoặc chuyển vùng của người dùng và được gõ mạnh (.Net2).
• Vấn đề: Các tệp CONFIG phân biệt chữ hoa chữ thường (không trực quan với con người), yêu cầu "thẻ" đóng / mở rất cụ thể, các chuỗi kết nối không thể được đặt trong thời gian chạy, các dự án thiết lập không thể ghi cài đặt (dễ dàng như đăng ký), không thể dễ dàng xác định tập tin user.config và cài đặt người dùng được thổi với mỗi phiên bản mới được cài đặt.
• Giải pháp: Sử dụng thành viên ITEM để đặt chuỗi kết nối khi chạy, viết mã trong lớp Trình cài đặt để thay đổi App.Config trong khi cài đặt và sử dụng cài đặt ứng dụng làm mặc định nếu không tìm thấy cài đặt người dùng.

Có phải thế giới sẽ kết thúc nếu bạn lưu trữ một vài vị trí cửa sổ và một danh sách các mục được sử dụng gần đây nhất trong sổ đăng ký Windows? Nó đã làm việc tốt cho tôi cho đến nay.

HKEY-HIỆN TẠI-NGƯỜI DÙNG là một nơi tuyệt vời để lưu trữ dữ liệu người dùng tầm thường với số lượng nhỏ. Đó là những gì nó làm. Có vẻ ngớ ngẩn khi không sử dụng cho mục đích dự định của mình chỉ vì những người khác đã lạm dụng nó.

Các cài đặt mà bạn muốn có sẵn trong hồ sơ chuyển vùng của người dùng có thể phải có trong sổ đăng ký, trừ khi bạn thực sự muốn tìm kiếm thư mục Dữ liệu ứng dụng của người dùng bằng tay. :-)

Đăng ký đọc và ghi là chủ đề an toàn nhưng tập tin thì không. Vì vậy, nó phụ thuộc vào việc chương trình của bạn có đơn luồng hay không.

Nếu bạn đang phát triển một ứng dụng mới và bạn quan tâm đến tính di động, bạn KHÔNG BAO GIỜ lưu trữ dữ liệu trong sổ đăng ký vì các hệ điều hành khác không có sổ đăng ký (windows) - điều này có thể rõ ràng nhưng thường bị bỏ qua).

Nếu bạn chỉ phát triển cho các nền tảng Win ... hãy cố gắng tránh nó càng nhiều càng tốt. Các tập tin cấu hình (có thể được mã hóa) là một giải pháp tốt hơn. Không có lợi ích trong việc lưu trữ dữ liệu vào sổ đăng ký - (lưu trữ bị cô lập là một giải pháp tốt hơn nhiều, ví dụ nếu bạn đang sử dụng .NET).

Hơi lạc đề, nhưng vì tôi thấy mọi người lo ngại về tính di động, cách tiếp cận tốt nhất tôi từng sử dụng là lớp QSinstall của Qt. Nó trừu tượng hóa việc lưu trữ các cài đặt (đăng ký trên Windows, tệp ưu tiên XML trên Mac OS và các tệp Ini trên Unix). Là một khách hàng của lớp, tôi không phải trải qua một chu kỳ não bộ tự hỏi về sổ đăng ký hay bất cứ điều gì khác, nó chỉ hoạt động (tm).

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

Thông thường, nếu bạn không đặt cài đặt trong sổ đăng ký, bạn chủ yếu sử dụng nó để nhận cài đặt Windows hiện tại, thay đổi liên kết tệp, v.v.
Bây giờ, nếu bạn cần phát hiện xem phần mềm của bạn đã được cài đặt chưa, bạn có thể tạo một mục nhập tối thiểu trong sổ đăng ký , đó là một vị trí bạn có thể tìm thấy trong bất kỳ cấu hình nào. Hoặc tìm kiếm một thư mục tên đã cho trong Dữ liệu ứng dụng.

Nếu tôi nhìn vào thư mục Tài liệu và Cài đặt, tôi thấy rất nhiều phần mềm sử dụng ký hiệu chấm Unix để cài đặt các thư mục: .p4qt .sqlworkbench .squirrel-sql .SunDoadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis. .jindent .jogl_ext (v.v.)

và trong Dữ liệu ứng dụng, các thư mục khác nhau có tên trình soạn thảo hoặc tên phần mềm. Có vẻ như là xu hướng hiện tại, ít nhất là trong số các ứng dụng di động ...
WinMerge sử dụng một cách tiếp cận hơi khác, lưu trữ dữ liệu trong sổ đăng ký, nhưng cung cấp Nhập và Xuất các tùy chọn trong hộp thoại cấu hình.

Cá nhân tôi đã sử dụng sổ đăng ký để lưu trữ các đường dẫn cài đặt để sử dụng bởi các tập lệnh cài đặt (un). Tôi không chắc đây có phải là lựa chọn khả thi duy nhất không, nhưng có vẻ như là một giải pháp hợp lý. Tất nhiên, đây là một ứng dụng chỉ được sử dụng trên Windows.

Trong .NET thực sự KHÔNG bao giờ có nhu cầu.

Dưới đây là 2 ví dụ cho thấy cách sử dụng các chương trình dự án để thực hiện việc này.

Các ví dụ này thực hiện điều này bởi Windows User Project Properties, nhưng ứng dụng cũng có thể / có thể được thực hiện tương tự.

Thêm ở đây:

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

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

(muộn để thảo luận nhưng) Trả lời ngắn: Chính sách nhóm.

Nếu bộ phận CNTT của khách hàng của bạn muốn thực thi các cài đặt liên quan đến Windows hoặc (các) thành phần bạn đang viết hoặc gói, chẳng hạn như tốc độ liên kết hoặc thông báo lỗi tùy chỉnh hoặc máy chủ cơ sở dữ liệu để kết nối, thì đây vẫn là thông thường được thực hiện thông qua Chính sách nhóm, biểu hiện cuối cùng của nó là các cài đặt được lưu trữ trong sổ đăng ký. Các chính sách này được thi hành kể từ khi Windows khởi động hoặc người dùng đăng nhập.

Có các công cụ để tạo các mẫu ADMX tùy chỉnh có thể ánh xạ cài đặt của các thành phần của bạn đến các vị trí đăng ký và cung cấp cho quản trị viên một giao diện chung để thực thi (các) chính sách mà anh ta cần phải thực thi trong khi chỉ hiển thị cho họ các cài đặt có ý nghĩa để thực thi theo cách này.

Tôi tin rằng Windows Registry là một ý tưởng tốt, nhưng vì sự lạm dụng lớn từ các nhà phát triển ứng dụng và các chính sách tiêu chuẩn không được Microsoft khuyến khích / ủy quyền đã trở thành một con thú không thể quản lý được. Tôi ghét sử dụng nó vì những lý do bạn đã đề cập, tuy nhiên có một số trường hợp có ý nghĩa khi sử dụng nó:

• Để lại dấu vết của ứng dụng của bạn sau khi ứng dụng của bạn đã được gỡ cài đặt (ví dụ: hãy nhớ tùy chọn của người dùng trong trường hợp ứng dụng được cài đặt lại)
• Chia sẻ cài đặt cấu hình giữa các ứng dụng khác nhau - các thành phần