![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Использовать или нет объекты спецификаций?
Kolan © (2007-09-18 08:50:00)Здравствуйте,
Если вы читали лармана, то наерно знаете про объекты спицификаций(specifications).
Допустим у меня есть объект Агде должен быть список других объектов Б. По сути те «другие» объекты Бявляются спецификациями.
Вопрос как организовать связь?
Я сделал так, что в объект А входит список Б, то есть не использовал спецификации. Сделал я это потому, что решил что с таким объектом удобнее работать. Например я передал его во вью и его отобразили. А если бы я использовал спецификации и связал бы его с помощью каккого-либо ID, например, то вью пришлось бы запрашивать спецификации для вывода объекта.
Плохо ли я поступил?
Что в этом полохого?
Как поступили бы вы?
Игорь Шевченко (2007-09-24 17:45:00) [1]Eraser © (24.09.07 11:53) [57]
> но и плодить объекты это тоже не выход, особенно когда дело
> дойдет до групповых операций и сложных апдейтов или выборок,
> все равно эти операции не завяжешь на объектах.
Групповые операции, сложные апдейты и выборки тоже могут быть методами объектов. Только других объектов, нес па ?
Eraser (2007-09-24 17:35:00) [2]
> Игорь Шевченко © (24.09.07 15:40) [61]
ok, допустим если отбросить все "но", то для работы с отдельными сущностями, в идеале, удобнее пользоваться классом-оберткой, но опять же вопрос [57] остается открытым, приходим к всё тем же query или модулю со списком функций редактирования/выборки.
Игорь Шевченко (2007-09-24 17:13:00) [3]Бакук © (24.09.07 16:04) [62]
> Имея объект, возможно я, изменяя объект домена (правильно
> я выразился?), ухожу от ошибок интерпретирования. Ухожу
> ли я от ошибок представления???
переведи :)
Бакук © (24.09.07 16:12) [63]
> А если логика в ХП? Шесть выборок (бывает и такое) хуже
> чем A.ObjectID.CarId.OwnerId = N, но создавать 4 объекта
> для такого?
Ничего не понял. Обычно для иллюстрации приводят примеры. Жду.
Бакук (2007-09-24 16:12:00) [4]
> Честно не понимаю, чем лучше. Проверки в операциях с классами
> делает компилятор, проверки в операциях с Query делает пользователь
> во время выполнения. А если использовать persistent fields
> то чем это, собственно, отличается от классов ?
А если логика в ХП? Шесть выборок (бывает и такое) хуже чем A.ObjectID.CarId.OwnerId = N, но создавать 4 объекта для такого?
> А SQL в «визуальных»(тех что лежат на форме) компонентах.
> А логика в событии какого нибудь грида… Вот уж где молодй
> опухнет.
А нафиг? А что, сейчас модно логику в .pas сувать?
Бакук (2007-09-24 16:04:00) [5]> Написав Query.FieldByName ты переложил диагностику ошибок с компилятора на конечного пользователя. Нафига ?
ОК. Я объявил поле явно. QueryID.AsString. Соответственно, все на компайлере. Конечно, изменяя поле сущности, я получаю ошибки компайлера. Имея объект, возможноя, изменяя объект домена (правильно я выразился?), ухожу от ошибок интерпретирования. Ухожу ли я от ошибок представления???
> Можно совет дать ? Ты сделай реальное приложение с использованием
> всех этих классов, моделей и прочего. Реальное, чтобы оно
> работало, а не только демонстрировало подход.
Да-да-да. Покажите. Не могу себя пересилить применить все это на Делфи :)))
Игорь Шевченко (2007-09-24 15:40:00) [6]Eraser © (24.09.07 15:28) [59]
Честно не понимаю, чем лучше. Проверки в операциях с классами делает компилятор, проверки в операциях с Query делает пользователь во время выполнения. А если использовать persistent fields то чем это, собственно, отличается от классов ?
Kolan (2007-09-24 15:34:00) [7]> хорошо, даже если допустить что в проекте несколько тысяч
> сущностей
Разных сущностей?. Тогда понадобится несколько тысяч запросов. А с использованием RAD Delphi, то и несколько тысяч компонентов
От количества не зависет сложность. Она примерно одинаковая
Eraser (2007-09-24 15:28:00) [8]хорошо, даже если допустить что в проекте несколько тысяч сущностей и для каждой сущности используется как минимум один TQuery, то это всё равно лучше, чем несколько тысяч классов )
Игорь Шевченко (2007-09-24 12:08:00) [9]Eraser © (24.09.07 11:53) [57]
А собственно, почему крайности ?
Eraser (2007-09-24 11:53:00) [10]
> Игорь Шевченко © (24.09.07 11:22) [51]
это крайности уже )
но и плодить объекты это тоже не выход, особенно когда дело дойдет до групповых операций и сложных апдейтов или выборок, все равно эти операции не завяжешь на объектах.
Kolan (2007-09-24 11:47:00) [11]> Реальное, чтобы оно работало, а не только демонстрировало
> подход.
Да, делаю. Завтра покажу. Основная проблемма шас это то как обновлять вью. Ведь собыие только одно «Я изменился», а что конкретно изменилось вью должен понимать сам
Я же пробую.
> сущностей только не менее 100000 штук, ну ладно хоть 10000.
Экземпляров? Я еще в [24] Kolan © (22.09.07 08:44) писал что тут засада и придется использовать DBAware. Сейчас в той программе что я пишу 100~200 экземпляров.
Суслик (2007-09-24 11:40:00) [12]
> Реальное, чтобы оно работало, а не только демонстрировало
> подход.
сущностей только не менее 100000 штук, ну ладно хоть 10000.
вот тогда и посмотрим :)
Игорь Шевченко (2007-09-24 11:34:00) [13]Kolan © (24.09.07 11:30) [53]
Можно совет дать ? Ты сделай реальное приложение с использованием всех этих классов, моделей и прочего. Реальное, чтобы оно работало, а не только демонстрировало подход.
Kolan (2007-09-24 11:30:00) [14]> А SQL
А когда это в SQL//
Kolan (2007-09-24 11:29:00) [15]> А если в проекте сотни Query ?
Угу и все они лежать на DataModule их названия невидно(перекрывают друг друга). И молодой разработчик(я) ничего понять не может.
Имхо
Машина.Колесо.Спустить(True)
гораздо понятнее чем
Query.SQL.Add('SELECT * FROM Car');
Query.Open;
Query.FieldByName('WheelState').AsBoolean := False
А SQL в «визуальных»(тех что лежат на форме) компонентах. А логика в событии какого нибудь грида Вот уж где молодй опухнет.
Игорь Шевченко (2007-09-24 11:22:00) [16]Суслик © (24.09.07 10:59) [47]
> Да нет, просто детство кончилось. Наигрался :)
Значит, Фаулеру с Ларманом осталось недолго ждать :) Удачи!
Игорь Шевченко (2007-09-24 11:22:00) [17]Eraser © (24.09.07 11:17) [49]
> для меня понятнее второй вариант, особенно если таких аналогов
> TCar несколько сотен в проекте, и для молодого спеца, который
> тебя рано или поздно заменит, тоже будет понятней 2 вариант.
>
А если в проекте сотни Query ?
Eraser (2007-09-24 11:17:00) [18]
> Можно мног чего делать. Domain нуже, имхо, в первую очередь
> для «сближения» программы с предметной областью. Согласиь
> понятнее когда перед тобой класс:TCar = class FWheel: array[0Ե]
> of TWheel; FSteeringWheel: TSteeringWheel;end;Чем когда
> ты видишь такое:Query.FieldByName('SteeringWheel').
для меня понятнее второй вариант, особенно если таких аналогов TCar несколько сотен в проекте, и для молодого спеца, который тебя рано или поздно заменит, тоже будет понятней 2 вариант.
Kolan (2007-09-24 11:05:00) [19]> а вот как купить
Как как вместе с BDS правда под .net.
Так а что по сабжу?.
Суслик (2007-09-24 10:59:00) [20]
> [46] Kolan © (24.09.07 10:57)
> > Заточенные под конкретные задачи фреймворки с материализацией
> > объектов не столь гибки
> А ECO вы не крутили?
я нет и пока не собираюсь ибо исходники у них закрыты.
и вообще - темное это дело, кто поддерживает понятно ( http://www.capableobjects.com), а вот как купить - не ясно. где исходники взять и пр.
> [45] Игорь Шевченко © (24.09.07 10:56)
> Суслик © (24.09.07 10:53) [44]
> Надо понимать, ты для себя открыл мир реляционных баз данных
> ? :)
Да нет, просто детство кончилось. Наигрался :)