Alexey Popov писал(а): > Это у вас, как я понял один объект. А когда > у каждого скрипта по 10 кастомизаций на объектах. > А потом появляется новая фича в базовом функцонале, > то возникает вопрос что в 10 кастомов надо внести > эту фичу.
Объект, я так понимаю - это отдельный клиент (тот, который платит бабло)? Да, у нас он один. Но у него, грубо говоря, двадцать филиалов. Требующих разной настройки. Для этого в базе данных есть контейнеры настроек. Контейнеры поддерживают наследование. > Да, вы фактически преодолели скриптовые грабли > применив тяжёлую артиллерию. Ну вообщем, да. OLEDB Провайдер, ADO, ActiveX Scripting, OLE-Automation. Плюс извращенный мозг Коваленко, который смог это все объединить в единое целое. > Система получается слишком > жёсткой. Большое преимущество скрипта как раз в том > что можно забить на структурность и можно менять быстро > на лету не задумываясь о всякой хрени типа контроля версий. Ты не так смотришь на эту проблему. Жестким у нас является компилируемое ПО. То что откомпилировано, меняется очень редко. Скрипты совершенствуются и обновляются постоянно. > Так я и не говорю что есть. Тем более что проблемы > можно решить. Вопрос изначально в проектировании > скриптовой системы и её целесообразности. > Хм. Ну что я тебе еще могу сказать. С возрастом у человека меняется система ценностей. Точнее она остается той же. Вот только центр тяжести переносится на другие позиции. В детстве, которое было до темного детства, я гонялся за блохами. Такты процессора, байты памяти ну и так далее. Потом было темное детство. Про это я рассказываю только за пиво. Потом был 16 сентября 2002 года, когда мы запустили то, о чем я тебе толкую сейчас. Если бы логика была прошита в EXE/DLL - меня бы закопали в течении следующих первых двух недель. Особенно мне памятна бага в функции формировании текстового представления даты, из-за которой начали портить бланки свидетельств. Дальше было не легче, но если бы не жесткое разделение системы на две части, я бы тут сейчас не выпендривался :)) И, кстати, при целесообразность. В основу проектирования каждого модуля было положена архитектура MVC. В 2002 году у нас получились неповоротливые и прожорливые модули. При том, при всем, что для них юзался С++. Я тогда еще здесь писал, что на плюсах можно писать проги не уступающие прогам на яве :))) В 2005 году я догадался как можно побороть эти дефекты. В начале 2006, самый страшный модуль стал жрать на 40% меньше памяти и работать более чем в 2 раза быстрее. Хотя "эксперты" со стороны клиента на протяжении этого времени очень часто твердили, что выбраная архитектура ущербна по своей сути. Правда самим повторить функционал наших модулей, с использованием "правильных" подходов так и не удалось. Но попытки не прекращаются :) То же самое можно сказать и про нашу "объектную" архитектуру базы данных. Коваленко Дмитрий.
