Вам знакомо понятие Универсальный подход?

Я могу объяснить, что я под этим понимаю.

Это когда сервер приложений имеет определенные средства, для

распознавания хранимых в хранилище типов(Бизнес структур)

и отношений между ними. Сервер приложений способен вычислять

все необходимые запросы на выборку, апдейт и удаление

самостоятельно.Одним словом, сервер приложений хранит все настройки в базе.



Клиент в таком приложении не посылает никакого SQL запроса.

Он передает на сервер только определенные идентификаторы

и в ответ получает готовые наборы данных.

Реализация клиента и сервера при данном подходе значительно

сокращается. Уменьшается вероятность ошибок. Повышается устойчивость

работы системы.

К сожалению часто приходится видеть загроможденные кубиками

Датамодули, в которых невозможно разобраться и требуется

перекомпиляция всего при внесении незначительных изменений.



Универсальный GUI выглядит примерно как

Enterprice Manager для MS SQL 2000.



Вот частный случай реализации



Суть заключается в том, что в базу добавляются спец таблицы,

описывающие иерархию наследования бизнес-классов и отношения между

ними.

Все сущности в базе имеют уникальные идентификаторы(допускается в

пределах таблицы)



Оперируя этими идентификаторами, можно вытаскивать на клиента

все наборы данных, при навигации по TTreeView.



например, каждая нода имеет описатель вида:



class TNodeData : public TObject

{

private:

int m_OwnerId;

int m_ChildCount;

TAppObject *m_AppObject; <- указатель на объект в кэше приложения



public:

.....



class TAppObject : public TObject

{

private:

int m_TypeId;

int m_ObjId;



При навигации на клиенте, клиент посылает на сервер запросы,

типа:



....Get(int p_OwnerId, int p_TypeId, int p_OId)



....Get(NodeData->OwnerId, NodeData->AppObject->TypeId,
NodeData->AppObject->p_OId)





Сервер приложений смотрит в свои спец. таблицы и вычисляет

имена реальных таблиц, наборы полей, внешние ключи

или промежуточные таблицы(многое- ко- многим)

для постороения SQL запроса используя только эти данные.



Posted via ActualForum NNTP Server 1.3

Просьба конструктивно изъяниться по данному вопросу.
Если что - то не нравится дак - проходите мимо.


Posted via ActualForum NNTP Server 1.3

да.

это не ТЗ



Posted via ActualForum NNTP Server 1.3

Эх.
чо то не те люди фсё идут в этот топик.
Нада наверное новый топик открыть
Духзвенка. Классический подход.


Posted via ActualForum NNTP Server 1.3

Gradient,

а у Вас есть свои универсальные разработки?


Posted via ActualForum NNTP Server 1.3

>вопрос намбер уан...
>у Вас есть универсальный код.

Для навигации по данным любой сложности.
Да есть такой код.

>в его основе лежит анализ..если это то, то делаем одно...если то, то
выполняем второе... >вопрос.. чем Вы собираетесь гасить очевидные временные
затраты данного >"универсального" подхода ?

Не понимаю о каких затратах идет реч?

С Уважением ко всем.



Posted via ActualForum NNTP Server 1.3

Gradient

> В каждом конкретном случае на базе этого нетрудно написать решение. А
прибивать к этому >формат сообщения - уже лишнее: он-то каждый раз зависит
от задачи.

А прибивать формат сообщения никто не собирался.



Posted via ActualForum NNTP Server 1.3

Petro123

если вы владеете универсальным подходом и у вас есть свободное время,
я готов с вами переговорить лично.


Posted via ActualForum NNTP Server 1.3

Petro123,

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

Наверное тут проще? У кого что болит - тот о том и говорит.

С Уважением, к Вам.


Posted via ActualForum NNTP Server 1.3

Petro123,

:)
Да ктож вам сказал что это ТЗ?

ТЗ оно вот , у меня здесь на рабочем столе,
а то что начальном посте изложено это просто мое понятие об универсальном
подходе.

>Клиент в таком приложении не посылает никакого SQL запроса.
>Он передает на сервер только определенные идентификаторы
>и в ответ получает готовые наборы данных.
========= ХП на сервере это решают

Да, возможно и решают.
И возможно что можно выкрутиться одними ХП на сервере в большинстве случаев,
но с большими затратами на изучение специфики хранилища данных. А может в
конечном итоге и не получиться.
Здесь же руки ничто не связывает как знание С++.
Ну а плата за производительность никакая не большая - наоборот есть
аспект который индустриальный клиент-сервер на второе место поставит.
Работа через интернет.Что требуется все чаще и чаще.

>Реализация клиента и сервера при данном подходе значительно
>сокращается. ============ голословно

это очевидно. Клиент "тощает" у него там получается 5-6 методов доступа к
серверу,
а может быть и того меньше.

>Уменьшается вероятность ошибок. Повышается устойчивость
>работы системы.======== голословно

вытекает из вышесказанного. Нечего поддерживать - нечего и исправлять в
реализации.

>К сожалению часто приходится видеть загроможденные кубиками
>Датамодули, в которых невозможно разобраться и требуется
>перекомпиляция всего при внесении незначительных изменений.
========= см.выше

невижу.


Posted via ActualForum NNTP Server 1.3