Як я можу зберігати дані, які читаються тільки для розгортання разом із моєю програмою?

17

Я розробляю настільний додаток, і ця програма потребує деякої інформації для запуску, але вона не змінює жодної з цих даних (дані потрібно завантажувати при кожному виконанні програми, але дані ніколи не змінюються). Дані потрібно зберігати на тому ж комп’ютері, на якому працює додаток (сховище на стороні клієнта?).

Також краще, якщо користувач не може легко змінити цю інформацію (припустимо, що у них не дуже багато знань про ІТ).

Як я повинен зберігати таку інформацію? Локальна база даних? XML, що надсилається разом із додатком?

Я використовую WPF.

c# design data wpf

— appa yip yip
джерело

2

Це не мета. Мета - це сайт для обговорення проблем чи проблем щодо основних сайтів, на яких задаються питання.

— jpmc26

1

Чому ви не хочете, щоб користувачі міняли інформацію? Це питання безпеки чи що? Чи повинна ця інформація зберігатися в таємниці від користувача? Причини можуть сильно змінити відповіді, які відповідають.

— jpmc26

1

@ Jpmc26 Ну, це свого роду проблема безпеки, але це не має великого значення . Основна мета програми - спілкуватися через послідовний порт з регулятором температури (наприклад, цей ), і XML зберігатиме деяку інформацію про адреси пам'яті контролера. Якщо користувач змінить це, це може спричинити проблеми під час виконання, тому я хотів би його уникнути. Але це, як я вже казав, викликає занепокоєння, не велика справа. ps: редагував питання про заміну мета на SE . Спасибі.

— appa yip yip

2

Якщо ви хочете локальну базу даних, подивіться на SQLite. (Але якщо даних досить мало для завантаження в оперативну пам'ять при запуску, я віддаю перевагу простий структурований файл, наприклад json або щось бінарне)

— CodesInChaos

1

"Якщо користувач змінить це, це може спричинити проблеми під час виконання, тому я хотів би цього уникнути." зовсім не схоже на питання безпеки. Охорона безпеки - це те, де у файлі є пароль та інше. Просто поставте параметри у XML-файл поруч із виконуваним файлом, а вгорі поставте коментар із написом "Не торкайтеся налаштувань у цьому файлі !!". Якщо користувач редагує випадкові файли у вашому каталозі встановлення, вони заслуговують на будь-яку розбитість.

— Роджер Ліпскомб

14

Бінарний файл був би очевидною відповіддю, але це залежить від того, як ви завантажуєте його - ви також можете полегшити життя, якщо зможете.

XML може бути хорошим вибором, оскільки в C # є вбудовані методи для його читання. Ви можете додати контрольну суму до своїх даних, так що якщо користувач змінить її, контрольна сума більше не збігатиметься (вам потрібно додати чек, щоб переконатися, що контрольна сума є дійсною)

Місцевий db може створити більше проблем, оскільки у вас є інші залежності, вам потрібно мати доступ до нього

— Метт Вілько
джерело

Я не думав про контрольну суму, це дійсно приємна ідея. Отже, я генерую контрольну суму і зберігаю її у своїй програмі, тому щоразу, коли я несеріалізую XML, я генерую нову контрольну суму і порівнюю її з першою?

— appa yip yip

4

Якщо ви зберігаєте контрольну суму в програмі, ви ніколи не дозволите іншу конфігурацію, тому ви можете також зберігати дані конфігурації як константи програми у своєму коді. Якщо ви хочете мати можливість змінити конфігурацію в майбутньому, додайте контрольну суму (кращим терміном буде "хеш") як поле XML і використовуйте її для того, щоб переконатися, що XML не був підроблений. Звичайно, рішучий зловмисник може дослідити ваш код, знайти вашу хеш-логіку і використовувати його для створення дійсних файлів XML, але все-таки клієнтські програми завжди вразливі до визначених зловмисників.

— SJuan76

4

Замість файлового або локального db краще буде вбудований у збірку файл ресурсів. Приховано від кінцевого споживача, легко керується розробником, але все-таки зручно для користувачів. Якщо продуктивність викликає занепокоєння, то двійкова серіалізація була б кращою.

— PTwr

@ SJuan76 Так, проблема хешу на XML полягає в тому, що його можна змінити, якщо хтось несериалізує його. У будь-якому випадку, якщо зміна XML (що, я думаю, це не відбудеться, але хто знає), воно зміниться лише в новій версії програми, тож здогадайтеся, я буду дотримуватися хеш-код.

— appa yip yip

2

@schmaedeck: Файли ресурсів - це буквально файли всередині виконуваного двійкового файлу. Значки та рядки та будь-які інші постійні дані, необхідні вашій програмі.

— Mooing Duck

21

Якщо дані ніколи не змінюються і читаються лише , то просто покладіть їх у файл коду як список констант.

public readonly string AppStartUpData = "MyAppNeedsThis";

Якщо ці дані відрізняються на розгортання, то зовнішній файл чудово.

.Net поставляється із вбудованими файлами .config (App.Config). Слід скористатися тими способами, як існують стандартні способи (вбудовані в рамки) для зчитування інформації з них.

Використовуйте файли конфігурації у випадку, якщо налаштування потрібно змінити (ніколи не кажіть ніколи), оскільки вони є лише текстовими файлами (Xml). Якщо є конфіденційна інформація, за потреби можна зашифрувати налаштування.

— Джон Рейнор
джерело

Я подумав про константи / readonlys, проблема полягає в тому, що є багато даних, тому, мабуть, я буду працювати з зовнішнім файлом. Дякую!

— appa yip yip

5

@schmaedeck ... так? Ви можете помістити ці визначення в окремий файл та імпортувати це. Насправді я вважаю, що Qt робить такі речі під час компіляції форм і речей, тому ви отримуєте автоматично створені файли, які мають мегабайти двійкових даних (наприклад, зображення) на деяких константах, але якщо вони знаходяться в окремому файлі, нічого поганого в цьому немає .

— Бакуріу

15

Ви завжди можете додати файл у свій проект і встановити його тип збірки Embedded Resourceтаким чином, щоб він вбудовувався безпосередньо в саму програму.

Крім того, файл, який шифрується та розміщується у доступному місці.

— TheLethalCoder
джерело

1

Це найкраща відповідь. Я хотів би побачити ще кілька вказівок, як цього досягти. Ви отримуєте переваги потенційно змінного файлу конфігурації, але отримуєте його статичним, як він вбудований у вашу збірку.

— Гусдор

5

Якщо ви не хочете, щоб користувач навіть зазирав до даних, вам слід їх серіалізувати у файл бінарних даних.

Лише додаток знав би довжину шматочків, щоб прочитати з нього.

Я не знаю C #, але в Java ви створили б такий файл:

FileOutputStream fos = new FileOutputStream(file);      
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(var1);
oos.writeObject(var2);
oos.writeObject(var3);
oos.writeObject(var4);

... і вони читають це так:

FileInputStream fis = new FileInputStream(file);
ObjectInputStream ois = new ObjectInputStream(fis);
Object o[] = new Object[4];
o[0] = ois.readObject();
o[1] = ois.readObject();
o[2] = ois.readObject();
o[3] = ois.readObject();

— Тулан Кордова
джерело

Я обов'язково використовую двійкову серіалізацію. Дякую за ваш час!

— appa yip yip