К примеру, у меня есть программа, которую будут использовать несколько юзеров на одной машине. Программа, в процессе своей работы накапливает некоторые данные, с которыми работает сама, без вмешательства юзера. Тем не менее, для каждого юзера данные различные.
Мне известны два наиболее распространенных варианта, каждый из которых имеет свои недостатки:
1.    Хранить данные в папке с программой. Пример qip. Тут недостаток в том, что любой юзер будет иметь доступ к файлам другого юзвера, кроме что ограничивать доступ вручную.
2.    Второй вариан, как делают большинство программ, хранить данные в папке «Application Data» юзера. Этот вариант мне больше нравится, но он не лишен недостатков. При переустановки системы все данные пойдут на юг лесом.

 А к примеру qip можно держать на другом разделе и даже не морочится с установкой. Да и настолько мне кажется философия .Net говорит в пользу первого варианта…


Какой по Вашему мнению вариант более правильный, или есть третий хороший вариант?

Есть два нормальных варианта:

1) Хранить данные в папке "Application Data" юзера. Надеяться, что сисадмин компьютера, на котором установлена программа, не идиот, и перенес пользовательские профили на другой раздел, отличный от системного.

2) Пользоваться операционными системами с разумно организованной файловой системой (в которых от сисадмина не требуются проявления интеллекта для решения подобных задач).   

Мне больше нравится первый вариант (правда, я не очень понимаю, причём тут "философия .NET"...). И указанный тобой недостаток

во втором варианте тоже может присутствовать. 


  Старый добрый Windows...

Да, и ещё я не понимаю, зачем ограничивать доступ к данным, которые

 

Добавлено через 1 минуту и 41 секунду


  Вот, вот. 

Это сообщение отредактировал(а) kemiisto - 17.1.2009, 02:40

Там может иметь доступ разве что юзверь с учётной записью администратора.




Посмотри ту же папку «Application Data», там все данные такого типа. Если данные (файлы), предназначены для работы с ними юзверя, они хранятся в папке «Мои документы»
А почему к ним давать доступ кому попало?

Я за v2.

Если выбираешь вариант 1, то ты фактически вешаешь на своей программе крест для обычных (не продвинутых) пользователей.
И вот почему.
Потому что не продвинутый пользователь ставит программу в папку по-умолчанию, т.к. он не знает, как её сменить. А папка по-умолчанию - это Program Files. А Program Files - это только чтение для не админов - ок, в XP и ниже считай все работают админами (за исключением корпоративной среды) - а в Vista и выше - наоборот. 
Соответственно, ваша программа не будет работать, если её устанавливать по-дефолту (практика "жми Next/Next/Next...").

P.S. Я, кстати, QIP сам не люблю за то, что он профили в папке с пользователями хранит. Вместо того, чтобы перетащить свой профиль на другую машину, мне теперь приходится по всему винту шерстить в поисках этих программ, которые хрен знает где хранят свои данные. Хорошо хоть Infium версия научилась делать правильно.

P.P.S. Ссылка в тему, ссылка в тему 2.

Добавлено через 2 минуты и 52 секунды

Тот же QIP: переписка с заказчиком, "волшебные" номера, явки, пароли...    Извините, лучше я в папке AppData это буду хранить (ещё и атрибут шифрования накину), чем, скажем, в корне D  ;)

CodeMonkey, и это по твоему без вмешательства юзера?

Добавлено через 6 минут и 21 секунду

А я и сказал

а может и не присутствовать.

Добавлено через 7 минут и 46 секунд

Да. И Фантом его уже озвучил - испоьзовать *nix системы!  

Да, это я называю "без вмешательства пользователя". С моей точки зрения это данные, создаваемые программой автоматически. "С вмешательством" пользователя - это когда вы в текстовом редакторе что-то написали и выбрали "Сохранить как". А то, что эти данные ещё куда-то программа может скидывать - это уже другое дело.
А что тогда по-вашему без вмешательства юзера? Без вмешательства юзера компьютер даже не включится. Как насчёт водящего мыла? Это с вмешательством или без? Как насчёт кэша, где могут храниться критические данные. Это с вмешательством или без? Как насчёт автоматической БД thumbnails? Это с вмешательством или без? 
Суть в том, что всё это - данные пользователя, а, следовательно, доступ к ним должен быть ограничен.

