Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Использовать или нет объекты спецификаций?

Страницы: < 1 2 3 4 >
Kolan © (2007-09-18 08:50:00)
Здравствуйте,
Если вы читали лармана, то наерно знаете про объекты спицификаций(specifications).

Допустим у меня есть объект Агде должен быть список других объектов Б. По сути те «другие» объекты Бявляются спецификациями.

Вопрос как организовать связь?

Я сделал так, что в объект А входит список Б, то есть не использовал спецификации. Сделал я это потому, что решил что с таким объектом удобнее работать. Например я передал его во вью и его отобразили. А если бы я использовал спецификации и связал бы его с помощью каккого-либо ID, например, то вью пришлось бы запрашивать спецификации для вывода объекта.

Плохо ли я поступил?
Что в этом полохого?
Как поступили бы вы?

Kolan (2007-09-24 10:57:00) [21]
> Заточенные под конкретные задачи фреймворки с материализацией
> объектов не столь гибки

А ECO вы не крутили?

Игорь Шевченко (2007-09-24 10:56:00) [22]
Суслик © (24.09.07 10:53) [44]

> ну это же сплошь и рядом бывает.

Не спорю. Но компилятор обнаруживает ошибки а) быстрее б) автоматически
Что есть лучше.

> 1. БД куда более гибки и унивесальны. На БД и классическом
> подходе можно хоть сразу начинать разработку.

Надо понимать, ты для себя открыл мир реляционных баз данных ? :)

Суслик (2007-09-24 10:53:00) [23]

> Написав Query.FieldByName ты переложил диагностику ошибок
> с компилятора на конечного пользователя. Нафига ?

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

если говорить о

классическая реляционная БД
vs
домены с моделями,

то мое и не имхо заключается в том, что:
1. БД куда более гибки и унивесальны. На БД и классическом подходе можно хоть сразу начинать разработку.
2. Заточенные под конкретные задачи фреймворки с материализацией объектов не столь гибки, но в силу своей заточенности позволяют экстремально быстро разрабатывать те самые конкретные задачи.

Игорь Шевченко (2007-09-24 10:47:00) [24]
Суслик © (22.09.07 10:31) [27]

> молодо-зелено :)

Золотые слова!

> дальше приходит понимание, что ООП нужно учиться пользоваться,
> а не просто считать необходимость ООП неоспоримой истиной.
>

Дважды золотые слова!

Игорь Шевченко (2007-09-24 10:44:00) [25]
Бакук © (22.09.07 10:17) [26]

> Ну удобство заключается в том, что я могу обратиться как
> [b]Car.Wheel.Id[/b]? Однако сомневаюсь, что [b]Query.FieldByName()[/b]
> это непонятно

Написав Query.FieldByName ты переложил диагностику ошибок с компилятора на конечного пользователя. Нафига ?

Игорь Шевченко (2007-09-24 10:42:00) [26]
Бакук © (22.09.07 08:32) [23]

> Зачем делать лишнее действие? Сфетчить данные, заполнить
> ClientDataset и вывести в грид?

Откуда фетчить ? Я вроде упоминал список объектов, а не набор данных где-либо. Отдель фетчить их входного XML-файла, отдельно фетчить из какого-нибудь legacy-формата, отдельно фетчить из базы данных ? Не много ли отдельных фетчей ?

> Не все же материализуете? Выборочно? Каким критерием вы
> пользуетесь при выборке? Какой плюс?

Критерий один - если объект нужен, он материализуется. Плюс тоже налицо, не было объекта - стал объект.

> По сути в обычные контролы можно вывести так же поля Датасета
> без создания объекта

Можно. А нафига ?

Суслик © (22.09.07 00:27) [22]

> У меня приятель сейчас работает в конторе, где проекты содержат
> модули от Unit1 до Unit99 (может больше). Контролы называются
> соответственно - Label1 и пр.

А Шаляпина твой приятель не поет ?

Kolan (2007-09-24 10:28:00) [27]
> Работает так:

Тут http://www.rsdn.ru/article/patterns/generic-mvc.xmlесть риуночег.

Kolan (2007-09-24 10:27:00) [28]
Кто что инстанцирует:

Для объектов модели я завожу менеджера, который их создает, удаляет и отдает по требованию.

Работает так:
Событие в форме говорит контроллеру SetFalseToMode.
Контроллер лезет в Менеджер предм. области и получает там объект.
Изменяет полученый объект.
Все подключеные к объекту вью получают сообщение и перерисовываются.

Кто подключает вью к объектам?
Обычно это делается на старте приложения. Для этого служит спец. StartUpController…

Kolan (2007-09-24 10:23:00) [29]
Тю, так у меня есть тестовый проектик. Как раз подходит для демонстрации.

Модель:
TStringKeeper = class(TCustomDomainObject) private FB: Boolean; procedure SetB(const Value: Boolean); public property B: Boolean read FB write SetB; end;

