ДжекНепотрошительkmawГородить какую-то "ООП" поверх РСУБД, мое личное мнение, не даст прироста эффективности разработки (бросьте в меня помидор):

Вот и я к чему веду. Этот фреймворк позволяет легко автоматизировать простые задачи... но при любом более-менее сложном случае мы упремся в те или иные ограничения фреймворка, и работа по его адаптации многократно съест все его преимущества.
Оно автоматом генерирует процедуры на вставку/удаление/обновление, а также вьюхи? Отлично. А что делать, если сгенерированная автоматом структура впадает в клинч на имеющихся данных, т.к. нужно править планы запросов и делать индексы?
А кто целостность данных там будет гарантировать? А где расширенную бизнес-логику писать? В объектах - низзя, оно ж их перегенерирует. Снаружи? Тогда в чем смысл такого "ООП"?
А документирование этого добра? Ведь мы могли бы иметь схему БД в каком-нибудь PowerDesigner'e, которая сама по себе является наглядной документацией, и отличным инструментом для сопровождения базы.

Один мой знакомый сделал то же самое в PowerDesigner. Сущности оформлял в виде классов, а код генерировал на VB.
Я еще раз повторюсь, что дело не в инструменте, а в наличии мозгов. Если есть мозги, то можно весь код ручками сделать, а если мозгов нет, то и Visual Studio не поможет.

По поводу жесткости фреймворка.

Во-первых я могу его использовать, а могу и не использовать, то есть писать ручками. Конечный результат от этого не меняется.
Во-вторых у меня всегда есть возможность ручной правки кода поверх сгенерированного на всякий особый случай.

Я ж говорю, если не хватает мозгов и опыта, то инструмент то тут при чём?

iscrafmOld Nickпропущено...


Полгода назад взял подработку. Сделал АРМ для инвентаризации на основе RFID меток. Задача была спроектирована до меня. Естественно как у всех. Времени было всего 20 дней, некогда было применять свои плюшки. Любой чих приходилось многократно прописывать. Больше за такое не возьмусь
у вас было целых 20 дней, для того, чтобы сделать один АРМ инвентаризации. И при этом некогда было "применять свои плюшки". Где тогда описываемое увеличение производительности?

Проблема была в том, что не я один работал надо проектом. Была еще команда, которая писала код для терминала сбора данных. И чтобы поменять структуру таблиц на ООП стиль, пришлось бы согласовывать с ними. Я по опыту я знаю, что даже несколько лет недостаточно, чтобы люди поняли что такое ООП и как его применять. Вот даже тут на форуме пока еще никто не понял :-)

Большинство программистов имя в руках объектно-ориентированный язык не могут объектно-ориентированно проектировать и программировать.

Я могу программировать объектно-ориентированно на любом языке программирования, даже на необъектно-ориентированных языках, таких как T-SQL или FoxPro 2.5 или любом процедурном.

iscrafmOld NickЯ по опыту я знаю, что даже несколько лет недостаточно, чтобы люди поняли что такое ООП и как его применять. Вот даже тут на форуме пока еще никто не понял :-)
точно уверены что никто не понял что такое ООП? После таких высказываний нить серьезного разговора теряется.

А с кем тут серьёзно то разговаривать? :-)

Bogdanov AndreyOld NickПричем здесь фреймворк? У меня нет фреймворка.

Или ООП это фреймворк?ООП - это подход, а ваша поделка (exec Class, exec Field, exec Compile и т.п) - это фреймворк. Можете заглянуть на википедию - там определение слова фреймворк написано.

Еще раз поясню для особо талантливых. Я могу сделать то же самое ни разу не написав exec Class