Структура приложение на Delphi + MS SQL

← →
sD © (2008-07-14 16:11) [0]

Собираюсь писать объемное приложение на Delphi + MS SQL. Как лучше организовать его по структуре? На мой взгляд удобнее всего описать классы, каждый из которых будет работать (выполнять запросы к базе данных) с определенным объектом (Пример: Сотрудник, Компания) Тогда в каком виде должны возвращать они информацию? Спасибо.

← →
Поросенок Винни-Пух © (2008-07-14 16:24) [1]

в понятном виде

← →
Johnmen © (2008-07-14 16:30) [2]

> Тогда в каком виде должны возвращать они информацию?

Кто "они"?

← →
Поросенок Винни-Пух © (2008-07-14 16:40) [3]

ну непятно штоле?
классы!

← →
sD © (2008-07-14 16:44) [4]

Есть у кого-нибудь пример кода класса работы с MS SQL на delphi? или может кто ссылочку кинет. спасибо.

← →
Поросенок Винни-Пух © (2008-07-14 16:46) [5]

Есть. TTable например.

← →
sD © (2008-07-14 16:48) [6]

Если не трудно скиньте на мыло sputnik097@mail.ru. Спасибо.

← →
Поросенок Винни-Пух © (2008-07-14 16:54) [7]

тебе от какой делфи скинуть?

← →
sD © (2008-07-14 17:03) [8]

delphi 7

← →
Плохиш © (2008-07-14 17:09) [9]

> sD © (14.07.08 17:03) [8]

Может стоит всё-таки книжку-какую для начала почитать?

← →
sD © (2008-07-14 17:13) [10]

Например? Если порекомендуете хорошую, буду рад!

← →
Плохиш © (2008-07-14 17:19) [11]

Судя по этой ветке, начать можно с "Делфи за 21 секунду для полных чайников".

← →
sD © (2008-07-14 17:24) [12]

Удалено модератором

← →
Johnmen © (2008-07-14 17:41) [13]

> Собираюсь писать объемное приложение

С объемным ты явно погорячился. Да и с писательством тоже торопиться не надо...

← →
Dennis I. Komarov © (2008-07-14 17:45) [14]

Это мода такая чтоли пошла? :( Классы - круто!!! Давайте писать классы. Завтра модным станут компоненты, а после консольные приложения....

Классы надо там где они надо, ровно как и все остальное

← →
clickmaker © (2008-07-14 17:55) [15]

> а после консольные приложения....

это не мода, это классика -)

← →
Поросенок Винни-Пух © (2008-07-14 17:57) [16]

Нееееее.
Классы с объектами в БД это отдельная пестня.
:)

← →
Kolan © (2008-07-14 17:58) [17]

Начните с Файлера и Лармана.

← →
Kolan © (2008-07-14 17:58) [18]

Фаулера

← →
Украинец (2008-07-14 18:05) [19]

> sD © (14.07.08 16:11)
>
> Собираюсь писать объемное приложение на Delphi + MS SQL.
> Как лучше организовать его по структуре? На мой взгляд
> удобнее всего описать классы, каждый из которых будет работать
> (выполнять запросы к базе данных) с определенным объектом
> (Пример: Сотрудник, Компания) Тогда в каком виде должны
> возвращать они информацию? Спасибо.

Не пробуйте писать ORM на Delphi пока не познаете полностью объектную парадигму и реляционную алгебру (именно познаете на опыте, а не просто прочитаете).

Если уж хотите ORM, то возьмите Java, Hibernate и в качестве фронтенда SWING. Среда разработки подойдёт Netbeans. А потом уже сможете перенести на Delphi если захотите вернутся.

← →
Kolan © (2008-07-14 18:10) [20]

> А потом уже сможете перенести на Delphi если захотите вернутся.

Расширение у фалов на

← →
Kolan © (2008-07-14 18:10) [21]

Расширение у фалов на pas поменять и все :)

← →
SergeyIT © (2008-07-14 19:08) [22]

> sD © (14.07.08 16:11)
> Собираюсь писать объемное приложение...

Я бы начал с плоского, то есть без Delphi и MS SQL - набросать небольшое, но подробное, ТЗ на бумаге.

← →
sD © (2008-07-15 13:35) [23]

