|
Ну вот, уже веселее, и до конца дня рабочего полчаса - есть время ответить :))
Пример действительно плохой взят.
Потому что у всех тут (почти) он работает на чистом SQL.
У нас также есть рассчет цены товаров, зависит от: типа товара, базовой цены, группы в которую входит, еще чего-то... в принципе, неважно от чего, главное, чтобы это "чего" можно было узнать по конкретному товару.
Вся эта фигня конечно же делается на SQL, причем одной процедурой, а методы рассчета записаны своим спец. языком как для каждого тиап товара, так и общие - кстати, кому тут парсер то? :)
Я что-то не вижу, куды тут ООП присобачить, методы, свойства? Сказали товару - рассчитайся, т.е. дернули ХП - оно все и рассчиталось. Дернули для любого товара одну ХП - она там внутри сама разберется, чего и как. Зачем на клиента тянуть чего-то, какие такие телодвижения делать?
авторК примеру, я просто выбираю все "товары", в том числе и унаследованные.
Выражение для выборки строится наполовину в промежуточном слое, наполовину в СУБД, т.к. логика построения такого выражения достаточно сложная, а язык СУБД для этого очень слабо приспособлен.
Т.е. вы не можете select * from Товар написать прямо в ХП? Для этого городите непонятно что? А зачем? Я так и не понял.
авторЕсть свой язык для выборки объектов + набор универсальных хранимых процедур, в которые передаются "полураспарсенные" конструкции этого языка. Этими несколькими хранимыми процедурами генерится динамический SQL для выборки коллекции объектов.
Коллекции каких таких объектов? Почему так хитро? Почему не только SQL?
авторОбработка результата тоже производтся в промежуточном слое, на выходе получается коллекция объектов класса "Товар".
Зачем? Зачем вам обрабатывать это на клиенте? Зачем вообще обрабатывать? Вообще, не зная, что вы подразумеваете под коллекцией объектов, под самим объектом и т.д.
авторВ результате при добавлении любых новых систем ценообразования, любых специфических типов товаров, в клиентский код, который работал с коллекциями товаров не прийдется вносить никаких изменений.
Но если что сильно поменяется - придется.
У нас же на клиента не надо вносить ничег ни до, ни после, вообще клиенту фиолетово.
авторРазумеется. У меня логика кэширования зависит от логики приложения, а не от логики СУБД.
Так и был вопрос - чего кэшируете?
авторОчень не хочется здесь всю архитектуру приложения описывать, т.к. кучу времени займет, но поверьте, одним SQL-ем здесь не обойтись... Он используется на клиенте для выборки коллекций объектов с использованием связей между сущностями. Связи также описаны в метаданных. Помимо обычных атрибутов, хранящихся в таблицах, есть т.н. "расширенные" атрибуты, хранящиеся вертикально в отдельной таблице, в принципе по ним также может осуществляться сортировка и поиск. Если это все писать на чистом SQL... Сложновато получается и непонятно, мягко говоря. На клиенте меня не интересуют таблицы и view, меня интересуют сущности в моей системе, в терминах этих сущностей и работают выборки с использованием своего языка.
Да и выборки получаются не очень простые, на 2-3 рекордсета в среднем, их приведение к коллекции объектов осуществляется отдельно, поэтому сам результат выполнения SQL-выражения мне на клиенте тоже неинтересен.
Эээээ.....
Зайдите на www.ozon.ru, возьмите любой товар. На товаре до фига чего есть - авторы, страницы, издатель, обложка, производитель, актеры, описания, комментарии, аналоги и еще туева хуча всякой белиберды, которая зависит от типа товара, и все это хранится не в тексте (как на html-странице красиво), а в атрибутах товара - единичных, множественных, привязанных других объектах и т.д. и т.п. и на клиенте выглядит ужасающе. И все это работает через СУБД. Нет, конечно на клиенте кое-чего тоже сделано, чтобы оно все показывалось как надо, но обрабатывается, связывается и т.д. оно только в СУБД, через sql.
Никаких проблем таких, чтобы решать это чем-то еще, нет.
авторЯ не говорю, что не реализуемо никогда и не прикаких обстоятельствах, я даже не говорил, что это и у меня нереализуемо. Это просто _нецелесообразно_ именно в моей архитектуре. Почуствуйте разницу. В вашей это может замечательно работать.
Ваша архитектура ничем не отличается от других - ну если только плохо построена под sql изначально :)
автор
>>А зачем Вам на клиенте нужны полноценные объекты? Что Вы с ними делать будете на клиенте?
Вопрос на миллион долларов :). Вы знаете, я, как ни странно, буду вызывать их методы :). Причем у объекта типа SpecificThing1 метод ComputeSomething будет вызывать в результате хранимую процедуру p_ComputeSomething1 с передачей параметра param1, где param1 - это дополнительное свойство SpecificThing1. А у объекта SpecificThing2 метод ComputeSomething будет вызывать в результате хранимую процедуру p_ComputeSomething2 с передачей параметра param2, где param2 - это дополнительное свойство SpecificThing2.
Свойства param1 и param2 выбираются из полей таблиц SpecificThing1 и SpecificThing2, т.е. в таблице Things не присутствуют. Классы SpecificThing1 и SpecificThing2 унаследованы от класса Thing, данные которого хранятся в таблице Things. А select * from Things мне в этом случае вернет нечто непонятное.
Я выше написал, как оно работает.
Вам что, проблема сделать одну ХП, которая будет понимать, какой метод дернуть исходя из типа товара? Для этого вы городите городушки? Только для этого???!!!
Или вы что-то скрываете? :)
-- Tygra's --
|
