Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это всё верно, но только для относительно простых случаев. Есть ещё несколько соображений. Например, юзер А тратит много времени на обновление какой-то записи ...

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

ГВ>Другой вариант. Запись (вернее — логический обновляемый объект) состоит из тучи мелких связанных записей, которые могут обновляться независимо (допустим — через drill-down навигацию), притом обновление одной из них может привести к недопустимости обновления агрегата, который при такой схеме и знать не будет о том, что какая-то его часть изменилась. Здесь вроде бы, логически, выход в том, чтобы вынести всю логику контроля целостности на... сервер БД и привет app-серверу как концепции, здравствуй расползание дизайна во все мыслимые и немыслимые стороны, а потому так делать нежелательно, следовательно разумный выход один — усложнять app-сервер.

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

Насчет выноса логики на сервер БД — это просто не реально. Особенно для IB. Мы не оперируем понятиями запись — ну если только речь не идет про таблицу типов. Значит проверить достоверность данных можно только имея доступ к объекту целиком (типа несколько записей). Как например, передать в хранимую процедуру составной документ, чтобы она его проверила и сохранила, я лично не представляю

App-сервер, это конечно позволит сделать, но.

• App-сервер вытаскивает данные (+ проверка прав и все такое)
  
• Упаковывает их в промежуточный формат (пусть XML) и передает клиенту
  
• Клиент получает пакет, распаковывает, выводит на экран
  
• Один черт, на клиенте должен крутится скрипт, который будет контролировать сам процесс редактирования документа — какую-то его часть можно редактировать, какую-то нет. Что сейчас, в принципе и делается.
  
• При нажатии на сохранить, клиент упаковывает запись, передает на app-сервер
  
• App-сервер распаковывает, проверяет, и пишет в базу данных.

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

ГВ>Теперь о том, что должен увидеть пользователь.

ГВ>Если запись захвачена им для просмотора, то хорошо бы её просто изменить, если для редактирования — то он не может увидеть сообщения о том, что запись кем-то изменена, поскольку она не может быть изменена кем-то. Единственный вариант, когда возможна такая ситуация — это при offline-транзакциях (захватили запись на изменение и отключились нафиг), которые сброшены сервером из-за превышения допустимого интервала времени между захватом записи и выполнением транзакции. Но здесь пользователь просто получит сообщение о прекращении транзакции и всё.

У нас минимизированы периоды активных транзакций. То есть загрузка/запись данных делается в разных "коротких" транзакциях, продолжительность которых пропорциональна объему данных. Это из-за специфики IB, который при длинных транзакциях, начинает накапливать мусор в базе данных.

А вообще, Генадий, будет у нас на Кол..., то есть Липецке — заходите в гости и все увидите своими глазами

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Один из способов, которые могут применить наши скриптеры (и применяют относительно документов), это использовать информацию о владении документом — из документооборота. Владелец может все. Другие (в зависимости от своих прав) этот объект либо совсем не смогут загрузить, либо загрузят его в режиме только на чтение.

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

КД>Насчет выноса логики на сервер БД — это просто не реально. Особенно для IB. Мы не оперируем понятиями запись — ну если только речь не идет про таблицу типов. Значит проверить достоверность данных можно только имея доступ к объекту целиком (типа несколько записей). Как например, передать в хранимую процедуру составной документ, чтобы она его проверила и сохранила, я лично не представляю

Ну, к слову, можно передать ключ временной копии документа, хранящейся в БД.

КД>App-сервер, это конечно позволит сделать, но.
КД>

[...]
КД>
• Один черт, на клиенте должен крутится скрипт, который будет контролировать сам процесс редактирования документа — какую-то его часть можно редактировать, какую-то нет. Что сейчас, в принципе и делается.
  
  Ну вот это тоже я и имел ввиду под словами "расползание дизайна". Часть логики у вас реализована в термиах App-сервера, часть — в терминах скриптов.
  [...]
  КД>

КД>Вообще, конечно мысль интересная. Особенно если логику app-сервера прописывать на интерпретируемом языке, но точно говорю — нам это пока не по-зубам. По крайней мере ближайший год-полтора это точно. Мы сейчас закручиваем гайки, которые не дают пользователям "шалить" в базе данных

Ну, тебе виднее...

КД>У нас минимизированы периоды активных транзакций. То есть загрузка/запись данных делается в разных "коротких" транзакциях, продолжительность которых пропорциональна объему данных. Это из-за специфики IB, который при длинных транзакциях, начинает накапливать мусор в базе данных.

