Как модель предметной области совместить с гридом?

← →
by © (2004-11-18 14:02) [0]

Есть модель предметной области, есть классы. Класс который представляет одну сущность через маппер отражается на базе данных.
Например:
Класс БД
TBank.MFO BANK.MFO
OR Mapper
TBank.Name BANK.NAME
С эти примерно все понятно.
А как поступать с классами типа TBankList - которые представляют набор записей БД. Как это реализовать, чтобы использовать возможности гридов?

← →
clickmaker © (2004-11-18 14:05) [1]

> Как модель предметной области совместить с гридом?

через DataSet и DataSource

← →
Игорь Шевченко © (2004-11-18 14:07) [2]

> Как это реализовать, чтобы использовать возможности гридов?

Могу посоветовать завести промежуточный DataSet, например, ClientDataSet, настроить Grid на него, и заполнять этот DataSet элементами коллекции (с обратным преобразованием, разумеется)

← →
by © (2004-11-18 14:14) [3]

[2] Игорь Шевченко © (18.11.04 14:07)
Т.е. сначала данные из БД загружаются в объект, объекты формируют коллекцию, а коллекция заполняет Grid?
Но если объектов много (например 5-10 тыс и более), то не загнется ли все это? Как быть в случаях если объектов много?

← →
Игорь Шевченко © (2004-11-18 14:19) [4]

by © (18.11.04 14:14) [3]

> Как быть в случаях если объектов много?

Ограничивать выборку, разумеется. Какой смысл помещать в Grid 5-10 тысяч записей ?

← →
Суслик © (2004-11-18 14:24) [5]

А можно сначала попробовать - может и с 5-10 тыс нормально работать будет.
Тогда и делать ничего не надо.

← →
Суслик © (2004-11-18 14:33) [6]

Вот еще мое имхо...

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

← →
Суслик © (2004-11-18 14:32) [7]

← →
by © (2004-11-18 15:36) [8]

Есть задача:
Есть набор данных, список звонков абонентов, 3 млн. записей. Нужно по каждому звонку расчитать его стоимость, основываясь на данных абонента.
Если не городить трехзвенки, то есть два варианта:
1) попробовать засунуть логику и расчет в хранимую процедуру на сервере БД. Плюсы: близость к данным, нет лишнего трафика. Минусы: на сервере БД не все можно сделать, размазывается логика между клиентом и БД
2) Выбираем записи, формируем коллекцию объектов (а память где брать?), осуществляем расчеты и пишем объекты в БД

Кто как относится к этим методам? Или есть еще третий, четвертый?

← →
clickmaker © (2004-11-18 15:38) [9]

> [8] by © (18.11.04 15:36)

а что есть такого в расчете стоимости, чего нельзя сделать на сервере БД?

← →
by © (2004-11-18 15:41) [10]

[9] clickmaker © (18.11.04 15:38)
Согласен, можно сделать практически все. Разве что кроме отображения прогресса выполнения )
Но как быть с размазыванием логики? Все выполнять на сервере?
Но тогда в чем выиграш от использования объектов если вся логика в БД?

← →
Игорь Шевченко © (2004-11-18 15:42) [11]

by © (18.11.04 15:36) [8]

Первый способ оптимальный.

← →
clickmaker © (2004-11-18 15:45) [12]

> [10] by © (18.11.04 15:41)
> [9] clickmaker © (18.11.04 15:38)
> Разве что кроме отображения прогресса выполнения )

Если поднапрячься, то и это можно. Через extended-хранилки и оповещение клиентов. Только стоит ли игра свеч.
В общем, согласен с [11]

← →
by © (2004-11-18 15:47) [13]

[11] Игорь Шевченко © (18.11.04 15:42)
[12] clickmaker © (18.11.04 15:45)

Т.е. зашиваем всю логику в БД, а клиент служит только для ввода данных и их представления через вызовы соответствующих хранимок?

← →
clickmaker © (2004-11-18 15:52) [14]

> [13] by © (18.11.04 15:47)

Ну я бы задачу ставил так: если для обработки данных не нужно их присутствие на клиенте и саму обработку можно организовать средствами сервера БД, то на клиент данные тянуть нет смысла.
Т.е. обсчитал то что нужно, потом с клиента параметрический запрос, чтоб урезать выборку - и смотри скока влезет

[2] Игорь Шевченко © (18.11.04 14:07)

> Как это реализовать, чтобы использовать возможности гридов?
Могу посоветовать завести промежуточный DataSet, например, ClientDataSet, настроить Grid на него, и заполнять этот DataSet элементами коллекции (с обратным преобразованием, разумеется)

А кто нибудь встречал реализацию подобного ввиде статьи в инете или чего либо в электронном виде? Или в какой-то книге (кроме Архитектуры Фаулера, её читаю)

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

[16] Суслик © (18.11.04 16:17)
А если откинуть то что это биллинг? то тоже лучше все на сервере?
А в каких случаях лучше отказаться от логики на сервере?

> А в каких случаях лучше отказаться от логики на сервере?

только если ее не реализовать средствами sql. Но на этот счет как раз и есть трехзвенка.
Вообще, дешевле увеличивать мощность одного сервера, чем всех клиентских тачек. Кроме того, обновление и поддержка системы упрощаются.

by © (18.11.04 15:59) [15]

> А кто нибудь встречал реализацию подобного ввиде статьи
> в инете или чего либо в электронном виде?

У Фаулера может быть, точно сказать не могу. Я делал подобную реализацию для отображения объекта (одного) с подчиненными коллекциями (разумеется, количество элементов коллекций было разумным) еще до того, как ознакомился с упоминаемой книгой Фаулера.

> А в каких случаях лучше отказаться от логики на сервере?

Ни в каких, кроме контроля ввода от пользователя.

Как модель предметной области совместить с гридом? Найти похожие ветки