Я и сам за второй вариант.   Ну всё же хотел убедиться в правильности выбора.
Всем спасибо, хотя дискуссию думаю можно и продолжить.  

Вообще это зависит от обстоятельств. Например, многие программы предлагают две версии: стационарную или мобильную (или же одну, но при установке спрашивается, куда ставим: на машину или на флешку).

Реестр:
- непереносимость между машинами
- помирает в случае падения винды
+ можно плодить копии проги с одним и тем же набором настроек
+ контроль доступа
+? по-майкрософтовски кошерно
+ возможность делать иерархию
+ возможность записывать бинарные данные

Ini
+ отличная переносимость
+ при падении винды легко скопировать
+ можно редактировать вручную (экспертные натстройки, которым не нашлось места в ГУЕ)
- сложно организовать иерархию
- сложно хранить бинарные данные (то есть, придётся кодировать в base64 или ещё как-нибудь)

Xml
+ все плюсы Ini
+ иерархия любой вложенности и сложности
- бинарные данные опять же в пролёте

контроль доступа в случае файлов ложится на файловую систему.

Хранение файла в папке с прогой:
+ прога самодостаточна, портабельна, легко переносится (в т.ч. на флешку или компакт)
- права доступа в XP+
- несколько юзеров юзают одни настройки

Хранение файла в AppData:
+ с правами доступа всё ОК (причем по дефолту)
+ у каждого юзера свои настройки
- прога не самодостаточна, при переносе нужно искать файл "где-то там"

В общем, мой выбор таков:
1) Файлы - однозначно. Формат файла определяется нуждами, глупо для линейного набора параметров "key=value" юзать XML.
2) При запуске проверка на наличие файла в папке с программой (либо любой другой способ указать программе, чтобы искала настройки рядом с собой - дополнительный файл seek_settings_here или portable.dat (а-ля AlReader и PDF-XChange Viewer) либо файл самых общих настроек, указывающий относительный путь к подпапке с персональными настройками (а-ля FileZilla) - не суть). Но делать ОБЯЗАТЕЛЬНО! Ибо портабельность рулит.
3) Если рядом с собой настроек не найдено - идти в AppData.

Именно такая схема используется в uTorrent, и я считаю её оптимальной. Она удовлетворяет двум самым важным аспектам: портабельности путём несложной настройки и многопрофильности+разграничению прав. Реестр в этом случае по некоторым аспектам идёт вровень, по некоторым - проигрывает.

Base64.

если юзер совсем нуб поставил прогу в "C:/Program Files", то и при первом варианте при переустановке системы все данные идут лесом. а домашний каталог можно и на другом разделе хранить, + мастер переноса файлов никто не отменял.

Некрофилы   

Мммммда......
не дай бог Вам уважаемые писать коммерческий софт... 

А если по существу, то изучите соглашение для ос виндовс для разработчиков прикладных программ (особенно делая упор на висту и выше). И тогда не будет возникать глупых опросов о том "как написать софт коротый не будет работать у половины пользователей".

Добавлено через 10 минут и 26 секунд
Судя по голосованию ~40% напишут софт не совместимый с вистой... 
еще 40% сделают все чтобы сисадмин    при попытке перенести данные пользователя.
остальные определятся в зависимости от солнечной активности... как им поступить...

что ж... это объективная реальность... удивляться тут нечему.

Application Data - это данные приложения! но не как ни пользователя! и я даже не знаю как бы я    того    который принес бы мне проект сохраняющий туда данные пользователя.

Всех злобным кодерам советую изучить структуру хранения данных в opera (браузер такой)... имхо один из лучших вариантов организации данных приложения и пользователя.  

Вы бы внимательно прочитали первый пост, а потом ругались бы.


Вот именно, Application Data - это данные приложения, но для каждого пользователя они различны