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

← →
Kolan © (2007-09-18 08:50) [0]

Здравствуйте,
Если вы читали лармана, то наерно знаете про объекты спицификаций(specifications).

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

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

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

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

← →
Anatoly Podgoretsky © (2007-09-18 08:57) [1]

> Kolan (18.09.2007 08:50:00) [0]

О чем ведешь речь.

← →
Kolan © (2007-09-18 09:02) [2]

О спецификациях. Про это Ларман писал в книге:
Craig_Larman_Applying_UML_and_patterns_SE

Смысл.
Допустим есть объект «товар»в супер маркете) у него должно быть описание, типа: «Морковь крупная заморская».

Дык вот, это описание можно поместить в «товар», но тогда если нет ни одного экземпляра, то потеряется и описание(спецификация), поэтому он советует сделать два объекта «товар» и «Спецификация товара» и связать их по ID(Integer).

Вот я НЕ поступил ка он советует  теперь волнуюсь&#133

← →
Anatoly Podgoretsky © (2007-09-18 09:07) [3]

> Kolan (18.09.2007 09:02:02) [2]

Ты про базы что ли?
Так это вопрос нормализации и проектирования.

← →
Anatoly Podgoretsky © (2007-09-18 09:07) [4]

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

← →
evvcom © (2007-09-18 09:14) [5]

> Как поступили бы вы?

Не бы, а поступаю, как учат классики.

← →
clickmaker © (2007-09-18 09:27) [6]

«Морковь крупная заморская» - это класс. Т.е. по сути и есть спецификация.
А пакет моркови - экземпляр.
Поэтому, правильно Ларман советует.

← →
Kolan © (2007-09-18 09:35) [7]

> Ты про базы что ли?

Да нет я о Domain.

Поэтому, правильно Ларман советует.
Знаю что правильно, но как тогда рисовать это все во вью?

У меня активная модель, которая уведомляет вью сама. Вот произошло изменение, вью получил конкретный «пакет моркови» и ему надо отобразить данные из этого экземпляра и + описание. Значит получив объект он полезет спрашивать (кого?) контроллер что-ли? Типа дай описания продукта с ID 124. Так?

← →
clickmaker © (2007-09-18 09:41) [8]

> активная модель, которая уведомляет вью сама

это как?

← →
Kolan © (2007-09-18 09:43) [9]

> это как?

Каждый объект домена реализует обозревателя и субъекта из паттерна observer. И вью тоже. При изменении модель рассылает уведомления&#133

← →
Kolan © (2007-09-18 15:44) [10]

А что вы на [7] не отвечаете?

← →
evvcom © (2007-09-19 09:10) [11]

> Вот произошло изменение, вью получил конкретный «пакет моркови»
> и ему надо отобразить данные

Ой, сколько неправильных слов. Я не знаю как в твоей загадочной СУБД, о которой ты молчишь как партизан, но во всех, с которыми я когда-либо сталкивался, view ничего не получает и тем более не отображает! View - это представление, запрос. Как запрос может что-то отобразить? Запрос выбирает из таблиц данные. А уведомления, имхо, в твоем случае должно получить клиентское приложение, после этого выполнить запрос из View, ну и отобразить результат. И что сложного в запросе с получением так называемой тобой спецификации? Ты про join слышал?

← →
Kolan © (2007-09-19 09:56) [12]

> Я не знаю как в твоей загадочной СУБД

Причем тут СУБД. У меня её нет. У меня есть Domain(Объекты уровня предметной области.)

> View  это представление, запрос.

Не о том говорим, я говорю о View из архитектурного паттерна Model-View-Controller, а вы о чем?

← →
Игорь Шевченко © (2007-09-19 10:48) [13]

> Дык вот, это описание можно поместить в «товар», но тогда
> если нет ни одного экземпляра, то потеряется и описание(спецификация),
> поэтому он советует сделать два объекта «товар» и «Спецификация
> товара» и связать их по ID(Integer).

Сделай, раз советует. Ни к чему людей обижать.

← →
evvcom © (2007-09-19 11:18) [14]

> а вы о чем?

Ну явно не об этом :)

← →
Суслик © (2007-09-19 11:26) [15]

> [10] Kolan © (18.09.07 15:44)
> А что вы на [7] не отвечаете?

ты проста такие умные вопросы ставишь, что и не понять.

я три года болел этими доменами, моделями предметной области, паттернами, ларманами, фаулерами и пр. баловство все это.
современная СУБД + правильная БД. вот где правда, брат.

и вообще - не видел ни одного удачного применения MVC в ЧИСТОМ виде. все равно V и C объединяют с большинстве случаев.

> Типа дай описания продукта с ID 124. Так?

справшиваей модель. при чем здесь controller.

