tygraТак мы и просим: покажите, с чего бы это бизнес-логику удобнее структурировать по ООП-принципам ??? Кто вам сказал, что это так?

Самый простой пример. Ну к примеру, существует сущность "товар". Существуют правила ценообразования для товара. Существует также несколько сущностей, унаследованных от "товара" как на уровне таблиц, так и на уровне классов бизнес-логики. На уровне таблиц наследование осуществляется отношением 1:1. Для этих унаследованных сущностей переопределены правила ценообразования, также добавлено несколько дополнительных атрибутов. На уровне клиенте я могу работать со всеми этими сущностями как с "товаром", менять их атрибуты и т.п. Правила ценообразования задаются формулами, которые могут транслироваться в выражения SQL, можно сказать, что логика ценообразования в результате работает в СУБД, но для того чтобы это было так, промежуточный слой должен довольно много телодвижений сделать.

К примеру, я просто выбираю все "товары", в том числе и унаследованные.
Выражение для выборки строится наполовину в промежуточном слое, наполовину в СУБД, т.к. логика построения такого выражения достаточно сложная, а язык СУБД для этого очень слабо приспособлен.

Есть свой язык для выборки объектов + набор универсальных хранимых процедур, в которые передаются "полураспарсенные" конструкции этого языка. Этими несколькими хранимыми процедурами генерится динамический SQL для выборки коллекции объектов.

Обработка результата тоже производтся в промежуточном слое, на выходе получается коллекция объектов класса "Товар".

Для каждой сущности определен набор операций, на операции завязана система security. На базовую сущность Entity завязаны права на выборку, чтение, создание, модификацию, удаление, редактирование прав, которые соответствуют различным операциям над этой сущностью. Операции наследуются точно также как на уровне СУБД, так и на уровне классов. Т.е. все унаследованные сущности будут иметь тот же набор операций, что и Entity + могут задаваться свои.

В результате при добавлении любых новых систем ценообразования, любых специфических типов товаров, в клиентский код, который работал с коллекциями товаров не прийдется вносить никаких изменений.

tygraУ вас с этим проблемы, из-за которых приходится выносить? СУБД что, уже не справляется?

Разумеется. У меня логика кэширования зависит от логики приложения, а не от логики СУБД.

tygraВот мне не нужны данные, структурированные по ООП принципам - они сделают только хуже, как не нужно и все другое, ООП-овидное в вашем смысле, на стороне СУБД. А вам зачем?

А у меня структурируются не только данные, но и операции над объектами, как я описал выше.

авторДа ну... Ну что нельзя сделать в MS SQL Server? Чур решения дифф. уравнений не предлагать :)

Парсер своего языка запросов оччень я бы сказал проблематично построить.

ASCRUSА его и не надо строить в СУБД - уже есть готовый и мощный - это сам SQL
Так он и не строится в СУБД по причине, описанной выше - строится на промежуточном слое, в СУБД передается уже результат его работы. По поводу в принципе использования своего языка...
Очень не хочется здесь всю архитектуру приложения описывать, т.к. кучу времени займет, но поверьте, одним SQL-ем здесь не обойтись... Он используется на клиенте для выборки коллекций объектов с использованием связей между сущностями. Связи также описаны в метаданных. Помимо обычных атрибутов, хранящихся в таблицах, есть т.н. "расширенные" атрибуты, хранящиеся вертикально в отдельной таблице, в принципе по ним также может осуществляться сортировка и поиск. Если это все писать на чистом SQL... Сложновато получается и непонятно, мягко говоря. На клиенте меня не интересуют таблицы и view, меня интересуют сущности в моей системе, в терминах этих сущностей и работают выборки с использованием своего языка.
Да и выборки получаются не очень простые, на 2-3 рекордсета в среднем, их приведение к коллекции объектов осуществляется отдельно, поэтому сам результат выполнения SQL-выражения мне на клиенте тоже неинтересен.

