1. FrxCOM живет в однопоточной комнате, поэтому сложно сформировать отчет на сервере для публикации (сложность реализации устойчивой работы в 3х уровневой архитектуре превысила разумные пределы)
Насчёт однопоточной комнаты я с Вами согласен и в то же время готов поспорить.
Почему согласен? Да потому что текущая версия студии действительно однопоточная. Думаю что не открою коммерческих и технологических секретов, если скажу что пока выполняется подготовка отчёта в одной "комнате", подготовка в другой блокирована. Это недостаток студии, решение которого сейчас обсуждается. Думается, он будет исправлен к выходу релиза.
А теперь, почему готов поспорить. В подавляющем большинстве случаев, при правильной реализации клиента, single thread appartment достаточен для реализации 3-х уровневой архитектуры. Я исхожу из приниципа:
один клиентский поток - один объект отчёта. И это ни в коей мере не противоречит single thread apartment. Более того, внутри apartment они исполняются параллельно.
Вы можете привести примеры, когда необходимо обащаться к объекту из разных потоков? Примеры именно для 3-х уровневой архитектуры.
Связи между таблицами в .NET организуются на уровне DataSet.
Поддержка .NET DataSet сейчас в стадии разработки.
Что касается DataTable:
Studio\Demo\VisualC#.NET\DataSetDemo\FrxDataTable.cs
"
5. доступ к данным (oledb, odbc и пр.) прям из генератора
(то, что всегда было интересным в fr2, fr3...)
Будет. Однозначно будет. Причём, мы вынесем текущий ADO движок и сделаем движки подключаемыми. Вопрос только в том, сколько это займёт времени и появится ли в релизе Студии.
Вы можете привести примеры, когда необходимо обащаться к объекту из разных потоков? Примеры именно для 3-х уровневой архитектуры.
Пример: В центр приходят данные с филиалов и по мере поступления автоматом производится формирование отчета на сервере, а на филиал отправляется сформированный отчет. Необходимо ждать, пока FR освободится, если он уже занят. Конечно, возможно запускать несколько экземпляров серверов приложений, но, увы, эта задача тоже не тривиальная.
Пример: В центр приходят данные с филиалов и по мере поступления автоматом производится формирование отчета на сервере, а на филиал отправляется сформированный отчет. Необходимо ждать, пока FR освободится, если он уже занят. Конечно, возможно запускать несколько экземпляров серверов приложений, но, увы, эта задача тоже не тривиальная.
Single apartment threading model вполне укладывается в приведённый пример, если каждый запрос исполняется в одном потоке. Главное чтобы к каждой копии объекта не было обращения из нескольких потоков.
Насчёт некорректно организованной одноквартирной модели в Студии я уже признался - сейчас несколько запросов на PrepareReport блокируются криическими секциями и обслуживаются в порядке поступления. Мы ищем пути распараллеливания обработки отчётов.
Пример: В центр приходят данные с филиалов и по мере поступления автоматом производится формирование отчета на сервере, а на филиал отправляется сформированный отчет. Необходимо ждать, пока FR освободится, если он уже занят. Конечно, возможно запускать несколько экземпляров серверов приложений, но, увы, эта задача тоже не тривиальная.
В процессе решения. Сейчас все силы брошены на мультипочность.
Рвите smile.gif FR3 - не только для .NET. Очень многие сидят на MSVC 6 и на net плевать хотели...
>>Вы хоть поняли, как построен StimulReport?!
дайте исходники - посмотрим, и может быть, поймем...
Полностью поддерживаю данное высказывание Александра. Далеко не все нужен .NET вкупе с его студией.
Например мне он не нужен и врядли будет нужен в ближайшие 5-10 лет, ибо не вижу я в нем каких то преимуществ перед той же D7 (Win32) в плане написания обычных БД-ориентированных приложений.
А вот тормозов и сложности установки на комп, использование .NET очень даже добавит.
Мое предвзятое мнение - цена совершенно адекватная (когда выдет релиз) , к сожалению продукт сыроват и продовать его рановато (кол-во релизов в неделю не гоорит о качестве .
Ну и шорох поднялся Сразу начали сильно думать, приляпывать интерфейсы, потоки и делать приличную заточку под .NET. Дело, конечно, хозяйское. Но, по-моему, бесперспективное из-за экспоненциально растущей сложности продукта => цены => затруднительной поддержки. Да не бойтесь вы цацку из рук выпустить! Никуда она не денется. FR3 есть - и будет есть.
Взяли бы за основу .NET 2.0, спроектировали продукт исходя из опыта, наработок FR, возможностей Stimul, требуемого и планируемого функционала, массы готового кода (взять хоть SharpDevelop) и не в напряг поручили б какому-нибудь талантливому бойцу из вашей команды заняться реализацией банально "в одну харю". К весне ФР-студия отсохла бы к чертям! А потом - и нативный (слово уже опротивело) FR3.
.NET стал основным API windows. Ну чего упираться рогами, плевать против ветра. MS сказал. MS сделал. Сделал такое предложение, от которого трудно отказаться. Еще год - и все дружненько нагнутся под .NET. О Delpfi уже говорили. .NET-сборки уже становятся ее родными.
..и пришел бы FR.INC, и сказал бы всем: "Нате вам!". И все бы взяли.. и закурили
Поддерживаю точку зрения Lav. Хочу только заметить, что создание отчетности посложнеее, чем кажется (в т.ч. на .Net), и прав Александр, в одном из топиков не рекомендовавший заниматься созданием такого продукта.
Microsoft до сих пор такого продукта не выпустила в свет. В ее Reporting Services используется COM так же, как и в FR.Studio. Я сейчас оцениваю ресурсы на создание нетовской отчетности 30-50 человеко-годов. Когда выпускники вузов будут достаточно подготовленны для работы с .Net, ресурсы сократятся в 3-5 раз. Предполагаю, это время наступит через 3 года.
Взяли бы за основу .NET 2.0, спроектировали продукт исходя из опыта, наработок FR
Кстати, вопрос. А почему Вы уверены что компания FR не ведёт проектирование ?!
У Вас есть инсайдерская информация?
Давайте не будем трясти рынок непровернными заявлениями?
Наработки FastReport .NET существуют и начаты они задолго до появления Студии. Анализ рынка показал, что наиболее благоприятно этот проект временно заморозить и воспользоваться временем для развития FastReport v3.
Тем не менее, мысли о .NET версии не покидали и не покидают разработчиков.
Расссматриваются разные варианты, анализуруются решения. Эта работа не видна нашим коллегам, но она идёт. Некоторые решения мы обкатываем на Студии. (естевенно, ровно до тех пор, пока из названия Студии не исчезнет слово Beta).
Насчёт талантливого бойца, извините, комментировать не буду - такой объём работ одиночке не под силу.
Комментарии
Насчёт однопоточной комнаты я с Вами согласен и в то же время готов поспорить.
Почему согласен? Да потому что текущая версия студии действительно однопоточная. Думаю что не открою коммерческих и технологических секретов, если скажу что пока выполняется подготовка отчёта в одной "комнате", подготовка в другой блокирована. Это недостаток студии, решение которого сейчас обсуждается. Думается, он будет исправлен к выходу релиза.
А теперь, почему готов поспорить. В подавляющем большинстве случаев, при правильной реализации клиента, single thread appartment достаточен для реализации 3-х уровневой архитектуры. Я исхожу из приниципа:
один клиентский поток - один объект отчёта. И это ни в коей мере не противоречит single thread apartment. Более того, внутри apartment они исполняются параллельно.
Вы можете привести примеры, когда необходимо обащаться к объекту из разных потоков? Примеры именно для 3-х уровневой архитектуры.
Пока не может быть встроен. Надеюсь, это произойдёт без полного переписывания продукта. А то, что это произойдёт, можете не сомневаться.
Связи между таблицами в .NET организуются на уровне DataSet.
Поддержка .NET DataSet сейчас в стадии разработки.
Что касается DataTable:
Studio\Demo\VisualC#.NET\DataSetDemo\FrxDataTable.cs
Вскоре, как будет востребовано покупателями.
Неправда Ваша - не далее как вчера появился:
Studio\Demo\VisualC#.NET\DataSetDemo\FrxDataView.cs
Мы задумываемся об этом.
Поддержка xml datasources, как и .NET DataSet, сейчас в стадии разработки.
Будет. Однозначно будет. Причём, мы вынесем текущий ADO движок и сделаем движки подключаемыми. Вопрос только в том, сколько это займёт времени и появится ли в релизе Студии.
в сфере вышесказаного г-ном alman (увы, не знаю имени), все сводится к фразам "скоро, может быть, будет", "скоро будет", "должно быть"...
получается, что сейчас стоимость запредельно завышена.
вы должны доплачивать людям, которые хотят пробовать.
Насчёт некорректно организованной одноквартирной модели в Студии я уже признался - сейчас несколько запросов на PrepareReport блокируются криическими секциями и обслуживаются в порядке поступления. Мы ищем пути распараллеливания обработки отчётов.
Причем качество поддержки оставляет желать лучшего....
Например, топики остались вообще без внимания:
http://www.fast-report.com/en/forum/?p=/discussion/2153
http://www.fast-report.com/en/forum/?p=/discussion/2320
Да ладно эти топики, тут ссылка о поиске порносайтов висела на виду
довольно долго... а плякаль....
Так что делайте выводы господа потребители....
"К сожалению, мы не гарантируем поддержки на форуме. Мы позиционируем форум для общения наших покупателей и коллег. "
Вы знаете, я тоже плакал. Потому что пропустил такое занимательное
зрелище. Вывод: "Форум не гарантирует технической поддержки, но есть вероятность её получить от коллег. Поддержку гарантирует support@fast-report.com"
Полностью поддерживаю данное высказывание Александра. Далеко не все нужен .NET вкупе с его студией.
Например мне он не нужен и врядли будет нужен в ближайшие 5-10 лет, ибо не вижу я в нем каких то преимуществ перед той же D7 (Win32) в плане написания обычных БД-ориентированных приложений.
А вот тормозов и сложности установки на комп, использование .NET очень даже добавит.
Взяли бы за основу .NET 2.0, спроектировали продукт исходя из опыта, наработок FR, возможностей Stimul, требуемого и планируемого функционала, массы готового кода (взять хоть SharpDevelop) и не в напряг поручили б какому-нибудь талантливому бойцу из вашей команды заняться реализацией банально "в одну харю". К весне ФР-студия отсохла бы к чертям! А потом - и нативный (слово уже опротивело) FR3.
.NET стал основным API windows. Ну чего упираться рогами, плевать против ветра. MS сказал. MS сделал. Сделал такое предложение, от которого трудно отказаться. Еще год - и все дружненько нагнутся под .NET. О Delpfi уже говорили. .NET-сборки уже становятся ее родными.
..и пришел бы FR.INC, и сказал бы всем: "Нате вам!". И все бы взяли.. и закурили
Microsoft до сих пор такого продукта не выпустила в свет. В ее Reporting Services используется COM так же, как и в FR.Studio. Я сейчас оцениваю ресурсы на создание нетовской отчетности 30-50 человеко-годов. Когда выпускники вузов будут достаточно подготовленны для работы с .Net, ресурсы сократятся в 3-5 раз. Предполагаю, это время наступит через 3 года.
По идее, PrepareReport уже может выполняться параллельно для разных объектов в разных потоках.
У Вас есть инсайдерская информация?
Давайте не будем трясти рынок непровернными заявлениями?
Наработки FastReport .NET существуют и начаты они задолго до появления Студии. Анализ рынка показал, что наиболее благоприятно этот проект временно заморозить и воспользоваться временем для развития FastReport v3.
Тем не менее, мысли о .NET версии не покидали и не покидают разработчиков.
Расссматриваются разные варианты, анализуруются решения. Эта работа не видна нашим коллегам, но она идёт. Некоторые решения мы обкатываем на Студии. (естевенно, ровно до тех пор, пока из названия Студии не исчезнет слово Beta).
Насчёт талантливого бойца, извините, комментировать не буду - такой объём работ одиночке не под силу.