← →
Суслик © (2007-09-19 11:34) [16]

> я три года болел этими доменами, моделями предметной области,
> паттернами, ларманами, фаулерами и пр. баловство все это.
> современная СУБД + правильная БД. вот где правда, брат.

(себя же процитирую :))

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

← →
Kolan © (2007-09-19 12:11) [17]

> справшиваей модель.

Да вроде логично. Надо бы нарисовать д. Взаимодействия,&#133 еще вопросы задам&#133

← →
Игорь Шевченко © (2007-09-19 16:22) [18]

> я три года болел этими доменами, моделями предметной области,
> паттернами, ларманами, фаулерами и пр. баловство все это.
>
> современная СУБД + правильная БД. вот где правда, брат

Баловство, конечно. Русский программист будет писать так, чтобы не было мучительно больно за бесцельно прожитые годы. А что будет после него - а комуэто нафиг надо, пусть теперь там поворочаются.

← →
Суслик © (2007-09-20 13:16) [19]

> [18] Игорь Шевченко © (19.09.07 16:22)
> Баловство, конечно. Русский программист будет писать так,
> чтобы не было мучительно больно за бесцельно прожитые годы.
> А что будет после него - а комуэто нафиг надо, пусть теперь
> там поворочаются.

вот, видишь, и ты так думаешь.

← →
Бакук © (2007-09-21 07:33) [20]

Объясните мне, каким образом вы применяте MVC в Делфи?
Недавно стал читать про «паттерны, фаулеры и MVC в частности» и понял, что на PHP я так и пишу. Разделяю вывод и обращение к БД. Каким образом это делать в Delphi?
Datamodule (Dataset + Datasource)  получение данных
Form (Grid с ссылкой на Datasource или DB Controls)  отображение информации
Это неверно? Зачем нагромождать проект? Ради того, чтобы было?

← →
Игорь Шевченко © (2007-09-21 12:40) [21]

Бакук © (21.09.07 07:33) [20]

Никаким образом не применяем. В Delphi есть механизм db-aware controls, яд которого проникает в мозг каждого разработчика и заставляет его игнорировать MVC.

Но, например, в ряде случаев, я предпочитаю материализовать объект по ключу из выбранной записи в том же гриде, и работать уже с объектом, отображая его данные безотносительно db-aware контролов или выполняя прочие действия. А иногда и грид отображает ClientDataSet, в котором записи формируются из списка объектов.

← →
Суслик © (2007-09-22 00:27) [22]

Проще надо быть.
У меня приятель сейчас работает в конторе, где проекты содержат модули от Unit1 до Unit99 (может больше). Контролы называются соответственно - Label1 и пр. Смотрел я этот код. Я может и ламо полное, но он меня не ввел в ужас - код, который делает дело, делает (насколько я знаю) неплохо. А то, что писан он, не то чтобы без MVC и прочих красот, так вообще без элементарной аккуратности, так это ничего - работает же. У кого есть лишнее время (я, например, страшно люблю красоты объектно-ориентированные) тот тратит это время. У кого нет, делает дело и не задумывается о красотах.

← →
Бакук © (2007-09-22 08:32) [23]

> А иногда и грид отображает ClientDataSet, в котором записи
> формируются из списка объектов.

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

> Но, например, в ряде случаев, я предпочитаю материализовать
> объект по ключу из выбранной записи в том же гриде, и работать
> уже с объектом, отображая его данные безотносительно db-
> aware контролов или выполняя прочие действия. А иногда и
> грид отображает ClientDataSet, в котором записи формируются
> из списка объектов.

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

> отображая его данные безотносительно db-aware контролов
> или выполняя прочие действия

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

← →
Kolan © (2007-09-22 08:44) [24]

> У кого есть лишнее время (я, например, страшно люблю красоты
> объектно-ориентированные) тот тратит это время.

От вас не ожидал&#133 Все красоты ООП для экономии времени.

> Объясните мне, каким образом вы применяте MVC в Делфи?

Имхо проблемма Delphi + MVC в части View. Если для отображения не нужны таблицы, то я ввобще обхожусь без DBAware контролов. Делаю DAL Domain View слои и контроллеры.

Если без DB Aware не обойтись, то все компоненты в DataModule скрываю за фасадом. Но опыта у меня мало всего 3 программы, так сделал.

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

Можно мног чего делать. Domain нуже, имхо, в первую очередь для «сближения» программы с предметной областью.
Согласиь понятнее когда перед тобой класс:

