НА>Еще смущает Workflow Foundation — к месту ли его воткнул..
В agile development есть принцип: презумпция ненужности технологии или инструмента: "Не используйте технологию (или инструмент) пока необходимость в ней не будет доказана". Иными словами Вы должны вырасти из тех технологий и инструментов, необходимость использования которых очевидна на данном этапе развития проекта, чтобы использовать более сложные технологии.
Часто совершается ошибка, архитекторы руководствуются презумпцией нужности технологии: "Любую навороченную технологию нужно использование, если её ненужность не доказана".
Я думаю в первой версии приложения можно обойтись без WWF. В последующих версиях, в качестве развития можно внедрить WWF. После промышленного опыта использования первой версии у Вас появятся пожелания заказчика, для реализации которых возможно потребуется WWF, а может и не потребуется.
НА>Это ограничение есть. Но мы не хотим ограничивать мобильность наших клиентов (особенно випов)
Чем WPF xbap ограничивает мобильность клиентов? Для конечного пользователя WPF xbap выглядит и работает также как обычное Web приложение. Причем можно даже реализовать offline режим при отсутствии internet и с синхронизацией, когда internet появляется.
G>Интересно, а как в таком случае прийти к использованию IoC. Ведь все можно сделать и без него. Или AOP например. Ситуация такая будет для любой библиотеки. Ведь в самом начале она не нужна, а когда уже сделали и поняли что нужна — переделывать дорого.
Я понимаю о том что Вы говорите.
Спорный вопрос, что дороже:
внедрять понадобившуюся технологию в работающий продукт
или поддерживать не нужную технологию (или удалять её из готового продукта).
"А если не видно разницы зачем платить больше?".
Если все решения равноценны, то решающее играет система приоритетов. В agile на первом месте удовлетворение текущих потребностей заказчика.
G>В итоге весь проект — куча велосипедов. Явной необходимости ведь никогда нет, потому что все можно написать самим, а только потом понять что это велосипед.
Многое решает не теоретические размышления, а банальная квалификация и психология разработчиков. Грамотный разработчик должен уметь отличить преждевременную оптимизацию от действительно необходимого технического решения.
Преждевременной оптимизацией страдают разработчики с комплексом неполноценности. Предложениями использовать навороченные технологии они старается скрыть свою низкую квалификацию. Возможно квалификация даже высокая, но у них комплекс (страх), что низкая. Такие особенно опасны, так как своим авторитетом и знаниями могут "продавить" решение использовать ненужную технологию.
Здравствуйте, igor-booch, Вы писали:
НА>>Еще смущает Workflow Foundation — к месту ли его воткнул..
IB>В agile development есть принцип: презумпция ненужности технологии или инструмента: "Не используйте технологию (или инструмент) пока необходимость в ней не будет доказана". Иными словами Вы должны вырасти из тех технологий и инструментов, необходимость использования которых очевидна на данном этапе развития проекта, чтобы использовать более сложные технологии. IB>Часто совершается ошибка, архитекторы руководствуются презумпцией нужности технологии: "Любую навороченную технологию нужно использование, если её ненужность не доказана". IB>Я думаю в первой версии приложения можно обойтись без WWF. В последующих версиях, в качестве развития можно внедрить WWF. После промышленного опыта использования первой версии у Вас появятся пожелания заказчика, для реализации которых возможно потребуется WWF, а может и не потребуется.
Интересно, а как в таком случае прийти к использованию IoC. Ведь все можно сделать и без него. Или AOP например. Ситуация такая будет для любой библиотеки. Ведь в самом начале она не нужна, а когда уже сделали и поняли что нужна — переделывать дорого.
В итоге весь проект — куча велосипедов. Явной необходимости ведь никогда нет, потому что все можно написать самим, а только потом понять что это велосипед.
Задача.
Организация документооборота с клиентом с использованием ЭЦП.
По сути это будет обмен между клиентом и компанией документами в формате pdf.
На текущий момент клиентов около тысячи, активных 100-150 (нужен запас прочности на 10 кратное увиличение)
В среднем ежедневный документооборот по всем клиентам —
На стороне клиента следующий функционал
-посмотреть список определенного типа документов за определенный период
-посмотреть документ (загрузить pdf файл к себе)
-подписать документ
-проверить подпись сотрудника компании
-проверить состояние своих позиций
-и т.д.
На стороне менеджера компании
-сформировать документы для клиента
-подписать документы
-управлять доступом функционала клиента в зависимости от типа договоров
-контроль состояний клиента (по сути реакция на алерты от системы, возникающие в зависимости от событий)
В общих чертах нарисовалась следующая картина
Клиент — ASP.net приложение с устанавливаемым активиксом (будет использоваться для генерации ключей и локального подписания документов). Приложение хостится на сервере (IIS) смотрящим наружу
Менеджер — WPF приложение
И все они общаются с внутренним апликейшен сервером (IIS) посредством сервисов.
Здесь соотвественно работа с данными, логика, генерация алертов, проверка прав доступа и прочее. как то так
Покритикуйте, посоветуте.. Что то никак не сложится картинка (
Здравствуйте, igor-booch, Вы писали: IB>Если сделать ограничение, что клиенты должны использовать Windows (а не Linux например) IB>то лучше на клиентах использовать не ASP.NET, а WPF xbap.
Это ограничение есть. Но мы не хотим ограничивать мобильность наших клиентов (особенно випов)
По обычному логину паролю клиенту доступна просмотровая версия, т.е. даже при отсутствии ключа полезность приложения сохраняется. Клиентам это действительно нужно для мониторинга ситуации.
НА>Задача. НА>Организация документооборота с клиентом с использованием ЭЦП.
Добавление.
Кол-во клиентов — 1000-1500 из них порядка 300 активных
Формируемых документов для клиента в день 1500-2000
Средний размер документа 300кб
Планируется снизить количество документов за счет предоставления интерактивных форма просмотра данных, т.е. исключить документы имеющие информативный характер и оставить только те, которые требуют подписания с обоих сторон.
IB>Чем WPF xbap ограничивает мобильность клиентов?
Ознакомился. Да, действительно особых причин его не использовать нет, за исключением избыточности.
Интерфейс для клиента достаточно прост и аскетичен. Но этот вопрос сейчас все равно изучу — с прицелом на будущие вполне имеет право на жизнь. Если позволит заменить ActiveX который работает с криптобиблиотекой и локальными файлами ключей и отчетов, то вполне можно использовать.
Здравствуйте, gandjustas, Вы писали:
G>Используй SharePoint с управления контеном. Подписание — модуль на клиенте activex\xbap\отдельное приложение.
Не озвучите примерную стоимость такого решения?
Здравствуйте, Николаев Александр, Вы писали:
НА>Здравствуйте, gandjustas, Вы писали:
G>>Используй SharePoint с управления контеном. Подписание — модуль на клиенте activex\xbap\отдельное приложение. НА>Не озвучите примерную стоимость такого решения?
Если foundation, то бесплатно. Не вижу чего вам необходимо будет из платной версии.
Дописать activex для подписи документов и проверку подписи на сервере. Думаю несложно.
Остальной функционал — выборки, разграничение доступа, управление метаданными уже есть.
Можно еще search server express использовать. Это foundation + нормальный поиск. Тоже лицензий не требует.
G>>>Используй SharePoint с управления контеном. Подписание — модуль на клиенте activex\xbap\отдельное приложение. G>Дописать activex для подписи документов и проверку подписи на сервере. Думаю несложно. G>Остальной функционал — выборки, разграничение доступа, управление метаданными уже есть. G>Можно еще search server express использовать. Это foundation + нормальный поиск. Тоже лицензий не требует.
На мой взгляд все же не в тему. Слишком тяжелой будет интеграция с текущей инфраструктурой.
Но ради тонуса почитаю, спасибо.
НА>Ознакомился. Да, действительно особых причин его не использовать нет, за исключением избыточности.
Что Вы подразумеваете под избыточностью ?
НА>Если позволит заменить ActiveX который работает с криптобиблиотекой и локальными файлами ключей и отчетов, то вполне можно использовать.
ActiveX заменить позволит. По сути у Вас может быть единое приложение: и для менеджера компании, и для клиента, только с разным набором доступных функций.
НА>>Ознакомился. Да, действительно особых причин его не использовать нет, за исключением избыточности. IB>Что Вы подразумеваете под избыточностью ?
НА>>Если позволит заменить ActiveX который работает с криптобиблиотекой и локальными файлами ключей и отчетов, то вполне можно использовать. IB>ActiveX заменить позволит. По сути у Вас может быть единое приложение: и для менеджера компании, и для клиента, только с разным набором доступных функций.
Да, после более плотного изучуния до меня дошло, что именно вы предлагали. Спасибо.
IB>По сути у Вас может быть единое приложение: и для менеджера компании, и для клиента, только с разным набором доступных функций.
Возникает один нюанс. Если ASP приложение исполнялось на внешнем сервере и могло напрямую взаимодействовать с сервисами внутреннего сервера, то приложение xbap исполняющееся на клиенте не имет прямого доступа к сервисам внутреннего сервера, поэтому придется на внешнем сервере дублировать сервисы внутреннего с перенаправлением на него же...
Здравствуйте, Николаев Александр, Вы писали:
НА>Покритикуйте, посоветуте..
у меня у брокера примерно также- так я бы с радостью кострировал разработчиков брокера, ибо эта сука работает только под IE, ради которой приходится отдельный комп держать- чисто чтобы в осле раз в месяц поработать.
S>у меня у брокера примерно также- так я бы с радостью кострировал разработчиков брокера, ибо эта сука работает только под IE, ради которой приходится отдельный комп держать- чисто чтобы в осле раз в месяц поработать.
Интересное мнение. Примерно так же что? ASP.NET + ActiveX на клиенте?
Я так понимаю весь парк на *nix?
Мы проводили опрос среди наших клиентов — 100% microsoft.
Здравствуйте, Николаев Александр, Вы писали:
НА>Интересное мнение. Примерно так же что? ASP.NET + ActiveX на клиенте?
ага какой-то activex на клиенте, который ie требует
НА>Мы проводили опрос среди наших клиентов — 100% microsoft.
S>из 1000 клиентов, все microsoft ? не верю.
Дело в том, что одно из направлений деятельности нашего холдинга — брокерские услуги
Мы предоставляем доступ на фондовые биржи РТС и ММВБ посредством торгового терминала Quik
Это терминал работает на win платформе. Есть отдельные варианты доступа некоторых наших зарубежных партнеров посредством fix протокола.
Вполне допускаю, что у них могут быть *nix платформы, но предоставление им данного продукта в задачу не входит.
Так что пока у нас нет задачи учитывать другие платформы, да вобщем то и не предвидиться.
НА>Возникает один нюанс. Если ASP приложение исполнялось на внешнем сервере и могло напрямую взаимодействовать с сервисами внутреннего сервера, то приложение xbap исполняющееся на клиенте не имет прямого доступа к сервисам внутреннего сервера, поэтому придется на внешнем сервере дублировать сервисы внутреннего с перенаправлением на него же...
Я так понимаю что вопрос в безопасности,
если так,
то в WCF это можно решить не созданием промежуточного сервера, а созданием еще одной endpoint на стороне WCF сервиса внутреннего сервера с необходимой конфигурацией безопасности.
Хотя если понадобится дополнительная защита на аппаратном уровне возможно будет целесообразно сделать отдельный сервер, который, как Вы говорите будет дублировать сервисы внутреннего с перенаправлением на него же.
Но в любом случае это будет дешевле, чем Web приложение (или за те же деньги больший функционал).
НА>как то так НА>Покритикуйте, посоветуте.. Что то никак не сложится картинка (
Обновил схему
Есть мысль отказаться от хранения файлов pdf в файловой структуре и использовать в качестве хранилища SQL Server.
Еще смущает Workflow Foundation — к месту ли его воткнул..
Здравствуйте, Николаев Александр, Вы писали:
НА>>как то так НА>>Покритикуйте, посоветуте.. Что то никак не сложится картинка (
НА>Обновил схему НА>Есть мысль отказаться от хранения файлов pdf в файловой структуре и использовать в качестве хранилища SQL Server. НА>Еще смущает Workflow Foundation — к месту ли его воткнул..
Ты почти изобрел почти sharepoint. остановись, не трать силы на создание платформы, создавай приложения.
Здравствуйте, igor-booch, Вы писали:
G>>Интересно, а как в таком случае прийти к использованию IoC. Ведь все можно сделать и без него. Или AOP например. Ситуация такая будет для любой библиотеки. Ведь в самом начале она не нужна, а когда уже сделали и поняли что нужна — переделывать дорого. IB>Я понимаю о том что Вы говорите. IB>Спорный вопрос, что дороже: IB>внедрять понадобившуюся технологию в работающий продукт IB>или поддерживать не нужную технологию (или удалять её из готового продукта). IB>"А если не видно разницы зачем платить больше?". IB>Если все решения равноценны, то решающее играет система приоритетов. В agile на первом месте удовлетворение текущих потребностей заказчика.
Так именно в этом и проблема. С такой формулировкой никогда не появятся IoC, AoP, ORM и другие обо,щенные фреймворки, они же потребностей явно не удовлетворяют.
Поэтому и существует такая дисциплина как архитектура ПО — выбор принципов, технологий и фреймворков на основе которых строится решение. Этот процесс должен быть проделан заранее и должен подходить для широкого класса задач.
G>Поэтому и существует такая дисциплина как архитектура ПО — выбор принципов, технологий и фреймворков на основе которых строится решение.
Всё правильно. То о чем я написал выше, этому не противоречит.
G>Этот процесс должен быть проделан заранее и должен подходить для широкого класса задач.
Если этот широкий класс задач нужен заказчику и он готов за него платить, то несомненно.
G>Так именно в этом и проблема. С такой формулировкой никогда не появятся IoC, AoP, ORM и другие обо,щенные фреймворки, они же потребностей явно не удовлетворяют.
Грамотный разработчик может выявить явную необходимость использования IoC, AoP, ORM для решения текущих потребностей заказчика. Чем больше технологий, для которых разработчик может выявить явную (обоснованную) необходимость использования тем выше его квалификация. Разработчик может владеть технологией, но не уметь грамотно обосновать необходимость её использования для решения задач заказчика. В этом отношении разработчики должны быть чуть-чуть менеджерами, что вести с ними диалог, так как менеджеры более осведомлены о потребностях заказчика.
Здравствуйте, KoolAid, Вы писали:
KA>Здравствуйте, gandjustas, Вы писали: G>>Если foundation, то бесплатно. Не вижу чего вам необходимо будет из платной версии.
KA>MS SQL, если доки хранить в базе. Судя по требованиям, размер превысит 10 Гб лимит для express.
RBS и никаких проблем. Да и необязательно иметь express для sharepoint foundation. можно и на взрослой базе работать.
Здравствуйте, Николаев Александр, Вы писали:
НА>Есть мысль отказаться от хранения файлов pdf в файловой структуре и использовать в качестве хранилища SQL Server.
Заодно купите револьвер — застрелиться после пары бэкапов. КАТЕГОРИЧЕСКИ советую не хранить документы в базе, чего бы вам мелкософт ни сулила.
НА>Еще смущает Workflow Foundation — к месту ли его воткнул..
Если нагуглил и воткнул — то точно надо было воткнуть в анус. Технологии надо выбирать, когда в них есть необходимость.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, Николаев Александр, Вы писали:
НА>>Есть мысль отказаться от хранения файлов pdf в файловой структуре и использовать в качестве хранилища SQL Server.
M>Заодно купите револьвер — застрелиться после пары бэкапов. КАТЕГОРИЧЕСКИ советую не хранить документы в базе, чего бы вам мелкософт ни сулила.
Что не так с бэкапами?
НА>>Еще смущает Workflow Foundation — к месту ли его воткнул..
M>Если нагуглил и воткнул — то точно надо было воткнуть в анус. Технологии надо выбирать, когда в них есть необходимость.
Ценное замечание.
Можно добавить больше конкретики в ваши советы?
КАТЕГОРИЧЕСКИ советую не хранить документы в базе, чего бы вам мелкософт ни сулила.