Последние две недели я учился разрабатывать серверные API с помощью среды PHP ThinkPHP. Теперь подведите итоги и запишите, что необходимо сделать для разработки интерфейса, чтобы повысить эффективность разработки и обеспечить хорошую масштабируемость.
1. Обзор процесса
В основном это процесс, пропустите создание среды:
- Разберитесь, какие интерфейсы
- Лист проектных данных
- Предварительный кардинг один к одному, один ко многим или многие ко многим
- написать валидатор
- Напишите глобальный класс исключений (идея АОП)
- определить пути маршрутизации
- Создайте класс контроллера
- Создайте класс модели
- Используйте ORM, поэтому создайте класс модели, соответствующий таблице данных
- Контроллер вызывает модель, модель вызывает базу данных, а интерфейс пишется
Во-вторых, конкретное описание
Разобравшись с интерфейсами, приступаем к проектированию таблицы данных:
Таблица данных будет корректироваться и изменяться по мере написания кода.
Стоит отметить, что когда между двумя таблицами существует отношение «многие ко многим», не забудьте разработать промежуточную таблицу для хранения соответствующих идентификаторов двух таблиц.
После разработки таблицы данных начните писать несколько классов инструментов, которые помогут повысить эффективность написания бизнес-кода.
Первый — валидатор (validate).
Фреймворк TP5 поставляется с классом валидатора.Что нам нужно сделать, так это наследовать этот класс валидатора, а затем расширить его в соответствии с конкретным интерфейсом.
Создайте базовый класс валидатора и поместите в него общие методы:
Метод goCheck() — это метод, который будут вызывать все определенные валидаторы, и каждый конкретный валидатор просто переписывает некоторые правила проверки и возвращаемую информацию проверки.
В методе goCheck() создается экземпляр класса Request. Целью этого является получение параметров, переданных вызывающей стороной при вызове API. После того, как параметры получены, естественно проверить эти параметры. Метод check() вызовет функцию правила проверки, установленную в каждом конкретном валидаторе для обнаружения.
Затем есть глобальный класс исключений (глобальное исключение).
Точно так же инфраструктура TP5 поставляется с классом исключения, поэтому мы создаем базовый класс исключения, чтобы наследовать его.
Затем необходимо переписать код состояния HTTP, сообщение об ошибке и код ошибки в соответствии с конкретным интерфейсом.
Что касается определения кода ошибки, то он заключается в разработке набора спецификаций самостоятельно.
После создания валидатора и глобального класса исключений нам нужно только вызвать их в функции каждого интерфейса:
Итак, основные вещи построены, приступим к написанию кода интерфейса.
Сначала определите путь маршрутизации:
В route.php введите класс Route и определите путь. Переменные в пути представлены: номер + имя переменной.Переменные в пути получаются функцией, указанной в конце пути, которая определена в соответствующем классе контроллера.
Например, переменная id:
Как показано на рисунке выше, в контроллере, когда мы получаем параметры, переданные вызывающей стороной через путь маршрутизации, мы вызываем модель, передаем параметры, и модель обрабатывает определенные вызовы базы данных.
Здесь также следует обратить внимание на то, что контроллер максимально выполняет только подключение, а не конкретные операции.
Затем, после того, как контроллер установлен, логично установить соответствующую модель.
TP5 также поставляется с классом Model, а затем мы также определяем наш собственный базовый класс модели, который, конечно, также наследует класс модели TP5:
Базовый класс модели, естественно, является более общим способом его определения. Например, в приведенном выше примере определен метод для возврата ссылки префикса изображения. Если интерфейс отличается, но связан с вызовом изображения, этот метод будет использоваться для объединения URL-адреса изображения.
Здесь тоже есть что отметить. Когда нам нужно создать глобальные переменные, мы можем создать дополнительный файл каталога в каталоге приложения, затем создать файл settings.php и вернуть в нем ассоциативный массив:
Последующие вызовы, как показано в методе prefixImgUrl в базовом классе модели выше, функция конфигурации, параметры передаются в имени файла плюс значение ключа ассоциативного массива, чтобы вы могли его получить:
Возвращаясь к модели, каждый интерфейс будет иметь свой собственный класс модели, который соответствует таблице данных, например:
Поскольку класс модели Banner наследует класс Model TP5 через базовый класс модели, все, что нам нужно сделать, это переписать некоторые свойства, чтобы адаптироваться к этому конкретному интерфейсу, например, переписать свойство $hidden, чтобы определить, из каких полей мы хотим возвращать данные. этот интерфейс скрыт.
Тогда это один из ключевых моментов ORM, вызывающий класс модели, соответствующий таблице данных. Например, в методе items связь между моделью Banner и моделью BannerItem определяется методом hasMany(). Затем в методе getBannerById() вызывается метод, используемый ORM для работы с данными, который является инкапсуляцией исходного оператора базы данных операции, а затем ORM возвращает объект модели, который будет иметь некоторые атрибуты в дополнение к данные базы данных и методы манипулирования данными. Это преимущество ORM по сравнению с собственными операторами SQL.
Наконец, контроллер вызывает метод модели getBannerById(), получает данные и затем передает их вызывающей стороне интерфейса в качестве возвращаемого значения интерфейса. На этом написание интерфейса завершено.
3. Резюме
На данный момент сделан краткий отчет о процессе разработки внутреннего API. Есть еще много не упомянутых деталей, просто краткое описание процесса, но это не основная цель данной записи. Цель этого времени — записать много нового на этой неделе.
Благодаря этому изучению разработки внутренних API я еще больше укрепил свое понимание и применение идей объектно-ориентированного программирования.
Благодаря наследованию и переопределению код может быть написан более четко и лаконично.
Классы, экземпляры, свойства, методы, как с ними обращаться, а затем управлять ими, благодаря этому изучению я углубил понимание.