Т.е., столкновение транзакций у вас не просто вероятно, а очень вероятно... Вероятность, впрочем, несколько снижается за счёт организационных мер, применяемых к пользователям. Не фонтан... ИМХО

КД>А вообще, Генадий, будет у нас на Кол..., то есть Липецке — заходите в гости и все увидите своими глазами

Нет уж, лучше вы — к нам. (c)

Здравствуйте, Геннадий Васильев, Вы писали:

КД>>Один из способов, которые могут применить наши скриптеры (и применяют относительно документов), это

ГВ>Т.е., скрипт проверяет содержимое полей объекта на предмет соответствия их каким-то условиям и в зависимости от этих условий выполняет те или иные действия. Так?
Точно.

КД>>Насчет выноса логики на сервер БД — это просто не реально. Особенно для IB. Мы не оперируем

ГВ>Ну, к слову, можно передать ключ временной копии документа, хранящейся в БД.
О нет. Это же два раза писать в базу, а потом еще и копию удалять. Мне кажется это накладно

KD>Один черт, на клиенте должен крутится скрипт, который будет контролировать сам процесс редактирования документа — какую-то его часть можно редактировать, какую-то нет. Что сейчас, в принципе и делается.
ГВ>Ну вот это тоже я и имел ввиду под словами "расползание дизайна". Часть логики у вас реализована в термиах App-сервера, часть — в терминах скриптов.
По другому пока не получается. А может просто нужно это все как-то иначе назвать . Хотелось бы чтобы название было цензурным

ГВ>Т.е., столкновение транзакций у вас не просто вероятно, а очень вероятно... Вероятность, впрочем, несколько снижается за счёт организационных мер, применяемых к пользователям. Не фонтан... ИМХО

Мне кажется, что опасность конфликтов между пользователями очень преувеличена. По крайней мере за пол-года эксплуатации у нас не было не одной подобной проблемы. Хотя это не значит что у нас все пущено на самотек

А используя длинные транзакциями, мы бы точно огребли кучу непрятностей.

ГВ>Нет уж, лучше вы — к нам. (c)
Как только — так сразу

Здравствуйте, DemAS, Вы писали:

DAS> Есть база данных. В ней есть таблицы. Талицы справочники представляют собой какие-то сущности: например — поставщики, товары, адреса....
DAS> Есть программа, которая работает с базой данных. По хорошему, как я понимаю, все эти сущности из БД должны каким-то образом отображаться на классы в программе. То есть у меня в программе должны присутствовать классы Поставщик, Товар, Адрес. Более того, как я понимаю, все изменения в БД должны происходит через методы этих объектов. То есть продажа товара поставщику должна происходить примерно так: Поставщик.Sale(Товар), а уже реализация этого метода должна вызывать измениея в БД.
DAS> Как я понимаю, это общепринятая практика ? По моему, если я не ошибаюсь, именно это называется mapping. Это так ?
DAS> Где можно почитать про способы, подходы, рекомендации реализации этой идеи.

Посмотрите СУБД Cache www.cache.ru. Эта объектно-реляционная СУБД умеет отображать свои таблицы на C++ классы автоматически. И вообще много чего еще умеет полезного.

Мля, едрить.
Несколько недель разрабатывал архитектуру по подобной теме... С нуля. Сделал, даже некую теорию под такой расклад построил. Получилось практичеки один в один по твоему ответу, в плоть до того что тоже использовал COM-объекты...
И что мне сказало начальство?
"Слишком много философии, мы не занимаемся ресёчем, проще всё должно быть". Сделали "проще" — смотреть код противно.

Здравствуйте, DemAS, Вы писали:

DAS> Есть программа, которая работает с базой данных. По хорошему, как я понимаю, все эти сущности из БД должны каким-то образом отображаться на классы в программе.

Я однажды написал програмку, которая коннектилась к схеме Оракловой СУБД, считывала все метаданные и генерировала исходный код (на Delphi) классов всех объектов со всеми взаимными ссылками между объектами. Впридачу генерила классы соответствующие таблицам и умеющие загружать свои данные из БД, и даже умеющая сортировать их по всем полям; и еще рисовать свое содержимое в TStringGrid-ах. Запускаешь такую прогу, получаешь исходник. Компилишь исходник получаешь программу которая может законнектиться к СУБД и выкачать из нее все данные в виде объектов со всеми взаимными ссылками и показать их все в стринг-гридах с возможностью отсортировать по разным столбцам. Потом я приостановил работу над этой прогой — у начальства она не вызвала приступа энтузиазма, мне поручили заниматься другими вещами.

