Есть статическая коллекция




Как лучше всего сериализовать коллекцию DefaultProfiles?

Я читал, что сериализовать можно только нестатические и не рид-онли члены. Т. е. чтобы сериализовать DefaultProfiles, мне нужно сделать свойство-копию этого статического свойства, но уже не статическое и не рид-онли. Но мне ещё надо, чтобы каждый экземпляр Profile имел только одну копию DefaultProfiles. Попытался сделать так




но ещё не проверял. Как считаете, будет работать? Тут расчёт на то, что копия DefaultProfiles будет создаваться только при сериализации, поэтому просто экземпляры Profile иметь каждый свою копию DefaultProfiles не будут, а будут ссылаться на один и тот же экземпляр. Верно я рассуждаю?

ЕвгенийВMineRunner,
Что в итоге хочешь получить то?
1. Хочу сериализовать DefaultProfiles.
2. Хочу получить в десериализованной копии такую же статическую штуку DefaultProfiles.
3. Хочу иметь только одну копию DefaultProfiles на все экземпляры Profile в пределах одного приложения. Т. е. после десериализации в, например, другом AppDomain, можно иметь другую копию DefaultProfiles.

Иммануил Кантсделай коллекцию синглтон
А у меня что?

Cat2Вообще не понимаю смысла серилизации, если только не работа череp WCF
Как раз работа через WCF. Я специально не конкретизирую, чтобы абстрагироваться.

Может, я туплю, но у меня такое ощущение, что я делаю что-то ненужное. Чтобы десериализовать объект в приложении А, это приложение А должно иметь ссылку на класс Profile, так? Тогда у него уже есть набор DefaultProfiles и при этом точно такой же, как и у того приложения Б, которое передаёт сериализованный объект приложению А, так? Т. е. сериализовать статическую константу DefaultProfiles в моём случае не нужно.

Вот если бы приложение А не имело ссылки на класс Profile и не знало бы о его внутренней структуре, а получало бы просто данные в том виде, в который я сериализую объекты (xml там, или json), то имело бы смысл создавать дублирующее свойство, которое бы превращало static readonly в какое-нибудь обычное свойство, которое можно сериализовать.

Правильно я рассуждаю?

MineRunnerВот если бы приложение А не имело ссылки на класс Profile и не знало бы о его внутренней структуре, а получало бы просто данные в том виде, в который я сериализую объекты (xml там, или json), то имело бы смысл создавать дублирующее свойство, которое бы превращало static readonly в какое-нибудь обычное свойство, которое можно сериализовать.

Правильно я рассуждаю?
Ну и вдобавок к этому, если я хочу, чтобы при добавлении DefaultProfilesToSerialize как дублирующего свойства для DefaultProfiles обычные инстансы класса Profile ссылались на ту же самую коллекцию дефолтных профайлов, то имеет смысл сделать свойство DefaultProfilesToSerialize без поля поддержки (backing field) - а просто чтобы это свойство возвращало ту же коллекцию DefaultProfiles.

Так?

Тогда мне надо переписать её без интерфейса - на конкретную коллекцию:

Я правильно всё сделал?

skyANAMineRunnerКак раз работа через WCF. Я специально не конкретизирую, чтобы абстрагироваться.
Конкретизируйте хотя бы во что сериализовать: Binary, JSON, SOAP, XML, ProtoBuf, в сообщение для какой-нибудь очереди?
А в чём будет принципиальное различие, если я для разных этих вещей сериализую?

Пусть будет сериализация XML. Забудьте про WCF (это я зря приплёл).

skyANAMineRunner, а что вообще такое DefaultProfiles и почему определено как статическое поле у Profile ?
Про профили я просто так придумал. Тут главное суть - есть некие дефолтные наборы настроек. Я запихал их в константную статику, по типу String.Empty.

Почему String.Empty находится в классе String? Потому что String.Empty связано с этим классом вне зависимости от контекста использования, поэтому в любом контексте, где используется String, должна быть возможность и использовать String.Empty. Поэтому удобно запихать String.Empty прямо в String. Вот по аналогии и я свои дефолтные профили запихал в класс профиля.

skyANAP.S.: ну и сеттер надо добавить для DefaultProfilesToSerialize. Потому как read only свойства не сериализуются.
Вот, это уже по существу советы.

1. Но, как я понял, и пояснил это тут , если надо потом сделать десериализацию в тот же класс Profile, то у приёмника сериализованного Profile должна быть ссылка на определение класса. А раз так, то DefaultProfiles он получает и так, без специальной сериализации/десериализации этого static readonly свойства. Так?

2. А вот если приёмник получает некий XML (JSON и т. д. по вкусу) и не собирается десериализовать его в объект Profile, то у этого приймника, скорее всего, нет ссылки на класс Profile и, соответственно, он не может получить набор DefaultProfiles в виде static readonly. Поэтому такому приёмнику надо специально сделать свойство в Profile, в котором можно разместить DefaultProfiles при сериализации. Так?

3. Но есть ещё требование, чтобы инстансы класса Profile не создавали каждый раз по копии DefaultProfiles.

