ООП и базы данных

← →
RDA (2002-09-27 10:06) [0]

При написании программ с работающих с базами данных чаще всего использую обычный процедурный подход. Хотелось бы услышать мнение мастеров, по этому поводу - используют ли они ООП (имеется в виду создание к примеру класса работник, предприятие, справочник) в данном случае или так же как у меня просто идет работа с полями базы данных. Хотелось бы услышать + и - обеих реализаций.
В данный момент начинаю реализацию комплекса программ в клиент-серверной архитектуре. Кадры, зарплата, юридический отдел (регистрация субъектов предпринимательской деятельности), управление экономики (работа с зарегистриванными субъектами предпринимательской деятельности) и т.д. - не хотелось бы наступать на грабли, поэтому прошу совета и подсказки.

← →
Mike_Goblin (2002-09-27 10:26) [1]

Используют, пишут свои frameworks под это дело (у меня так совсем простенький, но хватает), а еще в Delphi 7 Architect появилась такая чудная штука как Bold - это вот собственно и есть набор компонентов, позволяющих разрабатывать БД с применением ООП. Плотно ее я не юзал, поэтому пока хвалить или ругать не буду :)))

← →
roottim (2002-09-27 10:32) [2]

ничего в этом плохого нет!
создайте свой класс "работник".. задайти основные проперти и методы для манипуляции табл...
если речь идет о создании класса как сущности, то это явно не имеет смысла, и замедлит работу

и еще вот!.. незнаю насколько силен язык в ibase.. все лучше 2/3 работы отдать серверу.. и класс использовать для вызова именно ХП
имхо

← →
RDA (2002-09-27 10:37) [3]

Спасибо Mike_Goblin, roottim.
Есть у кого есть еще мнения.
>> roottim - именно ХП и предполагалось использовать.

← →
Johnny Smith (2002-09-27 14:25) [4]

2RDA © (27.09.02 10:06)
В самостоятельных проектах именно так стараюсь и работать. Хотя, мне кажется, нельзя абсолютизировать этот подход - в каждой конкретной ситуации подход должен быть индивидуальный..

← →
ART_43 (2002-09-27 15:08) [5]

я недавно для снабжения писал прогу с mssql, мне было удобней через ссылающиеся друг на друга справочники все делать, а потом можно было взять любую таблицу и используя средства сервера проанализировать на кого она ссылается, кто на нее ссылается, выбрать коментарии к полям, которые можно показывать вместо названий полей, сделал таблицу в которой опизал ключевые поля и поля названий, еще несколько фенек.
Написал несколько процедурок на серваке БД, которые всю основную обработку делали, Написал несколько процедурок на D и весь проект уложился в 15 форм, хотя при работе кажется, что их там около 40 или больше.
Хотя с персоналом может ООП будет и лучше. Я вообщето над этим способом не задумывался, хотя на первый взгляд вроде заманчивый.

← →
ART_43 (2002-09-27 15:30) [6]

В "КомпьютерПресс" в начале 2002 (вроде 1-3 номера) на сидюках была статья в нескольких частях на эту тему, советую прочитать прежде чем начнешь работать над проектом. Там много всего интересного, мне она сильно помогла.

← →
RDA (2002-09-27 21:00) [7]

Большая просьба поделитесь примером организации какого-либо класса (работник, предприятие, отдел), дабы не начинать все с самого начала.

← →
MsGuns (2002-09-27 21:12) [8]

А я бы не стал завязываться на смысловое наполнение БД как на объекты. А если завтра объект "Работник" или "Подразделение" пополнятся новыми реквизитами, что мне, прикажете все классы переписывать со всеми сопутствующими траблами ? Проще качественно проработать топологию БД, серверную часть и разработать хороший датамодульный инструментарий. Гибче, проще, мобильнее..

← →
Hro (2002-09-29 00:15) [9]

Я вот уже сколько лет пришу проги в области экономике энергетики, и эта экономика тесно переплетается с техническими аспектами. Часто порывался применить ООП, даже кое что и набросал, но в итоге всегда приходил к процедуному варианту. Зачастую это происходило именно из-за добавления новых сущностей, и прочих мало поддающихся формализации вещей (приходится считаться и с ПРИНЯТЫМИ в данной предметной правилами). Единственное что можно написать используя ООП - это работа со справочниками.

← →
Alexandr (2002-09-30 08:51) [10]

да

← →
Johnny Smith (2002-09-30 09:52) [11]

2MsGuns © (27.09.02 21:12)
А если завтра объект "Работник" или "Подразделение" пополнятся новыми реквизитами, что мне, прикажете все классы переписывать со всеми сопутствующими траблами?
Актуально. Но все-таки лучше в ряде случаев переписать один раз соответствующий класс (например, метод, ответственный за сохранение информации в БД) в соответствующем юните...
Хотя, конечно, было бы классно иметь инструмент, отслеживающий изменения в структуре БД и переносящий ее в клиентские классы (размечтался!!!:))). Хотя надо бы посмотреть DelphiRoseLink...

← →
Sergey Masloff (2002-10-01 10:44) [12]

Применение ООП вполне возможно. В частности, и создание объектов предметной области. В этом случае в объектах можно реализовать значительную часть бизнес-правил, используя для этого все возможности языка, которые обычно превосходят возможности процедурных расширений SQL. Кроме того, при этом возможно значительно снизить нагрузку на сервер, основную часть работы перекладывая на клиента. Вобщем, подход жизнеспособный, опробован (в том числе и мной) на многих проектах. Но однозначно сказать что это лучше работы с DB-контролами нельзя - все зависит от ситуации ;-)

С уважением

← →
MsGuns (2002-10-01 11:16) [13]

>Sergey Masloff (01.10.02 10:44)
Согласен с Вами. Когда речь идет о разработке достаточно сложной "живой" модели данных, например, дерева состава заказов для серийного и мелкосерийного производства сложных приборов, есть прямой смысл потратить год (а может и не один), для формализации поведения звеньев (кто решал подобные вопросы, поймет меня с полуслова) как "живых объектов", имеющих вполне конкретные свойства и методы (наличие конструкторских изменений, расцеховка и т.д.).
Но для упрощенных задач, в частности бухгалтерских, кадрового учета и тому подобных, такие затраты не уместны. ИМХО

ООП и базы данных Найти похожие ветки