johnRSDN,

Привет! Я давно занимаюсь таким вопросом, но в отношении оконных приложений. Кое-какие наработки есть, но свести всё к единому продукту не хватает ресурсов. Если кто захочет вложиться, то максимум через полгода получит полноценную среду разработки - по удобству не уступающую 1С, но не имеющую проблем 1С.

Недавно столкнулся с разработкой в WEB. Использую PHP и MSSQL2008. Начал с разработки платформы, но не для дизайна, а для логики сущностей. И удалось кое-что сделать:

1. База данных у меня давно проектируется в объектно-реляционном стиле. Наследование, полиморфизм, частично инкапсуляция (но можно и полную инкапсуляцию сделать). А главное у меня уже есть набор базовых классов, которые без всякой переделки кочуют из проекта в проект вот уже почти 8 лет. Так сказать ядро системы.

2. Для WEB-звена время жизни объектов ограничивается временем исполнения кода. При повторном обращении они создаются заново, поэтому нужно всегда где-то сохранять промежуточные значения. Для этого используют файл сессии. Мне удалось сделать базовый класс, который может себя сохранять в сессии и восстанавливать оттуда. Причем главное преимущество, это способность сохранять объектные атрибуты в виде ссылок. Таким образом при восстановлении объектов каждый восстанавливается по отдельности, а затем все они собираются вместе заменяя ссылки на самих себя.

Поясню подробнее.

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




Теперь если восстановить эти объекты из сессии, то получим по два экземпляра каждого объекта.
Первый экземпляр obj1 восстановится из сессии, а второй из свойства obj2->Property. То же самое со вторым объектом.

Так вот базовый класс при создании экземпляра генерирует уникальный ХешКод и перед сохранением заменяет объектные свойства на ХешКод. Соответственно каждый объект сохраняется в сессию в единственном экземпляре, всё остальное в виде ссылок.

При восстановлении объекта из сессии просматриваются все его свойства вида ХешКод, по которому находятся соответствующие экземпляры, восстанавливаются из сессии и заменяют собой ХешКоды.

Таким образом, получаем неограниченное время жизни объектов. При это еще сам собой получился сборщик мусора. Объект, на который потерялись все ссылки в сессию просто не сохранится.

Благодаря такому механизму удалось сделать события и обработчики событий для всех объектов. Удалось связывать разные модули между собой пока жива сессия.

Из минусов.

- Иногда сессия может вырасти до мегабайта, но тут нужно грамотно писать код, не создавать лишнего и хорошо обрабатывать ошибки.
- Зачастую прямую ссылку на страницу дать нельзя, т. к. она создается в контексте чего-либо и ХешКод уникален, система просто скажет, что такой объект не найден.

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

3. Интерфейс удалось сделать на шаблонах. Основное понятие в системе - операция. Операция - это страница или часть страницы. Операция обращается к сущностям, получает от них данные, берет шаблон, превращает его в DOM-модель и связывает поля (с данными) с контролами (тегами)

Это, конечно, еще не 1С, но платформа позволяет развить её и превратить в полноценный конфигуратор. Для этого есть идеи и опыт, но нет ресурсов.

johnRSDN,

