Crystal Programming. Введение на основе проекта в создание эффективных, безопасных и читаемых веб-приложений и приложений CLI

В нашем контексте на практике это означает, что мы можем заставить логику 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 ||=