Здравствуйте, gandjustas, Вы писали:
G>>>>>Наверное при нажатии save, но в таком случае и передавать на сервер не надо. O>>>> Как не надо? А как об изменении смогут узнать другие клиенты? G>>>Сам же написал что без обратной связи. Тогда зачем до save куда-то что-то передавать? O>> Обратная связь — это когда сервер уведомляет клиентов об изменении. А когда с клиента на сервер передавать — сразу или при нажатии на сейв — это не обратная связь. G>Это я понял, я не понял зачем передавать что-то на сервер до нажатия save без обратной связи.
Логическая цепочка этого обсуждения мной уже потеряна. Изначально я предлагал как альтернативу кнопке save сразу отсылать на сервер изменения, но это уже в прошлом.
O>> Почему не работает? У же который раз пишут, что может не работать, однако я не представляю как это возможно в случае наличия версии в каждой сущности и транзакционной БД. G>Сценарий. G>Для корректного обновления X надо прочитать из Y, выполнить запрос на внешний сервис с данными из Y, записать результат в X. G>Один клиент читает Y, начинает выполнять запрос, в этот момент другой клиент меняет Y. Так как первый клиент Y не менял, то конфликт версий при сохранении даже не будет проверяться, тем не менее данные будут несогласованы.
Видимо, придется лочить дерево зависимых объектов, как уже упомянал meowth.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[3]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, VPVinnitsky, Вы писали:
VPV>.Net Remoting например, на сервероном стабе можно организовать отслеживание изменений. там же в ремоутинге есть сервис управления жизнью объекта.
Ох сколько подводных камней этот путь таит, лучше даже не считать.
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.
Да нет, мы в фаре смотрим, анхендлед экзкпшены сервера по почте шлются.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[10]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>Я даже не смоневаюсь что переделка rich в anemic даст такой эффект. G>Это примерно как попробовать переделать OO-программу в функциональную.
На этой оптимистичной ноте предлагаю закрыть дискуссию, полезных знаний мне она точно не приносит, тебе как я вижу тоже. Предлагаю считать, что я плохо справляюсь с недостатками анемик модели, а ты рич.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O> Видимо, придется лочить дерево зависимых объектов, как уже упомянал meowth.
Это уже будет пессимистичная блокировка.
Re[10]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ziaw, Вы писали:
O>> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано. Z>Да нет, мы в фаре смотрим, анхендлед экзкпшены сервера по почте шлются.
Шлются непосредственно из приложения при отлове такого экзкпшена или отдельное приложение мониторит лог и шлет? Мне это не принципиально, однако для себя вижу бОльшую надежность в отдельном мониторе.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[11]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ocenochka, Вы писали:
O> Шлются непосредственно из приложения при отлове такого экзкпшена или отдельное приложение мониторит лог и шлет? Мне это не принципиально, однако для себя вижу бОльшую надежность в отдельном мониторе.
Здравствуйте, Ziaw, Вы писали:
O>> Шлются непосредственно из приложения при отлове такого экзкпшена или отдельное приложение мониторит лог и шлет? Мне это не принципиально, однако для себя вижу бОльшую надежность в отдельном мониторе. Z>SmtpAppender Z>log4net Config Examples
Спасибо, запомню на будующее. А не подскажете, что произойдет, если в момент исключения почтовый сервер или транспорт будут не доступны? Отправится ли исключение позже или потеряется?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Ocenochka, Вы писали:
O>Здравствуйте, Ziaw, Вы писали:
O> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано.
Можно смотреть логи в Apache Chainsaw. Для более детального просмотра, конечно, стоит написать свой тул.
Re[8]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, gandjustas, Вы писали:
G>Есть sync framework, который все сам делает. А лучше кеша потому что всетаки РСУБД, а не коллекция объектов в памяти. G>Но если актуальность информации важна, то лучше локальным кешированием оперативных данных не заниматься. Только справочники.
По-моему, вы напрасно впариваете тут Синк Фреймворк. Не тот сценарий, не та задача -- имхо не надо клиент-сервер превращать в распределенную БД. То что Синк умеет делать репликации, это очень хорошо, но здесь это не надо, судя по постановке задачи.
Re[10]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
O>> Нет нет, логи устраивают, просто хотелось узнать может это еще как-то сделать можно... А вспомогательные инструменты для работы с логом есть или просто через "блокнот" просмативаются при помощи поиска по id интересующего объекта? Просто мне кажется, что можно было бы навернуть небольшое преложение для просмотра логов, которое знает немного о бизнес-логике, чтобы наглядней отображать сразу логические последовательности работы с интересующими объетами или как-то так... в общем, просто интересно было как у вас сделано. M>Можно смотреть логи в Apache Chainsaw. Для более детального просмотра, конечно, стоит написать свой тул.
Ясно, спасибо за общение, очень понравилось!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[11]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ocenochka, Вы писали: O> Ясно, спасибо за общение, очень понравилось!
Не за что. Спрашивайте, может, и помогу чем, если знаю и буду тут.
Я бы вам еще порекомендовал на эту тему с Mike Chaliy пообщатьсо. Правда, имхо они куда-то далеко утопали, Fluent NHibernate + не знаю, юзают ли Spring.NET; но он конкретный практик, и много интересного рассказывает из своего опыта.
Re[12]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Не за что. Спрашивайте, может, и помогу чем, если знаю и буду тут. M>Я бы вам еще порекомендовал на эту тему с Mike Chaliy пообщатьсо. Правда, имхо они куда-то далеко утопали, Fluent NHibernate + не знаю, юзают ли Spring.NET; но он конкретный практик, и много интересного рассказывает из своего опыта.
Еще раз спасибо!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Люблю ставить оценки.
Re[13]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ocenochka, Вы писали:
O> Спасибо, запомню на будующее. А не подскажете, что произойдет, если в момент исключения почтовый сервер или транспорт будут не доступны? Отправится ли исключение позже или потеряется?
Афайк потеряется, это очень простой аппендер, который держит последние n эвентов в циклическом буфере и сбрасывает их по триггеру в email.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Есть sync framework, который все сам делает. А лучше кеша потому что всетаки РСУБД, а не коллекция объектов в памяти. G>>Но если актуальность информации важна, то лучше локальным кешированием оперативных данных не заниматься. Только справочники.
M>По-моему, вы напрасно впариваете тут Синк Фреймворк. Не тот сценарий, не та задача -- имхо не надо клиент-сервер превращать в распределенную БД. То что Синк умеет делать репликации, это очень хорошо, но здесь это не надо, судя по постановке задачи.
Трехзвенка с толстым клиентом — это практически единственный случай, когда имеет смысл делать локальную реплику. Поэтому и предлагаю такой подход.
Уж точно не пытаюсь впарить его. Впарить пытаюсть ADO.NET Data Services.
Re[10]: Архитектура приложения с несколькими клиентами и одн
G>Трехзвенка с толстым клиентом — это практически единственный случай, когда имеет смысл делать локальную реплику. Поэтому и предлагаю такой подход. G>Уж точно не пытаюсь впарить его. Впарить пытаюсть ADO.NET Data Services.
Тогда, если вы имели в виду толстый клиент с репликой, как сюда укладывается вот это ваше раннее заявление в начале треда: G>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
По-моему, совсем наоборот: при наличии локальной реплики тонкая модель не нужна, потому что все объекты находятся в одном физическом пространстве -- в UI можно подавать domain и/или presentation объекты, проблема SRP решается прямыми руками архитектора.
Соответственно, преимущество тонкой модели выступать в роли DTO здесь совершенно не нужно. Зато код из-за нее не сильно отличается от манипуляций с типизированными датасетами -- шумный, полный деталей реализации и нифига не предметной области. Выше Mike Chaliy привел пример.
Хотел еще сказать, топикстартер уже выяснил, что у него будет 2х-звенка с толстым клиентом.
Re[11]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Трехзвенка с толстым клиентом — это практически единственный случай, когда имеет смысл делать локальную реплику. Поэтому и предлагаю такой подход. G>>Уж точно не пытаюсь впарить его. Впарить пытаюсть ADO.NET Data Services.
M>Тогда, если вы имели в виду толстый клиент с репликой, как сюда укладывается вот это ваше раннее заявление в начале треда: G>>Общая проблема состоит в том, что жирная модель (она же domain model) в многозвенном приложении сосет как пылесос.
M>По-моему, совсем наоборот: при наличии локальной реплики тонкая модель не нужна, потому что все объекты находятся в одном физическом пространстве -- в UI можно подавать domain и/или presentation объекты, проблема SRP решается прямыми руками архитектора.
Я говорил про модель на сервере.
M>Соответственно, преимущество тонкой модели выступать в роли DTO здесь совершенно не нужно. Зато код из-за нее не сильно отличается от манипуляций с типизированными датасетами -- шумный, полный деталей реализации и нифига не предметной области. Выше Mike Chaliy привел пример.
Бредовый пример.
M>Хотел еще сказать, топикстартер уже выяснил, что у него будет 2х-звенка с толстым клиентом.
Это как? Двузвенка — практически база + клиент. На базе конечно можно навернуть логику, но не очень хорошо получится. Поэтому в двузвенке понятие "толщины" клиента обычно отсусвтвует.
Re[12]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>Я говорил про модель на сервере.
Тем не менее, при наличии SyncFramework, как вы предложили, объекты никуда гонять не надо, следовательно, rich model отлично подходит. Не понимаю, почему она — "сосет как пылесос" в таком случае.
M>>Хотел еще сказать, топикстартер уже выяснил, что у него будет 2х-звенка с толстым клиентом. G>Это как? Двузвенка — практически база + клиент. На базе конечно можно навернуть логику, но не очень хорошо получится. Поэтому в двузвенке понятие "толщины" клиента обычно отсусвтвует.
Да, клиент однозначно "очень толстый"
M>>Соответственно, преимущество тонкой модели выступать в роли DTO здесь совершенно не нужно. Зато код из-за нее не сильно отличается от манипуляций с типизированными датасетами -- шумный, полный деталей реализации и нифига не предметной области. Выше Mike Chaliy привел пример. G>Бредовый пример.
Боюсь, что не вам решать. Специфику пример отражает отлично.
Re[13]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Я говорил про модель на сервере. M>Тем не менее, при наличии SyncFramework, как вы предложили, объекты никуда гонять не надо, следовательно, rich model отлично подходит. Не понимаю, почему она — "сосет как пылесос" в таком случае.
"объекты никуда гонять не надо" — единственный критерий чтоли?
Re[14]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, meowth, Вы писали:
M>>Здравствуйте, gandjustas, Вы писали:
G>>>Я говорил про модель на сервере. M>>Тем не менее, при наличии SyncFramework, как вы предложили, объекты никуда гонять не надо, следовательно, rich model отлично подходит. Не понимаю, почему она — "сосет как пылесос" в таком случае. G>"объекты никуда гонять не надо" — единственный критерий чтоли?
Нет, но вы на больше и не указывали в этом треде.
Эм, а почему вы отвечаете вопросом на вопрос? Я у вас уже 4м комментом пытаюсь спросить, почему rich model плоха в условиях, если есть Sync Framework, как вы предлагаете взять. А если не предлагаете, выяснив, что клиент 2хзвенный, то вопрос никуда не девается -- почему в 2хзвенке rich model плоха; предметно ответьте? Только не надо про SRP.
