Laravel по-русски

Здравствуйте!

Пишу на laravel 5.2 собственного бота. Бот должен отвечать на запросы пользователей по командам на клавиатуре. Собственно, клавиатуру я представляю им тоже. За основу бота была скачена либа, предоставляющая фасад с классами упрощенного взаимодействия с ботом, а именно мне не приходится вручную формировать POST-запрос - либа делает это сама.

Команды к боту делятся на типы. Типы собраны в одну из нескольких клавиатур - каждая на свой тип. Эти клавиатуры объединяет главная клавиатура - меню.

Когда на сайт поступает сообщение с сервера телеграм, то после записи сообщения в базу, сообщение отправляется в главный файл бота - Core.php. Его код выглядит так:

<?php 

namespace App\TelegramBot;

use Telegram;

use App\Http\Controllers\UserController;

use App\TelegramBot\MessageParser;


use App\TelegramBot\Commands\Команда1Command; //тип А
use App\TelegramBot\Commands\Команда2Command; //тип А
use App\TelegramBot\Commands\Команда3Command; //тип А
use App\TelegramBot\Commands\Команда4Command; //тип Б
use App\TelegramBot\Commands\Команда5Command; //тип Б
use App\TelegramBot\Commands\Команда6Command; //тип В
use App\TelegramBot\Commands\Команда7Command; //тип В
// + еще с десяток юзов

class Core
{
	public static function main($message) {
		
		if(!self::auth($message)): // Проверяем есть ли такой пользователь в базе. Нужно для того, чтоб 'левые' люди не имели доступа к
                                           // пользованию ботом
			return;
		endif;
		
		$result = MessageParser::parse($message); // Парсим регуляркой тип команды из текста сообщения. Это своего рода определитель команды
		$action = false; // Создаем переменную, в которую поместим объект на исполнение команды

		switch($result)
		{	
				
			case 'Команда 1':
				$action = new Команда1Command($message);
				break;
				
			case 'Команда 2':
				$action = new Команда2Command($message);
				break;
				
			case 'Команда 3':
				$action = new Команда3Command($message);
				break;
          
                        // + еще с десяток команд

			default:
				$action = new КомандаНеОпределенаCommand($message);
			
		}

		if($action) $action->run();
		
	}

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

Изначально любая команда или действие описывалась абстрактным классом Command и держалась в папке Commands/, но держать все типы команд в одной папке неудобно. Поэтому возникла идея усложнить структура, но сделать ее более читаемой и простой на расширение. А именно сделать так:

Создать абстрактный класс Action, описывающий любой тип команд к боту. Поместить этот класс в свою папку Actions/ - она будет содержать все типы действий и обращений к боту, требующих ответа. Внутри папки Actions/ создать несколько папок, определяющих свои команды. Каждая из команд будет наследоваться от Action.

На данный момент имею это:
TelegramBot/
           |--> Core.php
           |--> MessageReceiver.php
           |--> MessageParser.php
           |--> Commands/
                        |--> Command.php - абстрактный класс, описывающий команды. Представлю его ниже.
                        |--> КомандаACommand.php
                        |--> КомандаБCommand.php
                        |--> КомандаВCommand.php
                        |--> ...

Хочется иметь это:
TelegramBot/
           |--> Core.php
           |--> MessageReceiver.php
           |--> MessageParser.php
           |--> Actions/
                       |--> Action.php - тот же класс Command
                       |--> Keyboards/Команды на предоставление клавиатуры, описываемые классом Action
                       |--> Options/Команды опций, описываемые классом Action
                       |--> Reports/Команды на отчет, описываемые классом Action
                       |--> ...

<?php

namespace App\TelegramBot\Commands;


abstract class Command
{
	private $message;
	private $answer;
	
	public function __construct($message)
	{
		//
	}
	
	public function run()
	{
		//
	}

}

Проблема в том, повторюсь, что подгружать каждый файл в Core.php крайне неудобно. Моих знаний ларавеля, как и ООП, недостаточно, чтоб правильно реализовать данную задачу. Как я понимаю, необходимо создать что-то на подобии автолоадера, который будет автоматом подгружать каждый класс из каждой папки и переносить их в Core. Тут я уже не соображаю.

Вообще, интересна критика данной структуры. Я только начинаю более менее нормально кодить. Жажду прогресса.

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

Спасибо.

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

Ежеминутно отрабатывает задача, по которой извне приходит набор данных в виде ассоциативного массива, который необходимо пропустить через фильтр на регулярках. Как и куда будет правильным прописать фильтры? В middleware? В другую задачу? Может есть примеры реализации подобного?

День добрый! Программирую давно, а ларавель, как и ООП-подход начал изучать недавно. Собственно, и в мир "большого" программирования еще на стадии вливания. Прошу не кидать камнями за, возможно, глупый вопрос, ответ на который я наверняка искал недостаточно усердно.

К делу.

Есть проект по сбору и обработке информаци из СМС сообщений. Не буду вдаваться в ненужные подробности о проекте, перейду сразу к сути.

Задача реализовать загрузку СМС сообщений в мою базу в таблицу 'sms'. MVC осваивать начал только с ларавелем, поэтому некоторые моменты еще не ясны. Итак, есть таблица, к ней приделана модель 'Sms'. Работа с таблицей осуществляется через эту модель и через 'SmsController'. Их задачи, в целом, понятны. Модель нужна для взаимодейстия таблицей, как с объектом, а контроллер для взаимодействия с таблицей уже через модель. Вроде верно. Поправьте если не так.

Так как смс приходят много, то они требуют постоянной подгрузки. Посему был создан еще один контроллер с названием "SmsUpdateController", который является неким центром, через который отрабатывает весь механизм загрузки. В нем мною определен основной метод main(), который отрабатывает по запросу через роутинг (потом посажу на крон). И все бы хорошо. Да вот проблема.

Я рассматриваю само смс-сообщение, как объект с полями 'text', 'sender', 'receiver' и 'datetime'. Собственно, они же и есть в таблице. Поэтому мне кажется логичным создать класс Sms, описывающий объект смс и "строчку" из таблицы. Мой коллега так не считает и предланает использовать ассоциативный массив и передввать его на всех циклах отработки загрузочного модуля. Я считаю это нелогичным, а посему решил все-таки создать класс Sms... и тут начплись проблемы.

Куда его прописывать? Создать папку Library в App? А как правильно подключить класс? Очень не хочется его втупую инклудить через 'use'. Может можно его как-то подгружать автоматически, чтоб он был виден автоматом везде в папке 'Controllers'. Или я ошибаюсь и так делать не нужно вовсе? Вообще и далее по ходу разработки понпдобятся собственные классы. Например, класс с регулярками для разбора смс хотел вынести в отдельный и подключать его в посредник-фильтер.

Вопрос на засыпку, стоит ли хранить системную информацию об объекте смс в отдельной таблице sms_meta? Или же пару лишних полей не испортят таблицу sms?