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

Это серия из 4 частей, в которых рассказывается, как настроить проект, начать работу с маршрутизацией, настроить базу данных и, наконец, создать модель и контроллеры нашего приложения. Чтобы увидеть часть 1, нажмите здесь.

Введение

В этой заключительной части я опишу структуру проекта, модель, modelAPI и RouteController, используемые в приложении.

Модели и немного домашнего хозяйства

Айв решает разделить мой проект на следующие классы.

  • Объект модели: это будет представление объекта нашей базы данных. Это выполнит любые действия с базой данных.
  • Объект modelAPI: он будет принимать запросы, взаимодействовать с моделью и возвращать маршрутизатору что-то полезное.
  • RouteController: который будет обрабатывать маршрутизацию нашего приложения.
  • main: который, если все пойдет хорошо, будет красивым и коротким и на самом деле не будет делать ничего, кроме настройки нашей БД.

Это позволяет хорошо сгруппировать обязанности.

Модель

Итак, на этом этапе нам нужно решить, как должна выглядеть наша модель. Ради учебника я собираюсь предположить, что он просто имеет id, description, priority и значение, должно ли оно быть visible или нет.

Нам нужно переопределить два метода…

override func table() -> String
override func to(_ this: StORMRow)

Это позволяет нам идентифицировать таблицу, которой соответствует модель, и переводит наш объект БД в модель приложения, которую мы можем использовать.

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

МодельAPI

ListItemAPI будет обрабатывать запросы от маршрутизатора и иметь доступ к модели для выполнения некоторых важных задач. Во многих случаях его методы возвращают String?, а это, в свою очередь, возвращается в теле ответа.

Маршрутизатор

Мы создадим класс с именем TodoListRouter, который будет обрабатывать любой запрос к localhost:8080/todolist. У нас будет 4 маршрута для создания.

Route(method: .get, uri: "/todolist", handler: indexView)
Route(method: .post, uri: "/todolist", handler: addItem)
Route(method: .post, uri: "/todolist/{id}/delete", handler: delete)
Route(method: .post, uri: "/todolist/{id}/complete", handler: complete)

У нас есть post и get до /todolist, которые мы будем использовать для отображения списка элементов или создания нового. Мы можем удалить элемент, а также пометить его как завершенный.

Уборка

Я также расширил HTTPResponse двумя методами. Стандартный заполненный заголовок и внутренняя ошибка сервера.

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

typealias JSONDictionary = [String: Any]
typealias JSONArray = [JSONDictionary]

HTML

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

Вывод

Если вы хотите скачать весь проект и попробовать его, просто перейдите по этой ссылке.

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

Обязательно ознакомьтесь с идеальной документацией для большего количества примеров проектов, а также с потрясающей серией видеороликов Рэя Вендерлиха о Swift на стороне сервера с Perfect.

Дальнейшая работа и улучшения

Основная функция, которую я добавлю в приложение, — это способ обновлять элементы как часть списка.

Еще одной функцией может быть временная метка createdOn и временная метка completedOn, включенная в базу данных.

Еще некоторые улучшения заключались бы в обобщении используемых в модели методов — меня не совсем устраивает структура приложения. Если бы у нас было приложение с несколькими моделями, у нас было бы много шаблонного кода в моделях и в modelAPI. Я думаю, что следующими шагами будет найти способ уменьшить это и уменьшить сложность самой модели.

Я также хотел бы уменьшить зависимость от PostgresSQL. Было бы неплохо, если бы приложение могло создать базу данных, если она не найдена. Это помогло бы с идеей иметь возможность запускать сервер локально гораздо проще.

Vapor — еще одна библиотека Swift на стороне сервера, которая привлекает много внимания. Я хотел бы попробовать пересоздать приложение с помощью Vapor.

Наконец, сервер работает с Xcode, поэтому я хотел бы запустить его в Linux.