|
Для Peisov.
Хорошо, пропуская опять же лирические рассуждения, попробуем более точно сформулировать. Итак:
1. Есть ОЧЕНЬ большое и ОЧЕНЬ серъёзное приложение, в котором только строк кода более 500 000 (пятисот тысяч), а форм - более 400. И для многих не до конца понимающих, чем промышленное программирование отличается от увлечений и мелких поделок, поясню: форм много, и они все - разные, созданные для разных целей, разных задач и разных данных. Создавать для каждой такой задачи класс, потом объявлять на его основе объект, и использовать его один единственный раз, в конкретном месте - это просто дебилизм. Гораздо проще и быстрее создать конкретную форму под конкретную задачу. Потому что имеется большой проект, который оплачивается очень большими деньгами, в котором жестко и однозначно прописаны сроки выполнения, и меры наказания при неисполнении в срок. При таких условиях следовать кретиническому требованию всегда использовать ООП - просто самоубийственно: заказчик просто скажет - на хрен мне ваши изыски, мне рабочее приложение требуется. А кто этого не понимает - пошли вон, найду других исполнителей. Деньги, повторяю, просто огромные. Опять же для понимающих - ССВ этого приложения составляет более 1 780 000 (одного миллиона семисот восьмидесяти тысяч) рублей в месяц.
Всё-таки разъясню: ССВ - это совокупная стоимость владения, т.е. туда входят и зарплата разработчиков, и зарплата пользователей. и зарплата обслуживающего персонала холдинга, и ССВ компьютерной техники, ЛС и всего прочего. Так вот. Это не горчичку на сардельки мазать под пивко, о достоинствах ООП рассуждая...
2. Почти то же самое относится ко всем объектам в каждой форме - они все выполняют разные задачи. Мне вот тут мой зам подсказывает: говорить о том, что надо бы создать класс, в котором прописать метод контроля, а потом только создавать объекты, да использовать их, это всё равно, как если бы определить, что TextBox может вводить только числа от 1 до 25, с проверкой на недопустимость ввода других чисел, не говоря уже о буквах и прочих символах, а потом пытаться на основе такого класса создавть поля ввода для совершенно разных данных - и числовых, и строковых, и символьных в формате Unicod, и т.д.
3. Типовая форма приложения, например, такова: она заполнена фреймом из семи-десяти закладок. На каждой закладке имеются области инфрмации (на основе Label), по одному, а то и по два-три Grid'а, по десятку кнопок, которые выполняют различные функции (при этом тривиальных, типа печати, среди них нет), по десятку или по два десятка полей ввода данных, причём, как уже говорилось, самых разных, от простейших типа ФИО, до сложных многосимвольных и сложноформатированных кодов, которые можно, конечно, выбирать из локальных (привязанных к даному типу данных) справочников, если они туда введены, а если не введены - то тут же их и вводить, и так далее.
4. Проверки (их тип и вид) в большинстве своём задает пользователь (на основе заранее сформулированного набора правил контроля) совсем в другом месте, они хранятся в специальных таблицах базы данных, и в каждой форме проще всего организовать специальный пользовательский метод, в котором к этим таблицам происходит обращение, ищется необходимое условие и производится проверка.
5. Поскольку в каждой форме в общей сложэности до ПОЛУТЫСЯЧИ объектов, то делать для каждого объекта в форме свой метод проверки - очень и очень накладно, по двум причинам:
1) во-первых, для этого необходимо ООЧЕНЬ большое число рядовых программистов-кодеров - а их количество ограничено, поскольку в проекте штат разработчиков строго определён и раздуванию не подлежит - поскольку количество проверок постоянно изменяется (это, повторюсь, возложено на усмотрение пользователей ИС), то придется постоянно модифицировать каждый метод в каждом объекте. Кретинизм ?
2) во-вторых, в каждом таком методе постоянно повторялись бы совершенно однотипные операции, что привело бы к значительному увеличению объёма кода, и как следствие - к увеличению сложности сопровождения и разработки. Тоже Недопустимо.
Так что, ребята, определние статуса активности объекта в форме - это весьма актуальная задача. На данный момент это делается очень искусственно - путём формирования в методе вызова каждого объекта своего идентификатора, занесению его в специальную таблицу, и после этого вызова процедуры проверки. Те., это опять таки увеличение и объема приложения, и размера базы данных, что не может не сказываться на быстродействии, причём не в лучшую сторону.
А если ещё учеть обязательное логирование и протоколирование всех действий пользователей, для последующих разборок (в случае необходимости, для определения, кто виноват в воде неверных значений, приведших к искажению данных и отчётности перед ФСФМ и прочими государственными структурами), то такое решение сразу видится очень топорным и надуманным.
Поэтому, если бы можно было в методе формы определить, какой объект был активен в момент вызова этого метода - это сразу бы решило очень серъёзную практическую задачу. По самым приблизительным прикидкам - это уменьшило бы размер базы данных на 5-6 %, а при текущем её размере в 70-75 гигабайт - это весьма существенно. Да и размер приложения бы сократился, вполне возможно, на ту же величину.
Так что, не надо задавать не относящихся к делу вопросов, и обвинять в некомпетентности, в использовании не той "религии", и прочего. И не надо советов, что надо в таких случаях использовать не VFP, а что-то посеръёзнее - нам виднее, что надо использовать. На первом этапе делали всю эту бодягу на Oracle 10g и 11i, но потом столкнулись с таким чудовищным объёмом ошибок, кретинизма самих Oracl'истов, и объёмом капиталовложений и увеличения ССВ, что два с половиной года назад просто вынуждены были мигрировать на VFP.
Поэтому, если не знаете, КАК ЭТО СДЕЛАТЬ - так и сидите себе дальше... Знаете - ответьте.
|
