Ajax тяжелый вопрос приложения и вопросы дизайна OO

Question

У меня есть корпоративное веб-приложение, которое чрезвычайно тяжело работать на AJAX, все данные идут через какой-то AJAX, поэтому сохраняются, обновляются, удаляются и т. Д. По образцу парадигмы MVC

Сайт в большинстве случаев взломан

Страница интерфейса Страница интерфейса содержит только интерфейс и все js, которые идут с ним, никакой обработки данных.Все данные запрашиваются после загрузки интерфейса.Все данные передаются и принимаются в общем формате обмена (подробнее ниже), например.edit_inventory.php или list_inventory.php

Backend Page Бэкэнд-страница, которая обрабатывает данные, когда команды принимаются как API-интерфейсы, которые вы видите в других веб-приложениях, в основном это гигантский оператор switch всехкоманды, которые он принимает.например.ajax_inventory.php

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

Копирование из типичной CMS, набора классов, интерфейса и бэкэндов называется компонентами.

root
    >comp
        >inventory
            >class_inventory.php
            >ajax_inventory.php
            >edit_inventory.php
            >list_inventory.php
            >ajax_inventorymerge.php
            >edit_inventorymerge.php
        >account

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

---

Вопросы, на которые я ищу ответы, которые обычно используются.

1. Является ли это хорошим шаблоном, можно ли его улучшить?

2. Должны ли объекты и классы, такие как "Product", отвечать за форматирование данных вобщий формат обмена, как упоминалось ранее?

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

4. Поскольку существует несколько форм данных, выводимых объектом из html (form_html), сообщений (msg), пары ключ-значение(form_data) и т. д. Как лучше всего запрашивать данные в целом, а не в $ a-> getData (), $ a-> getMsg, $ a-> getStuff?Другой формат обмена?или просто использовать общий формат обмена, как упоминалось ранее?

Общий формат обмена (в формате json)

{"msg":"Sucess",
 "form_data":{
     "id":100,
     "product_code":"BLA",
     "size":"3"
 },
 "form_html":{
     "list":"<\/li><\/ul>"
 },
 "script":"alert('Some stuff');"
}