Здравствуйте, Николаев Александр, Вы писали:
НА>>как то так НА>>Покритикуйте, посоветуте.. Что то никак не сложится картинка (
НА>Обновил схему НА>Есть мысль отказаться от хранения файлов pdf в файловой структуре и использовать в качестве хранилища SQL Server. НА>Еще смущает Workflow Foundation — к месту ли его воткнул..
Ты почти изобрел почти sharepoint. остановись, не трать силы на создание платформы, создавай приложения.
НА>Еще смущает Workflow Foundation — к месту ли его воткнул..
В agile development есть принцип: презумпция ненужности технологии или инструмента: "Не используйте технологию (или инструмент) пока необходимость в ней не будет доказана". Иными словами Вы должны вырасти из тех технологий и инструментов, необходимость использования которых очевидна на данном этапе развития проекта, чтобы использовать более сложные технологии.
Часто совершается ошибка, архитекторы руководствуются презумпцией нужности технологии: "Любую навороченную технологию нужно использование, если её ненужность не доказана".
Я думаю в первой версии приложения можно обойтись без WWF. В последующих версиях, в качестве развития можно внедрить WWF. После промышленного опыта использования первой версии у Вас появятся пожелания заказчика, для реализации которых возможно потребуется WWF, а может и не потребуется.
Здравствуйте, igor-booch, Вы писали:
НА>>Еще смущает Workflow Foundation — к месту ли его воткнул..
IB>В agile development есть принцип: презумпция ненужности технологии или инструмента: "Не используйте технологию (или инструмент) пока необходимость в ней не будет доказана". Иными словами Вы должны вырасти из тех технологий и инструментов, необходимость использования которых очевидна на данном этапе развития проекта, чтобы использовать более сложные технологии. IB>Часто совершается ошибка, архитекторы руководствуются презумпцией нужности технологии: "Любую навороченную технологию нужно использование, если её ненужность не доказана". IB>Я думаю в первой версии приложения можно обойтись без WWF. В последующих версиях, в качестве развития можно внедрить WWF. После промышленного опыта использования первой версии у Вас появятся пожелания заказчика, для реализации которых возможно потребуется WWF, а может и не потребуется.
Интересно, а как в таком случае прийти к использованию IoC. Ведь все можно сделать и без него. Или AOP например. Ситуация такая будет для любой библиотеки. Ведь в самом начале она не нужна, а когда уже сделали и поняли что нужна — переделывать дорого.
В итоге весь проект — куча велосипедов. Явной необходимости ведь никогда нет, потому что все можно написать самим, а только потом понять что это велосипед.
G>Интересно, а как в таком случае прийти к использованию IoC. Ведь все можно сделать и без него. Или AOP например. Ситуация такая будет для любой библиотеки. Ведь в самом начале она не нужна, а когда уже сделали и поняли что нужна — переделывать дорого.
Я понимаю о том что Вы говорите.
Спорный вопрос, что дороже:
внедрять понадобившуюся технологию в работающий продукт
или поддерживать не нужную технологию (или удалять её из готового продукта).
"А если не видно разницы зачем платить больше?".
Если все решения равноценны, то решающее играет система приоритетов. В agile на первом месте удовлетворение текущих потребностей заказчика.
G>В итоге весь проект — куча велосипедов. Явной необходимости ведь никогда нет, потому что все можно написать самим, а только потом понять что это велосипед.
Многое решает не теоретические размышления, а банальная квалификация и психология разработчиков. Грамотный разработчик должен уметь отличить преждевременную оптимизацию от действительно необходимого технического решения.
Преждевременной оптимизацией страдают разработчики с комплексом неполноценности. Предложениями использовать навороченные технологии они старается скрыть свою низкую квалификацию. Возможно квалификация даже высокая, но у них комплекс (страх), что низкая. Такие особенно опасны, так как своим авторитетом и знаниями могут "продавить" решение использовать ненужную технологию.
Здравствуйте, 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>Если нагуглил и воткнул — то точно надо было воткнуть в анус. Технологии надо выбирать, когда в них есть необходимость.
Ценное замечание.
Можно добавить больше конкретики в ваши советы?
КАТЕГОРИЧЕСКИ советую не хранить документы в базе, чего бы вам мелкософт ни сулила.
Технологии надо выбирать, когда в них есть необходимость.
