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

← →
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 вы не крутили?

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

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

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

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

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

← →
Kolan © (2007-09-24 11:05) [48]

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

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

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

← →
Eraser © (2007-09-24 11:17) [49]

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

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

← →
Игорь Шевченко © (2007-09-24 11:22) [50]

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

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

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

← →
Игорь Шевченко © (2007-09-24 11:22) [51]

Eraser © (24.09.07 11:17) [49]

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

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

← →
Kolan © (2007-09-24 11:29) [52]

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

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

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

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

← →
Kolan © (2007-09-24 11:30) [53]

> А SQL

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

← →
Игорь Шевченко © (2007-09-24 11:34) [54]

Kolan © (24.09.07 11:30) [53]

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

← →
Суслик © (2007-09-24 11:40) [55]

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

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

← →
Kolan © (2007-09-24 11:47) [56]

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

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

Я же пробую.

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

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

← →
Eraser © (2007-09-24 11:53) [57]

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

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

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

Eraser © (24.09.07 11:53) [57]

А собственно, почему крайности ?

хорошо, даже если допустить что в проекте несколько тысяч сущностей и для каждой сущности используется как минимум один 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]

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

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

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