> Это мода такая чтоли пошла? :( Классы - круто!!! Давайте
> писать классы. Завтра модным станут компоненты, а после
> консольные приложения....Классы надо там где они надо, ровно
> как и все остальное

Спасибо за ответ! Классы я считаю удобны здесь, потому что вся работа с базой данных с одним объектом будет находиться в одном месте, а не разбросана везде, что упростит модернизацию, тестирование и отладку. Какие Ваши идеи к этому? С другой стороны трудно приставляю работы классов с технологией и компонентами ADO.

Приложение должно быть написано на delphi, для этого есть свои основания.

← →
Поросенок Винни-Пух © (2008-07-15 13:43) [24]

что вся работа с базой данных с одним объектом будет находиться в одном месте

Кому от этого "одного места" хорошо?
Никому кроме чувства прекрасного.
Допустим ты нарисовал класс инкапсулирующий клиента.
Все чотко. Получаем клиента, читаем/пишем свойства вызываем методы.
Тут обнаруживается, что нужна групповая операция по нескольким клиентам.

Ты:
- рисуешь еще один класс так как первый класс заточен на единственного клиента и работает по его id

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

- забиваешь на классы и пишешь банальный апдейт.

Твой выбор?

← →
Sergey13 © (2008-07-15 13:46) [25]

> [23] sD © (15.07.08 13:35)
> потому что вся работа с базой данных с одним объектом
> будет находиться в одном месте

Это конечно хорошо, только вот работа с объектом бывает разная. Учитывать ВСЕ варианты в классе? Не превратится ли класс в неповоротливого монстра?
ИМХО.

← →
sD © (2008-07-15 13:50) [26]

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

← →
Поросенок Винни-Пух © (2008-07-15 13:52) [27]

Еще один вопрос:

Что делать с dataaware контролами и сервисом ими предоставляемым?
Отказываться ради "одного места"?

> [26] sD © (15.07.08 13:50)
> чтобы было удобно в дальнейшем модернизовать приложение?

А что ты понимаешь под удобством?

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

> А что ты понимаешь под удобством?

К примеру, вдруг измениться структура базы данных (тьфу-тьфу) и все запросы нужно менять!

а у тебя типа не надо будет менять

> [30] sD © (15.07.08 14:08)
> К примеру, вдруг измениться структура базы данных (тьфу-
> тьфу) и все запросы нужно менять!

Обязательно изменится (и не говори, что тебя не предупреждали) и обязательно нужно будет менять. При чем чем больше "объемность" приложения, тем больше менять.
Поэтому я бы в начале сосредоточился как раз на проектировании БД и грамотного разделения клиентской и серверной логики (если так можно выразиться).

> К примеру, вдруг измениться структура базы данных (тьфу-
> тьфу) и все запросы нужно менять!
>

Используйте хранимые процедуры.

> [33] Ega23 © (15.07.08 14:42)
> Используйте хранимые процедуры.

ХП хорошо спасает от изменения серверной логики. От смены структуры они спасают слабовато. ИМХО.

← →
Украинец (2008-07-15 15:46) [35]

> sD © (15.07.08 13:35) [23]
>
>
> > Это мода такая чтоли пошла? :( Классы - круто!!! Давайте
> > писать классы. Завтра модным станут компоненты, а после
> > консольные приложения....Классы надо там где они надо,
> ровно
> > как и все остальное
>
> Спасибо за ответ! Классы я считаю удобны здесь, потому что
> вся работа с базой данных с одним объектом будет находиться
> в одном месте, а не разбросана везде, что упростит модернизацию,
> тестирование и отладку. Какие Ваши идеи к этому? С другой
> стороны трудно приставляю работы классов с технологией и
> компонентами ADO.

Ты пришёл к технологии контроллера - выделенной функциональной единицы которая отвечает за корректное извлечение данных и их изменение (так как видел код в котором на ButtonClick и MouseUp писался в обработчике sql запрос, это жуть).

Его можно делать и процедурным, но лучше отдельный класс (инициализированный при старте приложения) который и будет возвращать уже подготовленные классы или датасеты, а также осуществлять нотификацию об изменениях через любой из механизмов нотификации.

http://ru.wikipedia.org/wiki/Model-view-controller

← →
Украинец (2008-07-15 15:48) [36]

> Ega23 © (15.07.08 14:42) [33]
>
>
> > К примеру, вдруг измениться структура базы данных (тьфу-
>
> > тьфу) и все запросы нужно менять!
> >
> Используйте хранимые процедуры.

Это только один из вариантов/частей контроллера. Лично я почти всегда обходился без хранимок и триггеров.

← →
девушка (2008-08-07 12:25) [37]

> ХП хорошо спасает от изменения серверной логики. От смены
> структуры они спасают слабовато. ИМХО.

очень даже спасают. если структура меняется не слишком сильно. и какие-то дополнения к бизнес-логике хорошо в них скрывать

> [37] девушка (07.08.08 12:25)

1. Нафига поднимать топики почти месячной давности?
2. Ну и как тебя спасет ХП, если вот например появился новый атрибут и с ним надо как-то работать?

> Его можно делать и процедурным, но лучше отдельный класс
> (инициализированный при старте приложения) который и будет
> возвращать уже подготовленные классы или датасеты, а также
> осуществлять нотификацию об изменениях через любой из механизмов
> нотификации.

Интересно, команента TDataModul не это ли делает...

Структура приложение на Delphi + MS SQL Найти похожие ветки