Здравствуйте, DemAS, Вы писали:

DAS> Есть база данных. В ней есть таблицы. Талицы справочники представляют собой какие-то сущности: например — поставщики, товары, адреса....
DAS> Есть программа, которая работает с базой данных. По хорошему, как я понимаю, все эти сущности из БД должны каким-то образом отображаться на классы в программе. То есть у меня в программе должны присутствовать классы Поставщик, Товар, Адрес. Более того, как я понимаю, все изменения в БД должны происходит через методы этих объектов. То есть продажа товара поставщику должна происходить примерно так: Поставщик.Sale(Товар), а уже реализация этого метода должна вызывать измениея в БД.
DAS> Как я понимаю, это общепринятая практика ? По моему, если я не ошибаюсь, именно это называется mapping. Это так ?
DAS> Где можно почитать про способы, подходы, рекомендации реализации этой идеи.

http://www.a-lexandr.hotbox.ru/index.html#okp

Здравствуйте, DemAS, Вы писали:

DAS> Есть база данных. В ней есть таблицы. Талицы справочники представляют собой какие-то сущности: например — поставщики, товары, адреса....
DAS> Есть программа, которая работает с базой данных. По хорошему, как я понимаю, все эти сущности из БД должны каким-то образом отображаться на классы в программе. То есть у меня в программе должны присутствовать классы Поставщик, Товар, Адрес. Более того, как я понимаю, все изменения в БД должны происходит через методы этих объектов. То есть продажа товара поставщику должна происходить примерно так: Поставщик.Sale(Товар), а уже реализация этого метода должна вызывать измениея в БД.
DAS> Как я понимаю, это общепринятая практика ? По моему, если я не ошибаюсь, именно это называется mapping. Это так ?
DAS> Где можно почитать про способы, подходы, рекомендации реализации этой идеи.

Мартин Фаулер "Архитектура корпоративных приложений"
Издательский дом "Вильямс" 2004

Подробно описаны типовые решения задач проектирования корпоративных приложений.

Здравствуйте, Roman Avramov, Вы писали:

RA>очень советую книжку Фаулера. сейчас на в открытом доступе остался только каталог:
RA>http://martinfowler.com/eaaCatalog/, но у меня осталась выкачанная бета-версия. надо — могу прислать.

И мне пожалуйста, если несложно. Заранее спасибо.

Здравствуйте, Roman Avramov, Вы писали:

RA>очень советую книжку Фаулера. сейчас на в открытом доступе остался только каталог:
RA>http://martinfowler.com/eaaCatalog/, но у меня осталась выкачанная бета-версия. надо — могу прислать.

А ящик забыл указать

Здравствуйте, KBH, Вы писали:

KBH>Здравствуйте, Roman Avramov, Вы писали:

RA>>очень советую книжку Фаулера. сейчас на в открытом доступе остался только каталог:
RA>>http://martinfowler.com/eaaCatalog/, но у меня осталась выкачанная бета-версия. надо — могу прислать.

KBH>И мне пожалуйста, если несложно. Заранее спасибо.

На Соколе в доме книги видел несколько дней назад. Если что..

Здравствуйте, g_i, Вы писали:

g_i>На Соколе в доме книги видел несколько дней назад. Если что..

Я в Краснодаре живу, если что.

Здравствуйте, Roman Avramov, Вы писали:

RA>очень советую книжку Фаулера. сейчас на в открытом доступе остался только каталог:
RA>http://martinfowler.com/eaaCatalog/, но у меня осталась выкачанная бета-версия. надо — могу прислать.

и, мне пожалуйста, на a_lexandr@mail.ru

Здравствуйте, KBH, Вы писали:

KBH>Здравствуйте, g_i, Вы писали:

g_i>>На Соколе в доме книги видел несколько дней назад. Если что..

KBH>Я в Краснодаре живу, если что.
Мдя. Ну там и воздух чище и климат мягше зато . Можно заказать доставку, наверное, с какого-нить интернет магазина. Только дорого выйдет (сама книжень недешевая + тяжелая, зараза — почта вроде по весу стоимость доставки определяет ).

Здравствуйте, g_i, Вы писали:

g_i>Мдя. Ну там и воздух чище и климат мягше зато . Можно заказать доставку, наверное, с какого-нить интернет магазина. Только дорого выйдет (сама книжень недешевая + тяжелая, зараза — почта вроде по весу стоимость доставки определяет ).

Как книга хоть называется?

Здравствуйте, KBH, Вы писали:

..
KBH>Как книга хоть называется?