Old NickПример неудачный. Если у вас ценообразованием занимается метод, то привяжите к каждому типу товара метод и вызывайте его через один базовый виртуальный метод товара. Есть проблемы в реализации? Нехрен тогда спорить о плюсах и минусах.

Выбрать на клиента все товары, в том числе и унаследованные? Делается не просто, а очень просто: select * from Things (если все виды товаров наследуются от одного базового, то выборку делаем из базовой таблицы)

Садитесь, 2!
Эти два метода неравноценны.
Расскажите мне тогда немного о том, что вы понимаете под полиморфизмом.
В случае такой выборки вы получите коллекцию объектов типа Товар, т.е. унаследованные товары будут без своих дополнительных атрибутов, соответственно по ним некорректно будут рассчитаны цены. Я же в своем случае получу коллекцию разнотипных объектов, типы которых унаследованы от типа "Товар", к которым буду обращаться так, как будто это объекты типа "Товар".

Old NickА по сути, ценообразование это список стоимостей, входящих в него составляющих. Что такое составляющие? Это сам товар, его составляющие (допустим, приход на склад в виде комплектующих, а расход со склада в виде готового компа), услуги по его продаже, услуги по его сборке, скидки на его продажу, накрутки на него, налоги на него и т.д. и т.п. И подсчет делается простым агрегирующим селектом.

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

ASCRUSК сожалению не поверю, потому что у меня все замечательно обходится одним SQL

То что у ВАС обходится замечательно одним SQL, не обязательно должно во всех случаях обходиться одним SQL, вам не кажется? Особенно, если учесть мягко говоря существенную разницу в архитектуре приложения. Критиковать же архитектуру не имея мало-мальских данных о самом приложении мне кажется несколько опрометчиво.

ASCRUS, я верю, что вы просто виртуоз SQL и можете на нем сделать все что угодно. Я не верю в то, что методы, применяемые вами являются единственно верными в любой ситуации. Я не уверен в этом и для своих методов. А пока я в этом не уверен, я не буду всем советовать срочно начать использовать мои методы и все остальные приложения, реализованные не так подозревать в кривой архитектуре, что и всем остальным советую.

Я не говорю, что не реализуемо никогда и не прикаких обстоятельствах, я даже не говорил, что это и у меня нереализуемо. Это просто _нецелесообразно_ именно в моей архитектуре. Почуствуйте разницу. В вашей это может замечательно работать.

Old NickАх, простите, я забыл что у вас ценообразование на клиенте происходит :-)
?? Откуда вы это взяли?

Old NickПоясняю насчет полиморфизма. У вас есть метод задача которого для каждого экземпляра из списка товаров вызвать метод ценообразования и полученный результат записать напротив товара. Значит данный метод виртуальный и его единственная задача по идентификатору товара определить его тип, по типу найти реальный метод и вызвать его.
?? А это откуда?

Ценообразование у меня выполняется в SQL, еще в момент выборки, прочитайте внимательно еще раз . но в то же время на клиенте мне нужны полноценные объекты своих типов, а не кастрированные путем select * from Things.

Old NickИли есть проблемы с созданием в реляционной базе виртуальных и перекрывающих метод?
А это, извините меня, и есть то, что я называл извращением.

Old NickА зачем Вам на клиенте нужны полноценные объекты? Что Вы с ними делать будете на клиенте?
Вопрос на миллион долларов :). Вы знаете, я, как ни странно, буду вызывать их методы :). Причем у объекта типа 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 мне в этом случае вернет нечто непонятное.

pkarklinИзвините, не удержался. Что для чего "слабо приспособлено"?! язык SQL для обрабтки реляционных данных?!

Там что-то говорилось про реляционные данные? Там говорилось про логику построения SQL-выражения из выражения на своем языке запросов. То есть по вашему SQL приспособлен для того, чтобы парсить какие-то текстовые выражения? Но я надеюсь вы этого не имели в виду, а просто невнимательно прочитали мой пост.