произойти, если вы используете такие вещи, как переменные класса. Однако это не означает, что использование переменной класса всегда плохо. Все зависит от контекста. Например, наш менеджер сущностей использует его для хранения ссылки на DB::Database. В данном случае это нормально, поскольку оно остается закрытым внутри нашего класса и представляет собой пул соединений. Благодаря этому каждый запрос может при необходимости получить собственное соединение с базой данных. Мы также не храним в нем какое-либо состояние, специфичное для запроса, поэтому оно остается чистым.

Аннотация ADI::Register сообщает контейнеру службы, что этот тип следует рассматривать как службу, чтобы его можно было внедрить в другие службы. Функции DI Athena невероятно мощны, и я настоятельно рекомендую прочитать более подробный список их возможностей.

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

Теперь, когда у нас есть все необходимые условия, мы можем, наконец, настроить постоянство статей, причем первым шагом будет предоставление нашему менеджеру объектов доступа к ArticleController. Для этого мы можем сделать контроллер службой и определить инициализатор, который создаст переменную экземпляра типа Blog::Services::EntityManager, например:

@[ADI::Register(public: true)]

class Blog::Controllers::ArticleController < ATH::Controller

  def initialize(@entity_manager : Blog::Services::

    EntityManager);

  end

  # ...

end

По причинам реализации служба должна быть общедоступной, следовательно, поле public: true в аннотации. Разрешено извлекать общедоступную службу непосредственно по типу или имени из контейнера, а не только через конструктор DI.. Это может измениться в будущем. Как только мы это сделаем, мы сможем ссылаться на нашего менеджера сущностей, как и на любую другую переменную экземпляра.

На данный момент нам действительно нужно добавить только одну строку, чтобы сохранить наши статьи. Метод #create_article теперь должен выглядеть так:

def create_article(article : Blog::Entities::Article) :

  Blog::Entities::Article

  @entity_manager.persist article

  article

end

Хотя действие контроллера выглядит простым, под капотом происходит немалое:

• Преобразователь тела запроса будет обрабатывать десериализацию и выполнять проверки.

• Менеджер объектов сохраняет десериализованный объект.

• Сущность можно просто вернуть напрямую, поскольку для нее будет установлен идентификатор и сериализована в формате JSON, как и ожидалось.

Давайте повторим наш запрос cURL ранее:

curl --request POST 'http://localhost:3000/article'

--header 'Content-Type: application/json'

--data-raw '{

  "title": "Title",

  "body": "Body"

}'

Это приведет к ответу, подобному этому:

{

  "id": 1,

  "title": "Title",

  "body": "Body",

  "updated_at": "2022-04-09T04:47:09Z",

  "created_at": "2022-04-09T04:47:09Z"

}

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

Получение статей

Хотя мы могли бы просто добавить к нему несколько методов для обработки запросов, было бы лучше иметь выделенный тип Repository, специфичный для запросов, который мы могли бы получить через диспетчер сущностей. Давайте создадим src/entities/article_repository.cr со следующим содержимым:

class Blog::Entities::Article::Repository

  def initialize(@database: DB::Database); end

  def find?(id : Int64) : Blog::Entities::Article?

    @database.query_one?(%(SELECT * FROM "articles" WHERE "id"

        = $1 AND "deleted_at" IS NULL;), id, as:

            Blog::Entities::Article)

  end

  def find_all : Array(Blog::Entities::Article)

    @database.query_all %(SELECT * FROM "articles" WHERE

    "deleted_at" IS NULL;), as: Blog::Entities::Article

  end

end

Это довольно простой объект, который принимает DB::Database и действует как место для всех запросов, связанных со статьей. Нам нужно предоставить это из типа менеджера объектов, что мы можем сделать, добавив следующий метод:

def repository(entity_class : Blog::Entities::Article.class) :

  Blog::Entities::Article::Repository

    @@article_repository ||=

      Blog::Entities::Article ::Repository.new

      @@database

end

Этот подход позволит добавить перегрузку #repository для каждого класса сущности, если в будущем будут добавлены другие. Опять же, мы могли бы, конечно, реализовать что-то более изысканным и надежным способом, но, учитывая, что у нас будет только одна сущность, использование перегрузок при кэшировании репозитория в переменной класса будет достаточно хорошим. Как говорится, преждевременная оптимизация — корень всех зол.

Теперь, когда у нас есть возможность получать все статьи, а также отдельные статьи по идентификатору, мы можем перейти к созданию конечных точек, добавив в контроллер статей следующие методы:

@[ARTA::Get("/article/{id}")]

def article(id : Int64) : Blog::Entities::Article

  article = @entity_manager.repository(Blog::Entities::Article)

    .find? Id

if article.nil?

  raise ATH::Exceptions::NotFound.new "An item with the provided ID could not be found."

end

  article

end

@[ARTA::Get("/article")]

def articles : Array(Blog::Entities::Article)

  @entity_manager.repository(Blog::Entities::Article).find_all end

Первая конечная точка вызывает #find? метод для возврата статьи с предоставленным идентификатором. Если он не существует, он возвращает более полезный ответ об ошибке 404. Следующая конечная точка возвращает массив всех сохраненных статей.

Как и раньше, когда мы начали с конечной точки #create_article и узнали об ATH::RequestBodyConverter, существует лучший способ обработки чтения конкретной статьи из базы данных. Мы можем определить наш собственный преобразователь параметров, который будет использовать параметр пути идентификатора, извлекать его из базы данных и передавать в действие, при этом он будет достаточно универсальным, чтобы его можно было использовать для других имеющихся у нас объектов. Создайте src/param_converters/database.cr со следующим содержимым, гарантируя, что этот новый каталог также необходим в src/blog.cr:

@[ADI::Register]

class Blog::Converters::Database < ATH::ParamConverter

  def initialize(@entity_manager : Blog::Services

   ::EntityManager);

  end

  # :inherit:

  def apply(request : ATH::Request, configuration :

    Configuration(T)) : Nil forall T

    id = request.attributes.get "id", Int64

      unless model = @entity_manager.repository(T).find? Id

      raise ATH::Exceptions::NotFound.new "An item with the provided ID could not be found."

  end

  request.attributes.set configuration.name, model, T

  end

end

Как и в случае с предыдущим прослушивателем, нам нужно сделать прослушиватель сервисом с помощью аннотации ADI::Register. Фактическая логика включает в себя извлечение параметра пути идентификатора из атрибутов запроса, использование его