Теперь как это всё реализовать? Вот вы сказали, нужно сеттер добавить. А что и куда он будет присваивать, с учётом вот этих моих трёх требований? Если бэкинг филд, то это копия DefaultProfiles на каждый инстанс Profile. Так?

Где-то в степину что вы будете делать со своей бедой в многопоточном исполнении, когда один поток работает с вашим листом
а другой поток в десериализаторе чистит лист и хуячит дуда профили с диска?
Ну и возникает вопрос - если кто - то снаружи имеет ссылку на профиль в листе а вы через десериализатор
расхуячили этот лист и запихнули туда левые профили, что делать этому бедному существу снаружи с его ссылкой?
Пишу в комментах к классу - потоконебезопасен.

Но вообще, всё проще - приложение один раз получает настройки и DefaultProfiles чисто для удобства - чтобы можно было выбрать готовые пресеты, а не прожимать кучу кнопок каждый раз. Смысла менять список профилей мало (юзер пока не может добавлять свои профили, а либо использует готовые, либо прожимает настройки каждый раз заново), а уж в многопотоке - вообще нет. Просто дефолтные профили покрывают почти все кейсы юзера и особого смысла менять их нет. Если поменяет, то не в самом списке DefaultProfiles, а только в некотором CurrentProfile, которым может быть один из первоначально выбранных DefaultProfiles. Как-то так.

Я ещё раз говорю, что специально абстрагируюсь от конкретного контекста, а стараюсь задать вопрос про некоторую сериализацию статика в вакууме.

Где-то в степиMineRunner,
ну допустим статик можно обойти через iserializable
ну допустим только чтение можно можно обойти через приватное прокси свойство в гетдатаобджект и конструкторе сериализации
ну предположим можно обмануть рекурсию

ну что вы будете делать со своей бедой в многопоточном исполнении, когда один поток работает с вашим листом
а другой поток в десериализаторе чистит лист и хуячит дуда профили с диска?
Ну и возникает вопрос - если кто - то снаружи имеет ссылку на профиль в листе а вы через десериализатор
расхуячили этот лист и запихнули туда левые профили, что делать этому бедному существу снаружи с его ссылкой?
С каким моим листом? Профили находятся где-то в приложении - например, в классе Настройки. Я показываю юзеру настройки, где выбран текущий профиль и есть набор профилей, который включает набор дефолтных профилей (грубо говоря, сначала идёт набор дефолтных, а нище - текущие юзерск ие или юзерск ий ). DefaultProfiles нужны просто для удобства, чтобы наполнить список профилей некоторыми заранее заданными профилями.

Если кто-то там в потоках "хуячит лист", то он это делает не с DefaultProfiles, а с неким листом в настройках.

Не знаю, как ещё сказать. Пусть будет так: Profile служит просто контейнером для набора DefaultProfiles, поскольку DefaultProfiles связаны с Profile по смыслу. Наподобие того, как я объяснил про String.Empty.

Но для полной красоты надо ещё сделать все профили в DefaultProfiles readonly, чтобы их нельзя было менять в самом списке DefaultProfiles. Как, кстати, это можно сделать?

MineRunnerНо для полной красоты надо ещё сделать все профили в DefaultProfiles readonly, чтобы их нельзя было менять в самом списке DefaultProfiles. Как, кстати, это можно сделать?
Наверное, закрыть DefaultProfiles и сделать публичный метод - GetDefaultProfiles, так?

MineRunnerMineRunnerНо для полной красоты надо ещё сделать все профили в DefaultProfiles readonly, чтобы их нельзя было менять в самом списке DefaultProfiles. Как, кстати, это можно сделать?
Наверное, закрыть DefaultProfiles и сделать публичный метод - GetDefaultProfiles, так?
Который будет каждый раз возвращать копию DefaultProfiles с копированными же объектами Profile в нём. Так?

MineRunnerMineRunnerпропущено...

Наверное, закрыть DefaultProfiles и сделать публичный метод - GetDefaultProfiles, так?
Который будет каждый раз возвращать копию DefaultProfiles с копированными же объектами Profile в нём. Так?
Во! А чтобы не мучаться с копированием дефолтных профилей каждый раз при запросе GetDefaultProfiles, то лучше вообще создавать дефолтные профили прямо в этом методе - тогда он каждый раз будет возвращать профили с одними и теми же свойствами.

Получается, вариант со static readonly DefaultProfiles плохой и лучше перейти на метод GetDefaultProfiles. Так?

MineRunnerMineRunnerпропущено...

Который будет каждый раз возвращать копию DefaultProfiles с копированными же объектами Profile в нём. Так?
Во! А чтобы не мучаться с копированием дефолтных профилей каждый раз при запросе GetDefaultProfiles, то лучше вообще создавать дефолтные профили прямо в этом методе - тогда он каждый раз будет возвращать профили с одними и теми же свойствами.

Получается, вариант со static readonly DefaultProfiles плохой и лучше перейти на метод GetDefaultProfiles. Так?
Это называется, кажется, фабрика, да?