Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[13.58.252.8] |
|
Страницы: (3) 1 [2] 3 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
ИМХО, замени консоль хост на виндовский сервис. У сервиса есть очень хороший метод OnStop. Вот в нем сериализовать будет удобно.
|
Сообщ.
#17
,
|
|
|
MIF с учетом выше озвученных вопросов ему очень сложно будет такое дело отладит, и если честно то я болше склоняюсь к версии что сохранение пользователей надо выносить в логическую процедуру и делать это отдельно, и никак не при dispose обьекта
|
Сообщ.
#18
,
|
|
|
ТС нам не всё сказал, посему приходится гадать. Я лично понял что лист пользователей хранится в статической (static) переменной.
|
Сообщ.
#19
,
|
|
|
Таки не буду менять консоль на виндовсовский сервис, ибо
Цитата Pit-Bul @ очень сложно будет такое дело отладит Цитата Pit-Bul @ сохранение пользователей надо выносить в логическую процедуру Имхо, сохранять надо именно по завершению работы консольной программы-хоста (а соответственно и сервиса). Чтобы при следующем запуске сервис загрузил список пользователей из xml файла и спокойно продолжил работать (иначе после перезапуска сервиса всем пользователям придеться заново регистрироваться) Цитата MIF @ Я лично понял что лист пользователей хранится в статической (static) переменной. Как-то незачем делать статик, если у меня InstanceContextMode=InstanceContextMode.Single (т.е. один экземпляр сервиса на всех). |
Сообщ.
#20
,
|
|
|
GoldenJoe, что в сериализованном xml планируется хранить?
|
Сообщ.
#21
,
|
|
|
Spawn.NET
Я же говорил уже. Класс User описывает пользователя сервиса (как минимум логин и пароль). В xml буду хранить List<User>. |
Сообщ.
#22
,
|
|
|
Почему не сохранять информацию по мере изменения объектов в программе? Что будет, если машину с сервисом просто обесточат, изменения потеряются?
|
Сообщ.
#23
,
|
|
|
Цитата Raino @ Почему не сохранять информацию по мере изменения объектов в программе? Что будет, если машину с сервисом просто обесточат, изменения потеряются? GoldenJoe, сохраняй при входе, коль уж это не логи всей работы. |
Сообщ.
#24
,
|
|
|
Raino, Spawn.NET
Ага, это еще и надежнее. Наверное, так и сделаю. А возможно ли не сериализовывать весь список заново, например, из-за 1 пользователя? (т.е. сохранить изменения, не выполняя повторную сериализацию всего списка) |
Сообщ.
#25
,
|
|
|
Цитата GoldenJoe @ Имхо, сохранять надо именно по завершению работы консольной программы-хоста (а соответственно и сервиса). Чтобы при следующем запуске сервис загрузил список пользователей из xml файла и спокойно продолжил работать (иначе после перезапуска сервиса всем пользователям придеться заново регистрироваться) вот как раз то что рвало мой мозг , как сказал бы мой шеф "двоечник, тащи ремень, пороть будем" Во первых, создание списка пользователей динамически уже бред. Во вторых что значит Цитата GoldenJoe @ иначе после перезапуска сервиса всем пользователям придется заново регистрироваться вообще то пользователь авторизуется при каждом обращении к сервису с предоставлением учетных данных. То есть при первом запуске приложения пользователь в клиентском приложении вводит логин/пароль, клиентское приложение отправляет эту пару сервису и при удачной авторизации возвращает учетные данные клиента, которые далее клиент при каждом обращении к сервису обязан предоставить. Следовательно получаем, есть статический список пользователей, например в базе, в XML хоть просто в текстовом файлике из которого сервис при первой авторизации получает данные и отдает их клиенту. Теперь касаемо управления пользователями, то есть добавление/удаление, изменение данных и прав - это обязанность либо отдельной программки, либо части клиентского приложения доступного опять же определенным учетным записям, выбирай сам. Вот примерно вот так ЗЫ: еще покури на тему System.Security и System.IdentityModel.Policy, WCF поддерживает аутентификацию на основе пользовательских и доменных политик |
Сообщ.
#26
,
|
|
|
Цитата GoldenJoe @ (т.е. сохранить изменения, не выполняя повторную сериализацию всего списка) Сам на свой вопрос отвечаешь. Вручную дописать изменения, значит открыть файл, внести изменения, сохранить, закрыть... Проще сериализовать |
Сообщ.
#27
,
|
|
|
Т.е. тут без вариантов - заново сериализовать весь список, так?
|
Сообщ.
#28
,
|
|
|
Ну, можешь, только нужный node исправлять, но это уже вручную.
|
Сообщ.
#29
,
|
|
|
Цитата GoldenJoe @ Pit-Bul, работает. Но Dispose вызывается каждый раз, когда отключается один из клиентов. Мне это не нужно, по этому ставлю InstanceContextMode=InstanceContextMode.Single (чтобы для каждого клиента не создавался отдельный экземпляр службы). Теперь Dispose вообще не вызывается, даже при закрытии окна консоли. WcfService _service = null; .... using(_service = new WcfService(Uri)) { _service.Open(); .... Console.ReadLine(); //просто для демонстрации :) _service.Close(); } //После выхода из using будет вызван Dispose() для _service; Так-же можно подписаться на события закрытия и вызывать Dispose. Метод Dispose не вызывается сервисом WCF т.к. для него не очевидно, что это необходимость делать. И сей момент переложен на плечи внешнего кода. Добавлено Цитата А возможно ли не сериализовывать весь список заново, например, из-за 1 пользователя? (т.е. сохранить изменения, не выполняя повторную сериализацию всего списка) Зачем при каждом входе то?? Если пользователей станет много, то сервис только сериализацией и будет заниматься... Создай подсистему активных пользователей и запусти поток, пусть с определенным интервалом смотрит на активных пользователей, кто долго неактивен, логаути и сохраняй. |
Сообщ.
#30
,
|
|
|
Цитата Pit-Bul @ WCF поддерживает аутентификацию на основе пользовательских и доменных политик Почитал. Может, стоит перейти со своего велосипеда: public interface IService { [OperationContract] bool Register(string userName, string password); // Регистрация нового пользователя. Аналогично регистрации на каком-нибудь сайте. // На данный момент выполняю сериализацию списка пользователей в методе Register. // Можно и в Dispose. Но! (см. далее) [OperationContract] bool LogOn(string userName, string password); // Войти [OperationContract] bool LogOff(); // Выйти } на это? <serviceCredentials> <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="CustomUserNameValidator, MyService" /> </serviceCredentials> Цитата maxim84_ @ После выхода из using будет вызван Dispose() для _service; Все правильно, если закрывать программу-хост нажатием <enter> (Console.ReadLine() ведь). А если "крестиком" - не вызывается. Инфа 100% - ставил breakpoint и проверял. Сейчас кто-нибудь ответит "закрывай enter'ом и не парься". Но все-таки интересно, почему Dispose не вызывается, если закрывать "крестом". Если решить эту проблему, можно, в принципе, выполнять сериализацию в Dispose, а не в Register. Преимущество - сериализация списка пользователей выполняется всего 1 раз - при закрытии программы-хоста (Кэп намекает, что если делать это в методе Register, сериализация будет выполняться каждый раз, когда регистрируется новый пользователь. "Если пользователей станет много, то сервис только сериализацией и будет заниматься..." - как-то так.). И недостаток сериализации в Dispose - потеря данных в случаи отключения питания компьютера, на котором запущен сервис. Так что либо большая нагрузка на сервис (сериализация в Register) либо возможность потерять данные (сериализация в Dispose). Наверное, лучше 1 вариант. |