Знаете поговорку "кто не умеет работать, тот идет руководить..." ?
по сути вопроса, нет никакого смысла приводить объект к базовому типу, если вы вначале его создали, и после этого вызываете его методы. пример в видео высосан из пальца, в реальных проектах так никто не делает.
Если есть некоторое рабочее решение для подобной ситуации, то интеграция это вопрос технический и совместимость из коробки не столь важна. Можете дать ссылки на движки?
Вы верно озвучили мои опасения, но хочется как то продвинуться в этом направлении. Про репортер для базы я прокомментировал в другом ответе, думаю что это очень опасное решение.
Может быть, но появляется много вопросов: Осиливают ли его пользователи? Как продукт переживает тот факт, что модель данных не может просто взять и измениться? Мне интересен именно чужой опыт по схожей проблеме: внедрили такое-то решение, возникли такие-то проблемы, которые успешно решили или не решили, но назад не пойдем, потому что это все равно лучше чем было.
Нет, отчеты разные, в них достаточно много пересекающихся данных и они мутируют со временем. К сожалению, наймом проблема не решается, нет такого стабильного потока отчетов и очень сложная область, т.е. чтобы новый человек смог сделать сам пару месяцев вникать надо.
Если задается такой вопрос то нет никакого практического смысла запускать профайлер. Вы сможете долго разглядывать результаты его работы, но ответов на свои вопросы вы там не увидите. Профайлер это не волшебная коробка, которая скажет что у вас не так. Прежде чем его запускать надо четко понимать что вы ищите. Проблема у вас в архитектуре, как уже указано в первом комменте, вам необходимо ревьюить код. В качестве отправной точки могу предложить проверку того что любая существенная деятельность выполняется НЕ в гуишном потоке. То что вы визуализируете может оказаться слишком тяжелым для визуализации и причина в WPF. Возможно причина в GC. Итого: если вы этого еще не сделали, то начинайте читать статьи по написанию производительного .net кода.
Я не очень понимаю суть нашего диалога. Вам удалось понять реализацию множественной диспетчеризации на основе визитера в упомянутой статье? Вы можете привести пример клиентского кода который решает указанную постановку?
У меня с мыслями вроде бы все в порядке, здесь речь о конкретном решении, которое я либо не понял либо это вовсе не решение либо это решение какого то другого вопроса
Спасибо за ответ, хочу уточнить.
Я правильно понимаю, что загрузка js умеющего себя отображать реализуется только через ajax и eval(загруженный с сервера код) ?
Тяжесть фреймворка даже для одной страницы скорее не проблема, если это позволит иметь более структурированный и поддерживаемый код. Это внутреннее приложение и трафик никто не считает. А вот требования к знанию js это уже более серьезное препятствие. Вы могли бы схематично описать каким образом указанные фреймворки позволяют реализовывать динамическую загрузку элементов? Просто чтобы примерно оценить сложность/удобство решения.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
по сути вопроса, нет никакого смысла приводить объект к базовому типу, если вы вначале его создали, и после этого вызываете его методы. пример в видео высосан из пальца, в реальных проектах так никто не делает.