View:

TLabelView = class(TCustomDomainObject) strict private FLabel: TLabel; public constructor Create(ALabel: TLabel); procedure Update(ASubject: TCustomDomainObject); override; end;

Единственное тут нет контроллера(маленький пример):
procedure TForm1.OffButtonClick(Sender: TObject); begin FStringKeeper.B := False; end;

Обычно контролле — это синглетон в данном случае c контроллером было бы так:

procedure TForm1.OffButtonClick(Sender: TObject); begin TController.GetInstance.SetFalseToMode;TController.GetInstance.SetFalseToMode; end;

Anatoly Podgoretsky (2007-09-24 10:10:00) [30]
> Суслик (24.09.2007 10:04:35) [35]

этого бояться не надо, если умеешь быстро и далеко бегать.

Kolan (2007-09-24 10:09:00) [31]
Лучьше растянуть получения по ушам, чтобы не так больнобыло, поэтому скажу что все объекты предментной области наследники вот такого класса(мож я его уже чуть доработал, но это неважно):

TCustomDomainObject = class private FObservers: TCustomDomainObjectList; FAllowChangeNotification: Boolean; FChanged: Boolean; FUpdateObserverOnAttach: Boolean; procedure SetAllowChangeNotification(const Value: Boolean); protected procedure NotifyObservers; public constructor Create; destructor Destroy; override; procedure Attach(AObserver: TCustomDomainObject); procedure Detach(AObserver: TCustomDomainObject); procedure Update(ASubject: TCustomDomainObject); virtual; abstract; property AllowChangeNotification: Boolean read FAllowChangeNotification write SetAllowChangeNotification; published property UpdateObserverOnAttach: Boolean read FUpdateObserverOnAttach write FUpdateObserverOnAttach default True; end;

Суслик (2007-09-24 10:04:00) [32]

> Заодно по ушам получу :)

этого бояться не надо.

Kolan (2007-09-24 09:55:00) [33]
> Тема действительно интересная

Выделю. Там и так выделено дальше некуда. Заодно по ушам получу :) и комментарии что это изврат :)… Жаль нет с собой проекта…

Суслик (2007-09-24 09:53:00) [34]

> [32] Kolan © (24.09.07 08:43)
> > И все же, покажите делфийский пример использования например
>
> > MVC?
>
> Завтра покажу части из реального проекта.

Во-во, мне тоже очень интересно. Только пожалуйста, подготовься. Ну там выдели, где model, где view, а где controller. Тема действительно интересная, ибо MVC лучше всего подходит имхо в вебе. Там все как-то более ясно, что есть что. А вот в дельфи? Model, Controller - поди отдели их друг от друга.

Kolan (2007-09-24 08:43:00) [35]
> И все же, покажите делфийский пример использования например
> MVC?

Завтра покажу части из реального проекта.

Бакук (2007-09-24 02:21:00) [36]
И все же, покажите делфийский пример использования например MVC? Для ломки мировоззрения. Ибо я читаю Суслика и абсолютно с ним соглашаюсь.

Суслик (2007-09-22 23:56:00) [37]
Може потому, что не сталкивался никогда? :)
Может логику можно на сервере держать?

Kolan (2007-09-22 11:02:00) [38]
> в дельфи же это баловство — материализовать объекты. подозреваю,
> что фича ради фичи.

Нетпросто я так привых делать. Я раньше с БД никогда не сталкивался, поэтому тучи запросов в DataModule все в кучу(логика в формах) для меня диковато смотриться.

Суслик (2007-09-22 10:46:00) [39]

> Kolan © (22.09.07 08:44) [24]
> От вас не ожидал… Все красоты ООП для экономии времени.

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

я сейчас переписываю старый проект. сколько же там красот ООП, которые ни разу не пригодились за 9 лет. а вы говорите экономия - я же на эти красоты потратил то самое время.

Суслик (2007-09-22 10:31:00) [40]

> Kolan © (22.09.07 08:44) [24]
> От вас не ожидал… Все красоты ООП для экономии времени.

молодо-зелено :)
работать нужно в рамках той библиотеки, которую используешь.
если библиотека использует mvc, то это должно быть mvc, если как в vcl, то нужно использовать как в vcl.

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

в дельфи же это баловство - материализовать объекты. подозреваю, что фича ради фичи.

кстати, заметь, я не отрицаю возможность иметь полноценный Object Persistant Framework. у меня именно такой. но это есть полная противоположность стандартным компонентам дельфи для общения с БД. у меня не используется ни один - ни dbgrid ни datasource (так вроде называется, не помню ибо никогда не использовал). так вот моя ситуация имеет право на жизнь, ибо в ней присутвует полноценная своя парадигма без наслаивания на чужеродную парадигму.

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »