В корне концепции мне нужна иерархия (композиция) объектов

andylars 29.11.2014 22:39 / 30.11.2014 13:18

Поэтому, через рефлексию я пошёл только как черновая проба сделать максимально нативно. Изначально сразу думал просто построить отдельный хеш, как синтетическую структуру объектов, с ним можно пошустрее и погибче обойтись, но боюсь, что вдруг наступлю на грабли, того, что нативно вложенные объекты имеют реальный контекст исполнения, а синтетически разложенные по хешу объекты могут доставить неприятностей.

В простом очертании мне нужна такая структура Модели:

 ObjName <ClassName>
   Nested: true
   Objs:
     ObjName <ClassName>
        Nested: true
        Objs:
        ...
        Funcs:
        ...
   Funcs:
     fFunc1
         in: <- декларация типа входных данных objs <classname>
        out: <- выходных соответственно  obj <classname>
     fFunc2
        ...

# Умозрительный пример:

 Session1 <CoreModel>
   _AppPreamble: <hash>
        Title: WebGoods <string>
        Copyright:      <hash>
           Firm: WebGoods Ltd. <string>
           Years: 2008-2014 <string>

    Goods <Goods>
        Query: <string>
        List: <BufHash> #буфферизованный доступ
           Frame: <hash>  
               pos_1: <hash>
                  item_id: <int>
                  item_name: <string>
                  item_image_url: <hash>
                      default: <string>
                      ext_1:  <string>
                  item_price: <double>

           CurrentFrameNum: <int> #текущий номер кадра
           CountFrames:  <int> #всего кадров
           CountRecords: <int> #всего записей
           fNext() - следующий "кадр" данных
           fPrev() - предыдущий "кадр" данных
           fsetFrameSize(<int>) - задать размер буфера
           

P.S.: pfORM посматриваю, но это же ORM, т.е. только про данные, а у меня именно Модель в ее наиболее широком смысле, т.е. Модель приложения в принципе - это и возможные структурированные данные и функции вместе.

То есть это не абстракция над данными, это абстракция над приложением, внутри которого уже можно поселить ORM и RAW-доступ к данным одновременно, по желанию.

Грубя говоря, если притянуть за уши известных терминологий, я пытаюсь изобразить какой-то свой шаблон проектирования самого верхнего уровня абстракции.

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

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

А "точка входа/инициализации" начинается с того, что некий внутренний менеджер открывает сессию к этому общему интерфейсу и сёрфает по этой объектно/функциональной структуре, работая с Моделью.

Таким образом, а рамках одного runtime, может быть даже несколько различных сессий "в приложение", но это не самоцель, самоцель что менеджер может рендерить в разные прикладные UI и взаимодействовать со всей Моделью приложения, опираясь на какие-то вспомогательные Template-семантические подсказки, дающие жесткие или мягкие декларации как то или иное отрисовать.

Т.е. это уже повадки агентно-ориентированного подхода.

По сути, это попытка сделать какой-то сводный конечный интерфейс всего backend'a перед стыковкой его с любыми другими fronend'ами, где концепция подачи отличается тем, что:

a) общая структура представляет собой до определенной степени композицию объектов(микро-моделей) структуру и вложенность которых можно задавать потом декларативно каким-нить xml или json, а то есть перетанцовывать на ходу меняя структуру приложения, практичеки не ползая в код и имея гарантии что это безопасно и интерфейсы согласованы. (В последнее предложение и сам едва-ли верю)

b) агентный подход, при котором работа с общим интерфейсом приложения (которое по сути являет собой API автоматически) идет через менеджер, который является формальным "браузером"/клиентом этой глобальной Модели и может транслировать общение с ней через разные UI. В том числе, это реализует и права доступа и всякие роли и т.п. В рамках сессии менеджера можно сохранять, управлять состоянием всего приложения. Что в локализации для веба как раз выглядит как состояние интерфейсов, навигации и прочего.

На деле, же это пока это глина, которой я балуюсь попутно решая две практические задачи: подучить парсер и придумать быстрое свое или взять что-то готовое, чтобы "запилить" некоторый веб-проект интернет-витринной направленности.

---