Вот как так? Говоришь одно, спрашиваешь одно - отвечают другое.......

ООП А вам не кажется, что данная логика значительно лучше реализуется на ОО языках вместо того, чтобы городить это на сервере. Ведь именно про такую обвязку и говорил Д. Сорокин в первых постах.
Как у вас вызвается метод базового класса? Тоже через такой поиск? Зачем???
Нам не кажется.
А вы привели бы пример этого всего на ООП - а мы посмотрим, как прекрасно, когда БЛ зависит от клиента. Особенно если вдруг версии клиента разные. :))
Ну еще вам наверное интересно писать в клиенте кучу структур, вместо одной маленькой и простой ХП? А потом править там же, на клиенте - так? Или не так? А как? Хотелось бы пример.

ООП Если это пример того, как "снижаются" расходы на разработку - то я молчу. Релиазовывать С++ на T-SQL, да еще и так, что это становится делом ВСЕХ разработчиков системы - это что-то.
У вас очки не те одеты - вы о каком С++? Или ..а, понятно, вот почему ООП - вы же только на С++ умеет с данными работать, а на SQL кроме select * from table ничего боле не можете. Ну так ваши проблемы, что sql не родной.

ООП В вашей реализации любой девелопер, разрабытвающий БЛ должен знать, что при добавлении метода ему нужно сделать "виртуальный", в нем пробежаться по таблице типов, выбрать нужный по имени и его вызвать. А если потом ошибиться на одну букву в названии метода для типа - то еще и ошибку получить. Великолепно.
Я даже и не понял, о чем это вы?
Но все-равно, получается, что в вашей реализации ничего вообще делать не надо - методы сами откуда-то берутся, материализуются силой мысли. :))

--------
VladiCh Мне для заведения нового атрибута в самом простом случае не потребуется ни того, ни другого, ни третьего. В системе есть т.н. расширенные атрбуты, которые хранятся вертикально в отдельной таблице. Например если в документе есть поля, которые надо выделять отдельно, но на бизнес-логику они никак не завязаны, зато по ним например может производиться поиск, то мне не придется изменять ничего, просто в конфигураторе описать новые поля.
Ну давайте сначала определимся - есть атрибуты, которые хранятся где-то отдельно от основной таблицы, и есть поля таблицы.
Так вот при изменении полей таблицы вам все-равно придется менять везде.
И нам тоже :)
При изменении атрибутов вам не надо менять - автоматика, понимаешь.
Ну и нам тоже :)
Вот отсюда и вопрос, опять и опять: зачем тогда вам объект, если у нас его нет, а делаем мы с вами одно и тоже. :))

VladiCh Пользователь дергает эти методы... Эти методы реализуются по-разному у разных типов объектов, но пользователь их дергает одинаково.
Ну конечно одинаково - одну ХП :) Только для того, чтобы ее дернуть, не надо городить городушки на клиенте - просто exec ChangeState @ID, @SID. И как бы логика не поменялась - всегда только этот вызов, с любого клиента, даже если у вас кроме ID и названия объекта ничего больше нет (естественно и никаких ООП).
авторДля выполнения этих методов объекту нужны атрибуты, загружаемые з базы.
Вот! А нам не нужно ничего загружать из базы - все там в ней самой и делается. Что проще?
VladiCh Может быть я конечно непонятно пишу, не знаю... Но мне почему-то кажется, что дело не во мне, просто кое-кто упорно не желает понимать простейших вещей.
Ну, мы просто не можем никак понять, зачем вам объекты со всеми их атрибутами и методами, которые как-то генерит какой-то специальный механизм. Почему непонятно - потому что непонятно, зачем делать сложнее, если можно проще, причем намного. Было бы у вас проще - мы бы другое говорили.

VladiCh Разумеется можно дернуть одну ХП, которая внутри определит тип товара и дернет другую ХП. При добавлении нового типа товара вам нужно будет переписывать эту ХП.
Ну если вы хотите - переписывайте.
Обычно не переписывают - одна базовая ХП имеет только механизм для разборки, что, кто, зачем и где дернуть, вся же обработка естественно для каждого типа товара написана отдельно. Но тут уж простор реализаций - кто алгоритмы хранит и потом обрабатывает, а кто и отдельные процедуры пишет.
Но сводится все к одному: дернули базовую ХП, она поняла тип, по типу определила, что исполнить, исполнила, отдала ответ. Все. Зачем тут ООП, да еще на клиенте? Зачем вообще для этого что-то на клиенте?

Я еще раз обозначу проблему: зачем вам объекты? Ну приведите пример объекта, примерное описание кода, который делает объект на клиенте и т.д.
Потому что пока все-равно не понятно - у нас сделано все намного проще, а работает так же. Смысл делать сложнее?

Может рассказать и про мой "механизм", так, для информации? Может...

-- Tygra's --