Мартин Фаулер "Архитектура корпоративных приложений"
Издательский дом "Вильямс" 2004
ISBN 5-8459-0579-6(рус)

Здравствуйте, c-smile, Вы писали:

CS>collection read(id request, collection parameters)
CS>collection write(id request, collection parameters)

Как я понимаю, эта сладкая парочка представляет собой шлюз к stateless-серверу.

Предлагаю дальнейшее развитие идеи:

1) Проектируем интерфейсы всех сущностей домена. Получаем их определения на языке IDL.
2) С каждой сущностью связываем OID
3) По исходному IDL генерируем IDL для удаленного доступа, следующим образом:

пусть исходный интерфейс имеет вид:

interface ISomeEntity: IUnknown
{
    [id(1)] HRESULT Do1([in] Arg1 a, [in] Arg2 b);
    [id(2)] HRESULT Do2([in] Arg3 c, [out,retval] Arg4 d);
};

тогда для него генерируем удаленный интерфейс:

interface IRemoteSomeEntity: IUnknown
{
    [id(1)] HRESULT Do1([in] OID_t instanceId, [in] Arg1 a, [in] Arg2 b);
    [id(2)] HRESULT Do2([in] OID_t instanceId, [in] Arg3 c, [out,retval] Arg4 d);
};

4) Для каждого удаленного интерфейса автоматически генерируем такую реализацию:

HRESULT IRemoteSomeEntityImpl::Do1(OID_t instanceId, Arg1 a, Arg2 b)
{
   m_database->begin_transaction();
   ISomeEntity* p = m_database->activate_object(instanceId);
   HRESULT hr = p->Do1(a, b);
   m_database->end_transaction();
   return hr;
}

HRESULT IRemoteSomeEntityImpl::Do2([in] OID_t instanceId, [in] Arg3 c, [out,retval] Arg4 d)
{
   m_database->begin_transaction();
   ISomeEntity* p = m_database->activate_object(instanceId);
   HRESULT hr = p->Do2(c, d);
   m_database->end_transaction();
   return hr;
}

5) Все эти реализации объединяем в одном синглетоне, делая их доступными через QueryInterface. Сам синглетон оформляем как кокласс.
В результате получаем абстрактную реализацию stateless application server.

6) Автоматически генерируем код маршаллинга интерфейсов IRemoteXXX. В результате одним вызовом CoCreateInstanceEx клиент получает через MULTI_QI все, что ему нужно для работы с сервером.

7) Серверу остается реализовать повторно используемый класс m_database, и классы реализации локальных интетфейсов для каждой сущности домена, типа class SomeEntity: public ISomeEntity, и т.п.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Преимущества:
1) Фактически это тоже шлюз, который жрет под себя очень ограниченное количество ресурсов, и обеспечивает такую же производительность и прочие преимущества шлюза.
2) Достаточно спроектировать интерфейсы сущностей, все остальное сгенерируется автоматически по этим интерфейсам.
3) Гораздо проще вносить изменения в интерфейсы.
4) Проект оказывается лучше структурирован, и может вырастать до более крупных размеров без срыва в хаос.
5) Гораздо большая доля кода оказывается повторно используемой.

Недостатки:
1) Нужно единожды написать генератор деклараций удаленных интерфейсов и их реализаций,
2) Нужно единожды написать класс m_database
Думаю, для серьезных проектов приведенные недостатки несущественны.

Преимущества, следующие из недостатков:
1) Имея такой генератор кода, можно запросто избавиться от привязки к DCOM.

Здравствуйте, Roman Avramov, Вы писали:

RA>очень советую книжку Фаулера. сейчас на в открытом доступе остался только каталог:
RA>http://martinfowler.com/eaaCatalog/, но у меня осталась выкачанная бета-версия. надо — могу прислать.

А можно и мне?

Здравствуйте, DemAS, Вы писали:

Ссылка по теме:
http://ojb-net.sourceforge.net/


DAS> Есть база данных. В ней есть таблицы. Талицы справочники представляют собой какие-то сущности: например — поставщики, товары, адреса....
DAS> Есть программа, которая работает с базой данных. По хорошему, как я понимаю, все эти сущности из БД должны каким-то образом отображаться на классы в программе.

Здравствуйте, Roman Avramov, Вы писали:

RA>очень советую книжку Фаулера. сейчас на в открытом доступе остался только каталог:
RA>http://martinfowler.com/eaaCatalog/, но у меня осталась выкачанная бета-версия. надо — могу прислать.

Я например хочу!
пришли на 534514 at inbox dot ru