Такого продукта нет :-(

Александр Пузаков,

В том то и дело, что они знали что хотели получить (да и то не до конца), а как это сделать не знали и скорее всего не знают до сих пор. Поэтому и получилось то, что есть.

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

Sergey_rb,

То, что ты сделал здорово и замечательно, но это лишь часть того, что хочу сделать я. У меня комплексный подход. Твоя наработка хорошо легла бы в мою систему как визуальный построитель бизнес-процессов. Когда Если я всё-таки сделаю свою систему, то обращусь к тебе.

ViPRos,

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

Sergey_rb,

Если в кратце, то это три слоя. MVC или не MVC, я сказать затрудняюсь, но вроде похоже.

1. Сущности. Обязательно ООП с единственным базовым классом. Подход объектно-реляционный. Генерация таблиц и процедур по метаданным. Генерация классов (например, C#) тоже по метаданным.

2. Слой бизнес-логики, компонентное иерархическое построение на основе 4-х классов Application, Process, Operation, Command. Сама же бизнес-логика и ограничение прав доступа определяет, то есть специально делать разграничение прав не нужно, само собой получается.

3. Интерфейс, получает данные от операций в строго определенном формате, в нем же и обратно передает с изменеными данными, а также получает набор событий. При активизации события (клик по кнопке или ссылке) обратно отправляется имя команды в контексте текущего положения в бизнес-логике.

Уже продуман интерфейс программы для редактирования метаданных и структура метаданных.

И многие бизнес-сущности уже реализованы и отлажены.

Sergey_rb,

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

iscrafm,

Не совсем. Есть БД с набором сущностей, которую уже 8 лет использую практически без изменений. Есть генератор сущностей на основе метаданных. SQL-версия. Хочу сделать .NET версию или Delphi, точнее хочу сделать стороннее приложения для редактирования метаданных и генерации кода.

На PHP сделал слой бизнес-логики на основе Application, Process, Operation, Command. Практика показала, что получился хороший, логичный, концептуальный механизм для исполнения бизнес-логики. Подробнее можно прочитать здесь . Хочу реализовать аналог для Сервера Приложений на .NET.
На .NET я уже делал версию сервера приложений, но тогда я еще не додумался до данной концепции и логика была плоской, хотя вполне работоспособной.

Интерфейс, как ни странно не хочу делать в виде дизайнера форм, а использовать VS10. или Delphi. Тут можно интерфейс писать на чем угодно, так как общаться с сервером приложений он будет посредством XML

Sergey_rb,

Этих 4-х классов достаточно для любой, даже самой изощренной логики. Если быть точнее, то это базовые классы.
Для каждой новой команды создается класс-наследник Command и в нем пишется логика.
Для каждой новой операции создается класс-наследник Operation и в нем пишется логика.
Application и Process не перекрываются, они работают согласно описанию в метаданных.

Да и для операции можно также сделать, но ручками код писать удобнее, нагляднее

ViPRos,

Как раз нет. В ядре нет вообще ничего прикладного. Поэтому я ядро могу использовать для реализации какой угодно системы.

ViPRos,

Я там выше ссылку приводил на подробное описание, приведу еще раз вот

Правила простроения бизнес-логики

Для построения бизнес-логики используется иерархическая модель функциональных элементов.
То есть базовым элементом бизнес-логики является функция - компонент, которая реализована с помощью
объекта класса Command с методом Exec, это типичный шаблон проектирования Command

Имеется четыре базовых класса Command, Operation, Process, Application

1. Command представляет собой логику, которая выполняется последовательно и непрерывно на стороне сервера
2. Operation представляет собой частный случай Command и является интерактивной командой, которая взаимодействует
с клиентом (под клиентом понимается любое клиентское приложение)
3. Process представляет собой частный случай операции и является долгоиграющей операцией, которая время от времени
сохраняет свое текущее состояние на сервере независимо от времени жизни клиентского приложения. Process
имеет набор состояний и к каждому состоянию привязывается определенный набор операций, доступных в этом
состоянии, в том числе в качестве операции процесса может выступать другой процесс, в результате чего он
становится подпроцессом.
4. Application представляет собой частный случай процесса и является синглетоном в разрезе клиентов. То есть
каждый клиент (клиентское приложение) имеет экземпляр приложения, причем единственный. При этом Application
является корнем приложения. Его точкой входа и выхода.

Таким образом бизнес-логика строится в виде дерева с корнем Application, набором состояний приложения и
вложенными операциями, привязанными к этим состояниям. Дерево имеет неограниченное количество уровней.

Рассмотрим в качестве примера площадку для проведения аукционов, реализованную в виде WEB-приложения
Попасть на площадку может любой пользователь, в том числе не зарегистрированный на площадке. Тем не менее,
такой пользователь имеет доступ к некоторому функционалу:

1. Посмотреть описание площадки
2. Прочитать новости площадки
3. Посмотреть список торгов
4. Залогиниться (если есть аккаунт)
5. Зарегистрироваться

Все эти операции доступны для приложения в состоянии New, которое означает, то процесс запущен, но еще не имеет
сохраненного экземпляра в базе данных (или еще не инициализирован экземпляр).

Оформим иерархию


Application - экземпляр класса Application (процесс - синглетон)
New - состояние процесса (стартовое)
Description - операция, которая выводит страницу с описанием функционала площадки
News - операция, показывает страницу со списком последних новостей площадки
AuctionList - операция, выводит на экран список актуальных торгов
Login - операция, позволяющая пользователю авторизоваться на площадке
Registration - процесс, который даёт пользователю возможность создать аккаунт на площадке

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

http://www.ets24.ru/index.php?op=Login

Операция проверит в базе наличие аккаунта и соответствие пароля, инициализирует процесс (Application)
и вернет его состояние: Registered. Теперь надо в дереве бизнес-логики определить какие операции стали доступны


Рассмотрим последние три операции:

Logout - операция, предназначена для выхода из авторизации
Cabinet - операция, открывает страницу с личным кабинетом
OrganizeAuction - процесс, дающий возможность организовать аукцион

Остальные операции, которые повторяются в обоих состояниях имеет смысл вынести в безусловные операции, так как
он не зависят от состояния приложения. Такая возможность у процессов тоже есть. То есть в процессе можно
прописывать операции, зависимые от контекста (привязанные к состоянию), и не зависимые от контекста, которые
можно выполнить в любом состоянии процесса, главное, чтобы доступ к самому процессу был.

С учетом вышеизложенной информации можно перестроить дерево бизнес-логики


Теперь попробуем расписать процесс регистрации нового пользователя на площадке

- Registration

Теперь целиком наше дерево будет выглядеть так:


Запуск вложенного процесса может происходит по нескольким сценариям:

1. Синхронный запуск - означает, что процесс, внутри которого синхронно запущен дочерний процесс, становится
недоступным пока свою работу не завершит дочерний процесс
2. Асинхронный запуск - означает, что родительский процесс не ждет завершения дочернего и дает доступ к запуску
других подпроцессов.
3. Инициирующий запуск - означает запуск зависимого подпроцесса, предназначенного для другого субъекта, например,
запуск процесса проверки заявки на регистрацию, предназначенного для оператора. Инициирующий запуск может быть
как синхронным, так и асинхронным.
4. Множественный запуск - означает, что можно запустить несколько вложенных процессов одного и того же типа, иначе
повторный запуск подпроцесса будет приводить к доступу уже имеющегося подпроцесса.

Каждый экземпляр процесса непосредственно связан с субъектом, который его создал, либо которому предназначен
процесс. Никто другой не может получить доступ к процессу.

Система разграничения прав доступа при таком построении бизне-логики приобретает новый смысл

1. Вызов какой-либо операции или команды возможен только при указании абсолютного пути к ней. Например

op=Cabinet - открыть личный кабинет (корневая команда Application опускается). Кабинет откроется, только если
Application находится в состоянии Registered

op=Cabinet/WorkSpace - откроется рабочий стол личного кабинета. Вызов операции

op=WorkSpace напрямую ни к чему не приведёт (кроме сообщения об отсутствии доступа), т.к. внутри Application
такой операции нет, и она появляется, только когда инициализируется операция Cabinet

И соответственно вызвать команды AddPanel и RemovePanel, которые зарегистрированы в операции WorkSpace также не
получится, пока не зайдешь в WorkSpace

2. Вызов процесса происходит по другому сценарию. Для обращения к уже имеющемуся экземпляру процесса указывается
его тип и идентификатор, например

op=Registration&OID=8253

При этом на стороне сервера происходит проверка принадлежности процесса вызывающему собъекту (по полю Subject в
процессе).

Для запуска нового процесса нужно указать родительский процесс (кроме Application, который всегда инициализируется
и является синглетоном), его идентификатор и имя вложенного процесса, например

op=Registration/SendRequest&OID=8253

При этом запуск подпроцесса SendRequest будет возможен только в том случае, если процесс Registration с
идентификатором OID=8253 принадлежит пользователю и находится в состоянии, в котором доступен подпроцесс

В итоге имеем одновременно способ описания бизнес-логики и средство разграничения прав доступа











Внутренняя реализация классов Command, Operation, Process и Application


Класс Command простой до безобразия. Имеет виртуальный метод Exec($params), где $params - ассоциативный массив,
где ключ - название параметра, а value - значение параметра

В наследниках класса Command в перекрытом методе Exec пишется логика. Примеры команд на текущий момент

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




Sendmail - команда, которая отправляет электронное письмо





Операция регламентирует бизнес-логику более жестко. Основным также является метод Exec
Но в наследниках он не перекрывается. Метод Exec выглядит так:





Сначала идёт вызов виртуального метода Init, который регистрирует вложенные операции и команды, которые
как раз и будут доступны внутри данной операции, пример реализации метода Init




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




Это уже оптимизация быстродействия

Затем в методе Exec операции определяется подоперация, если она указана. Смотрим параметр op.
К слову сказать, в $params сидит $_GET. В каждую операцию в параметре op приходит строка, в которой
уже вырезана рутовая часть, относящаяся к текущей операции, т.е. в операции Application строка op
выглядит так op=Cabinet/WorkSpace, а в операции Cabinet строка op выглядит так: op=WorkSpace

Поэтому следующий код как раз и занимается тем, что вычленяет дальнейший путь, ищет вложенную
среди зарегистриргованных вышеуказанным методом Init и если находит, то передаёт ей управление,
обрезав корневую часть строки. Если не находит, выдает ошибку. Если уже была достигнута последняя
точка пути, то выполняется логика, определенная по-умолчанию. То есть вызывается метод ExecDefault

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

И если всё же произошла ошибка, то выполняем метод HandleError, передав ему текст ошибки.

Process еще более жёстко регламентирует логику, настолько жестко, что создавать наследники не нужно
Доступные операции и состояния прописываются в базе данных, например




Сначала регистрируются операции, затем процессы, затем операции привязываются к состояниям процессов.
Таким метод Init процесса обращается к базе данных, читает настройки и регистрирует доступными операции,
причем не все, а только те, что привязаны к текущему состоянию. Состояние определяется по переданному
OID процесса. Если OID не передан, то значит это новый процесс и состояние = New

Как уже сообщалось, мы не перекрываем класс Process в слое бизнес-логики, исключение составляет только
класс Application. Он инициализируется без OID, по связи с текущим пользователем и отрисовку страницы
выполняет самостоятельно, в отличие от процесса, который сформированную страницу возвращает вызвавшей его
функции. Applicationу возвращать страницу уже некуда, поэтому он ее эхает.






Как необходимо разрабатывать новые прикладные классы бизнес-логики. Посколько Application и Process являются
самодостаточными, то остаётся разработка операций и команд. Про разработку команд выше уже сообщалось. Нужно
просто перекрывать метод Exec, поэтому рассмотрим подробно разработку операций. Сделаем это на примере админки.

Создадим операцию Administration. Прикрепим ее к Application в состоянии Registered. Доступ к ней должен получать
только администратор системы. Для этого есть два способа:

1. В методе Init вызывать хранимую процедуру, которая будет проверять является ли пользователь администратором
и если нет, то создавать исключение.
2. Привязать операцию к процессу по условию, то есть добавить к связке процесс-состояние-операция еще Conditon
(IsAdministrator). Тогда все, кто не админ, не будут получать доступ к операции

Выберем первый способ (чисто для примера, на практие я реализую второй способ)

1. Зарегистрируем ее в базе.




2. Создаем класс Administration в PHP, наследуем от Operation

Перекрываем метод Init




Дочерняя операция Object предоставляет доступ к любому действию любого объекта, её нужно реализовать
Но это будет дальше, а сейчас продолжим реализовывать операцию Administration

Что должна делать данная операция по-умолчанию? Наверное, выводить список всех классов.
Перекроем метод ExecDefault.




То есть по-умолчанию будет вызываться операция Object, которая будет вызывать действие объекта List
А класс объекта - Class, то есть выводим список объектов типа Class.

Теперь нужно перекрыть метод Page, который будет выводить html на экран




Предполагаем, что страницу всегда будет формировать вложенная операция.

Не буду подробно расписывать операцию Object, просто распишу словами, что она должна представлять из себя.

Посколько иерархия бизнес-логики это один из слоев MVC, то вторые два это слой бизнес-сущностей и интерфейса.
Как устроен слой Бизнес-сущностей вы уже знаете. Это иерархия классов бизнес-сущностей, и в каждой
зарегистрирован набор действий Edit, Create, View, Delete, Print и т.д.

Это значит, что метод Init операции Object, должен создать экземпляр класса бизнес-сущности и получить у него
список действий. Базовое действие Action является наследником операции. А метод Exec должен выболнить это
действие.

Таким образом команда вида

op=Admin/Object/Edit&OID=1234

Создасть операцию Admisitration (если есть доступ), затем создаст опреацию Object, которая создаст сущность,
найденную по параметру OID и выполнит его действие Edit.

Для создания нового объекта или вызова действия класса, нужно указывать не OID, а Class, например

op=Admin/Object/Create&class=Notice
или
op=Admin/Object/List&class=Auction

ViPRos,

Непонятные они, сложные :-(