TCar = class FWheel: array[0&#1333] of TWheel; FSteeringWheel: TSteeringWheel; end;

Чем когда ты видишь такое:
Query.FieldByName("SteeringWheel").

← →
Kolan © (2007-09-22 08:47) [25]

> Не все же материализуете? Выборочно?

Да

> Каким критерием вы пользуетесь при выборке?

Необходимостью

Какой плюс?
Удобство, понятность для других программистов и для себя через месяц в первую очередь.

← →
Бакук © (2007-09-22 10:17) [26]

> Можно мног чего делать. Domain нуже, имхо, в первую очередь
> для «сближения» программы с предметной областью. Согласиь
> понятнее когда перед тобой класс:TCar = class FWheel: array[0Ե]
> of TWheel; FSteeringWheel: TSteeringWheel;end;Чем когда
> ты видишь такое:Query.FieldByName("SteeringWheel").

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

> Имхо проблемма Delphi + MVC в части View. Если для отображения
> не нужны таблицы, то я ввобще обхожусь без DBAware контролов.
> Делаю DAL Domain View слои и контроллеры.Если без DB Aware
> не обойтись, то все компоненты в DataModule скрываю за фасадом.
> Но опыта у меня мало всего 3 программы, так сделал.

Сильно будет нагло, если попрошу дать посмотреть какие-то обрыки, наброски? Для самообучения?

> Необходимостью

И все-таки, необходимостью чего?

← →
Суслик © (2007-09-22 10:31) [27]

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

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

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

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

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

← →
Суслик © (2007-09-22 10:46) [28]

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

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

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

← →
Kolan © (2007-09-22 11:02) [29]

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

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

← →
Суслик © (2007-09-22 23:56) [30]

Може потому, что не сталкивался никогда? :)
Может логику можно на сервере держать?

← →
Бакук © (2007-09-24 02:21) [31]

И все же, покажите делфийский пример использования например MVC? Для ломки мировоззрения. Ибо я читаю Суслика и абсолютно с ним соглашаюсь.

← →
Kolan © (2007-09-24 08:43) [32]

> И все же, покажите делфийский пример использования например
> MVC?

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

← →
Суслик © (2007-09-24 09:53) [33]

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

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

← →
Kolan © (2007-09-24 09:55) [34]

> Тема действительно интересная

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

← →
Суслик © (2007-09-24 10:04) [35]

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

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

← →
Kolan © (2007-09-24 10:09) [36]

Лучьше растянуть получения по ушам, чтобы не так больнобыло, поэтому скажу что все объекты предментной области наследники вот такого класса(мож я его уже чуть доработал, но это неважно):

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;

← →
Anatoly Podgoretsky © (2007-09-24 10:10) [37]

> Суслик (24.09.2007 10:04:35) [35]

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

← →
Kolan © (2007-09-24 10:23) [38]

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

Модель:
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;

← →
Kolan © (2007-09-24 10:27) [39]

Кто что инстанцирует:

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

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

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

← →
Kolan © (2007-09-24 10:28) [40]

> Работает так:

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

← →
Игорь Шевченко © (2007-09-24 10:42) [41]

Бакук © (22.09.07 08:32) [23]

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

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

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

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

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

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

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

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

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

← →
Игорь Шевченко © (2007-09-24 10:44) [42]

Бакук © (22.09.07 10:17) [26]

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

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

← →
Игорь Шевченко © (2007-09-24 10:47) [43]

Суслик © (22.09.07 10:31) [27]

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

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

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

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

← →
Суслик © (2007-09-24 10:53) [44]

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

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

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

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

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

← →
Игорь Шевченко © (2007-09-24 10:56) [45]

Суслик © (24.09.07 10:53) [44]

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

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

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

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

← →
Kolan © (2007-09-24 10:57) [46]

> Заточенные под конкретные задачи фреймворки с материализацией
> объектов не столь гибки

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

> [46] Kolan © (24.09.07 10:57)
> > Заточенные под конкретные задачи фреймворки с материализацией
> > объектов не столь гибки
> А ECO вы не крутили?

я нет и пока не собираюсь ибо исходники у них закрыты.
и вообще - темное это дело, кто поддерживает понятно (http://www.capableobjects.com), а вот как купить - не ясно. где исходники взять и пр.

> [45] Игорь Шевченко © (24.09.07 10:56)
> Суслик © (24.09.07 10:53) [44]
> Надо понимать, ты для себя открыл мир реляционных баз данных
> ? :)

Да нет, просто детство кончилось. Наигрался :)

> а вот как купить

Как как вместе с BDS правда под .net.

Так а что по сабжу?.

Суслик © (24.09.07 10:59) [47]

> Да нет, просто детство кончилось. Наигрался :)

Значит, Фаулеру с Ларманом осталось недолго ждать :) Удачи!

Eraser © (24.09.07 11:17) [49]

> для меня понятнее второй вариант, особенно если таких аналогов
> TCar несколько сотен в проекте, и для молодого спеца, который
> тебя рано или поздно заменит, тоже будет понятней 2 вариант.
>

