Я нахожусь в процессе создания новой программы. Он создается таким образом, что я никогда ничего не создавал. Программа в основном состоит из следующих:
У меня возникают проблемы с этой настройкой:
1.I не удалось выполнить создание singleton для моего класса базы данных, потому что, используя ajax, я вынужден создать новый экземпляр базы данных в каждом файле ExampleAction. Это нормальное поведение или должно быть возможно, и это, вероятно, что-то в моем коде? Если это будет возможно, и это что-то в моем коде, я отправлю его позже.
Если я не буду достаточно ясным, это то, что я пробовал: – Я переименовал index.html в index.php (конечно). – Включил мою сингл-версию базы данных в верхней части этого файла. – Сделал вызов ajax для ExampleAction.php. – ExampleAction.php не имеет доступа к классу базы данных, и я должен снова включить его и создать новый экземпляр.
2. Когда я делаю вызов Ajax, я отправляю параметры через POST. Общая схема ExampleAction выглядит следующим образом:
$actionInstance = new ExampleAction(); class ExampleAction { public __construct() { this.GetAction(); } private GetAction() { $action = $_POST['action']; switch ($action) { case "Login": this.Login(); break; } //Login function, etc. here } } Конечно, мой реальный код содержит санитарию и т. Д., Операторы switch более длинные и содержат намного больше функций
То, что мне не нравится в этом, – это две вещи. Мне не нравится, что я должен создавать экземпляр объекта каждый раз, когда я делаю вызов файла, но я думаю, что это не поможет.
Во-вторых, если у меня много функций, мой коммутатор становится огромным.
Все эти проблемы заставляют меня думать, что я все это делаю неправильно.
TL; DR: Я ищу лучший способ создать такую программу, как то, что я делаю. У меня такое чувство, что я делаю свой код медленнее (из-за увеличения количества вызовов ajax), и с течением времени сложнее поддерживать (из-за постоянно растущего оператора switch.
Причина, по которой вам нужно создать экземпляр нового объекта для каждого вызова AJAX, заключается в том, что вызов AJAX представляет собой новый запрос на ваш сервер от клиента. Вызываемый скрипт не запускается в вашей программе, и любая настройка должна выполняться в точке, которую сценарий вызывается AJAX.
Лучше всего использовать инфраструктуру, использующую MVC, такую как codeigniter или Zend Framework . Короче говоря, если использовать правильную структуру MVC, вы избавитесь от необходимости создавать объекты для каждого вызова AJAX, поскольку это обрабатывается контроллерами, и вы сможете потерять свои операторы коммутатора, поскольку каждый вызов AJAX может быть уникальным URI с один контроллер, который обрабатывает все эти разные вызовы.
EDIT: в ответе на комментарий К сожалению, у меня нет опыта работы с Zend Framework, но я уверен, что эта посылка почти такая же, как в Codeigniter. Таким образом, в Codeigniter у вас должен быть контроллер AJAX, который расширяет основной контроллер и, следовательно, имеет доступ к базе данных и всему остальному, который настраивается в основном контроллере.
В контроллере AJAX у вас будут разные методы, которые обрабатывают все различные вызовы AJAX примерно так.
//CI_Controller is codeigniter's base Controller class AjaxController extends CI_Controller { public function __construct() { parent::__construct(); $this->output->set_content_type('application/json'); // Can make calls to anything a normal controller can do } public function doSomething() { // You have access to the database because you are extending // and calling the parent constructor // $this->db->query(); } public function doSomethingElse() { ... }
Для вызова этих функций AJAX ваши URI будут http://mysite.com/Ajax/doSomethig или http://mysite.com/Ajax/doSomethingElse
Как я уже говорил, перед вызовом AJAX – это новый запрос на ваш сервер от клиента. Когда пользователь запрашивает страницу, ваш PHP-код запускается на сервере, а результат отправляется клиенту. Любой javascript запускается в браузере пользователей. Если ваш javascript делает вызов AJAX, это новый запрос на ваш сервер и происходит после того, как ваш PHP закончил исходный запрос.
Трудно просто предоставить вам «лучший способ» для вашей программы.
Однако я предлагаю вам погрузиться в шаблон MVC и узнать о его структуре. После этого вы можете попробовать реализовать подобный метод в своем собственном коде.
Вот основное объяснение о MVC, но не торопитесь в Google и читайте больше, чем просто этот бит текста:
Определить MVC в условиях неспециалиста
Помните, что вы технически настроены и близки к коду. MVC для вас так же ясен, как и день, но говорить бизнесу «Модель, вид, Контоллер» может создать у них впечатление, что вы страдаете от синдрома торерта. MVC не будет иметь большого значения для бизнеса даже после того, как вы определите их по отношению к коду. Чтобы заставить бизнес понять, почему это ответ, и меньше всего того, что он есть, может быть скорее задачей, чем ожидалось в моем опыте. Даже некоторым разработчикам сложно иногда это понимать.
Чтобы заставить слушателя понять, что такое MVC, и почему он работает, что я пробовал в этом проходе, это применить MVC к другим отраслям, в которых слушатели больше заинтересованы. Пример, который работал для меня в прошлом в сравнении с собственностью или даже с транспортными средствами. Большинство людей имели дело с строителями, плотниками, водопроводчиками, электриками или наблюдали за потоком выставок собственности на телевизоре. Этот опыт является хорошей платформой для использования и объясняет, почему работает разделение, такое как MVC. Я знаю, что вы, вероятно, думаете, что это не сработает, так как это не то же самое, что в программном обеспечении, но помните, что вы не пытаетесь обучить бизнес стать разработчиком или иметь глубокое понимание MVC, просто объясняя им, что разделение в производстве требуется, и это то, что предлагает структура MVC.
Чтобы привести пример того, как вы могли бы это описать, я очень кратко объяснил, как разделение работает в собственности. Имейте в виду, что это сосредоточено на использовании не разрабатываемой системы, которая может быть совершенно другим углом объяснения.
Посмотреть
Представление в MVC – это уровень представления. Это то, что будет видеть и взаимодействовать с конечным пользователем продукта. Система может иметь несколько видов всех типов, начиная от вывода командной строки и заканчивая визуализированным HTML. Представление не состоит из бизнес-логики в большинстве ясных конструкций. Интерфейс подходит для цели и является областью взаимодействия. Поэтому вы можете просто вывести HTML для потребителей, чтобы взаимодействовать с SOAP / XML или выводить SOAP / XML для взаимодействия с предприятиями. Оба используют ту же бизнес-логику, что и система, иначе известная как модели и контроллеры.
В мире собственности вы можете думать о представлении как о внутренности свойства или о внешнем слое свойства, с которым взаимодействуют жители. Интерьер может быть настроен для цели, и одно и то же свойство может иметь много разных типов арендаторов. Например, свойство конкретного проекта может содержать жилые дома. Такое же внутреннее пространство можно легко использовать в качестве офисного помещения, хотя в одном и том же свойстве имеет другую цель. Однако структура собственности одинаков. Поэтому среда, в которой взаимодействуют пользователи, не мешает структуре здания.
Контроллеры
Контроллер – это то место, где происходит волшебство, и определяет логику бизнес-приложения. Это может быть тот случай, когда пользователь отправил ответ из представления, затем этот ответ используется для обработки внутренней обработки запроса и обработки ответа обратно пользователю. Принимая типичный ответ, когда пользователь попросил купить книгу. Контроллер имеет идентификатор пользователя, данные платежа, адрес доставки и выбор пункта. Затем эти элементы обрабатываются через бизнес-логику для завершения покупки. Данные передаются через систему в уровень модели, и, в конце концов, после того, как весь запрос удовлетворяет определениям бизнеса, заказ строится и пользователь получает свой элемент.
Если мы сравним это с собственностью, мы могли бы сравнить упорядочение книги в Интернете с включением выключателя света. А арендатор перевернет переключатель, точно так же, как заказать книгу. Сам переключатель является элементом слоя представления, который отправляет запрос контроллеру, как щелчок на кнопке проверки на веб-сайте. В этом случае бизнес-логика заключается в том, что электрик установлен и встроен в проекты свойств. Переключатель переключается, что завершает схему. Электричество проходит через все провода, включая блок предохранителей, прямо к лампочке. Подобно тому, как пользователь получает книгу, в этом случае арендатор получает свет. Весь процесс за кулисами, включающий электрическую проводку, не виден арендатору. Они просто взаимодействуют с коммутатором в пространстве и оттуда контроллер обрабатывает запрос.
модели
Модели в MVC являются самым нижним слоем и обрабатывают основную логику системы. В большинстве случаев это можно рассматривать как слой, который взаимодействует с источником данных. В системах, использующих MVC, контроллер будет передавать информацию модели, чтобы хранить и извлекать данные. Следуя приведенному выше примеру определения контроллера, здесь хранятся данные заказа. Здесь хранятся дополнительные данные, такие как уровни запасов, физическое расположение продукта книги среди многих вещей. Если это была последняя заказываемая книга, следующий запрос этого элемента может проверить, доступен ли он и запретить заказ, поскольку элемент больше не доступен.
Придерживаясь примера включения выключателя света, этот уровень в нашей структуре может быть источником электропитания. Когда арендатор щелкает выключателем, внутренняя цепь должна запрашивать электричество для подачи запроса, который аналогичен, когда пользователь запрашивает данные из базы данных, как и данные, необходимые для обработки запроса. Если жилье не подключено к электросети, оно не может завершить процесс. Преимущества для бизнеса от использования MVC
После того, как вы получите сообщение, объяснив, что такое MVC, вам нужно будет узнать, какие выгоды можно получить от него. Я не собираюсь вдаваться в огромное количество деталей, я уверен, что вы можете более точно применять преимущества, которые напрямую связаны с вашей реальной ситуацией. Ниже перечислены некоторые из общих преимуществ системы на базе MVC: несколько примеров:
Различные уровни навыков могут работать на разных уровнях системы. Например, дизайнеры могут работать с интерфейсом (View) с очень небольшими знаниями в области разработки, а разработчики могут работать над бизнес-логикой (Controller) с очень незначительной заботой о дизайне. Затем они просто интегрируются вместе по завершении. В результате вышеупомянутых проектов разделения можно управлять легче и быстрее. Дизайнер может запускать интерфейсы перед разработчиком и наоборот. Этот процесс разработки может быть параллельным, а не последовательным, что сокращает время разработки. Легко иметь несколько типов просмотра, используя одну и ту же бизнес-логику. Очистить маршрут через систему. Вы четко знаете, где находятся разные уровни системы. С четким маршрутом системы логика может быть разделена и улучшена. Это добавило преимущества безопасности, поскольку вы четко знаете разрешенный маршрут от данных к пользователю и можете иметь четкие проверки безопасности по маршруту. Каждый слой отвечает за себя. (Относится к точке 1). Это означает, что вы можете иметь чистую структуру файлов, которая может поддерживаться и управляться намного проще и быстрее, чем система с плотной связью, где у вас может быть много повторяющейся логики. Наличие четкой структуры означает, что разработка будет более прозрачной, что должно привести к сокращению времени разработки, проблем обслуживания и циклов выпуска при правильном применении.
Конкретный пример PHP о том, как реализовать MVC в php, можно найти здесь: http://phpmaster.com/the-mvc-pattern-and-php-1/
Дополнительно: поймите, что контроллер в какой-то момент представит вам «View», это представление может быть html, xml, json или что-то еще. Поэтому контроллеры также будут обрабатывать ваши запросы AJAX.