А если в проекте сотни Query ?

> А если в проекте сотни Query ?

Угу и все они лежать на DataModule их названия невидно(перекрывают друг друга). И молодой разработчик(я) ничего понять не может.
Имхо
Машина.Колесо.Спустить(True)
гораздо понятнее чем

Query.SQL.Add("SELECT * FROM Car"); Query.Open; Query.FieldByName("WheelState").AsBoolean := False&#133

А SQL в «визуальных»(тех что лежат на форме) компонентах. А логика в событии какого нибудь грида&#133 Вот уж где молодй опухнет.

> А SQL

А когда это в SQL//

Kolan © (24.09.07 11:30) [53]

Можно совет дать ? Ты сделай реальное приложение с использованием всех этих классов, моделей и прочего. Реальное, чтобы оно работало, а не только демонстрировало подход.

> Реальное, чтобы оно работало, а не только демонстрировало
> подход.

сущностей только не менее 100000 штук, ну ладно хоть 10000.
вот тогда и посмотрим :)

> Реальное, чтобы оно работало, а не только демонстрировало
> подход.

Да, делаю. Завтра покажу. Основная проблемма шас это то как обновлять вью. Ведь собыие только одно «Я изменился», а что конкретно изменилось вью должен понимать сам&#133

Я же пробую.

> сущностей только не менее 100000 штук, ну ладно хоть 10000.

Экземпляров? Я еще в [24] Kolan © (22.09.07 08:44) писал что тут засада и придется использовать DBAware. Сейчас в той программе что я пишу 100~200 экземпляров.

> Игорь Шевченко © (24.09.07 11:22) [51]

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

хорошо, даже если допустить что в проекте несколько тысяч сущностей и для каждой сущности используется как минимум один TQuery, то это всё равно лучше, чем несколько тысяч классов )

> хорошо, даже если допустить что в проекте несколько тысяч
> сущностей

Разных сущностей?. Тогда понадобится несколько тысяч запросов. А с использованием RAD Delphi, то и несколько тысяч компонентов&#133

От количества не зависет сложность. Она примерно одинаковая&#133

Eraser © (24.09.07 15:28) [59]

Честно не понимаю, чем лучше. Проверки в операциях с классами делает компилятор, проверки в операциях с Query делает пользователь во время выполнения. А если использовать persistent fields то чем это, собственно, отличается от классов ?

>Написав Query.FieldByName ты переложил диагностику ошибок с компилятора на конечного пользователя. Нафига ?
ОК. Я объявил поле явно. QueryID.AsString. Соответственно, все на компайлере. Конечно, изменяя поле сущности, я получаю ошибки компайлера. Имея объект, возможно я, изменяя объект домена (правильно я выразился?), ухожу от ошибок интерпретирования. Ухожу ли я от ошибок представления???

> Можно совет дать ? Ты сделай реальное приложение с использованием
> всех этих классов, моделей и прочего. Реальное, чтобы оно
> работало, а не только демонстрировало подход.

Да-да-да. Покажите. Не могу себя пересилить применить все это на Делфи :)))

> Честно не понимаю, чем лучше. Проверки в операциях с классами
> делает компилятор, проверки в операциях с Query делает пользователь
> во время выполнения. А если использовать persistent fields
> то чем это, собственно, отличается от классов ?

А если логика в ХП? Шесть выборок (бывает и такое) хуже чем A.ObjectID.CarId.OwnerId = N, но создавать 4 объекта для такого?

> А SQL в «визуальных»(тех что лежат на форме) компонентах.
> А логика в событии какого нибудь грида… Вот уж где молодй
> опухнет.

А нафиг? А что, сейчас модно логику в .pas сувать?

Бакук © (24.09.07 16:04) [62]

> Имея объект, возможно я, изменяя объект домена (правильно
> я выразился?), ухожу от ошибок интерпретирования. Ухожу
> ли я от ошибок представления???

переведи :)

Бакук © (24.09.07 16:12) [63]

> А если логика в ХП? Шесть выборок (бывает и такое) хуже
> чем A.ObjectID.CarId.OwnerId = N, но создавать 4 объекта
> для такого?

Ничего не понял. Обычно для иллюстрации приводят примеры. Жду.

> Игорь Шевченко © (24.09.07 15:40) [61]

ok, допустим если отбросить все "но", то для работы с отдельными сущностями, в идеале, удобнее пользоваться классом-оберткой, но опять же вопрос [57] остается открытым, приходим к всё тем же query или модулю со списком функций редактирования/выборки.

Eraser © (24.09.07 11:53) [57]

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

Групповые операции, сложные апдейты и выборки тоже могут быть методами объектов. Только других объектов, нес па ?

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