Phoenix for Rails 개발자: 실용적인 예 - 섹션 2
11759 단어 elixirrailsphoenixframeworkbeginners
소개하다.
이 블로그의 첫 부분에서 우리는 Rails와 Phoenix의 웹 층에서의 비교를 토론했는데, 만약 당신이 아직 읽지 않았다면 시작합시다.다음에 우리는 데이터와 업무층이 어떻게 이 두 구조에서 실현되는지 볼 것이다.
이사하다
데이터를 정의하는 위치에서 시작하여 이동합시다.다음은 메모리를 새로 고치기 위한 ActiveRecord 마이그레이션입니다.
def change
create_table :articles do |t|
t.string :title
t.text :text
t.timestamps
end
end
지금은 엑토(피닉스의 ORM):def change do
create table(:articles) do
add :title, :string
add :text, :text
timestamps()
end
end
차이점에 주의했습니까?언뜻 보면 똑같아 보이지만, 자세히 살펴보면 첫 번째 코드 세그먼트는 대상을 대상으로 하는 방법을 사용했고, 두 번째 코드 세그먼트는 기능적인 것을 발견할 수 있다.이것은 우리로 하여금 이 흥분되는 새로운 틀에 Rails 지식을 응용하기 쉽게 한다. 우리는 문법을 약간 조정하기만 하면 되지만, 기초는 여전히 존재한다.예를 들어, 우리는 문장 제목에 독특한 제약을 추가할 것이다.def change do
create table(:articles) do
add :title, :string
add :text, :text
timestamps()
end
create unique_index(:articles, [:title])
end
따라서, 비록 이것은 추가 index: { unique: true }
의 일반적인 방법과 다를 수 있지만, 여전히 기존 테이블에 색인을 만드는 방식과 매우 유사하다.이게 바로 이곳에서 일어난 일이기 때문이다.모델 및 모델
여기서 우리는 첫 번째 거대한 차이를 발견했다.모델이 Rails 응용 프로그램의 핵심이지만 Phoenix는 모델만 있습니다.이런 것들은 기본적으로 데이터베이스 데이터를 포함하는 구조, 예를 들어 표 필드와 그 유형이다.이 데이터를 검증하고 오류 메시지를 생성하는 것도 책임진다.이 밖에도 데이터베이스에 대해 아무것도 모르고 업데이트나 삭제를 저장하지 않는다.하지만 충분히 이야기했으니 그들의 모습을 보자.
defmodule Blog.Articles.Article do
use Ecto.Schema
import Ecto.Changeset
schema "articles" do
field :text, :string
field :title, :string
timestamps()
end
def changeset(article, attrs) do
article
|> cast(attrs, [:title, :text])
|> validate_required([:title, :text])
|> unique_constraint(:title)
end
end
이 모든 것을 두려워하지 마라. |>
그것은 단지 파이프 조작부호일 뿐이다. (Unix와 같다.)그것은 단지 왼쪽의 결과를 오른쪽 함수의 첫 번째 매개 변수로 전달할 뿐이다.예를 들어cast의 첫 번째 매개 변수는 article
로 앞의 두 줄을 cast(article, attrs, [:title, :text])
와 등가시킨다.Phoenix 솔루션은 표준 ActiveRecord보다 더 지루합니다.
class Article < ApplicationRecord
validates :title, uniqueness: true
end
그러나 데이터 처리 방식 간의 또 다른 차이점을 보여주기 위해 이 새로운 유일성 제약을 사용하자. 이것은 Ecto가 같은 종류를 개선하는 한 방면이라고 생각한다.글 모드의 changeset
함수를 보면 마지막 줄에서 글과 제약 호출 unique_constraint
함수를 사용합니다.이것은 데이터베이스에서 가능한 이상을 받기 위해 준비한 것일 뿐, 아무런 조회도 하지 않고, 이 검증을 데이터베이스에 의뢰할 뿐이다.이것은 Ecto의 이념 중 하나로 제약 검증은 데이터베이스에 속하고 제약을 검사할 때 효율이 높으며 최종적으로 대부분의 시스템에서 제약을 검증한다.언어 환경
맞아요!내가 가장 좋아하는 부분은 상업 논리다.Phoenix의 모델은 데이터베이스를 호출하지 않고 단지 하나의 데이터만 호출한다고 말한 것을 기억하십니까?데이터베이스 호출이 어디에 있는지 알고 싶을 것입니다. 바로 위아래 문장에 있습니다.
defmodule Blog.Articles do
@moduledoc """
The Articles context.
"""
import Ecto.Query, warn: false
alias Blog.Repo
alias Blog.Articles.Article
def list_articles do
Repo.all(Article)
end
def get_article!(id), do: Repo.get!(Article, id)
def create_article(attrs \\ %{}) do
%Article{}
|> Article.changeset(attrs)
|> Repo.insert()
end
def update_article(%Article{} = article, attrs) do
article
|> Article.changeset(attrs)
|> Repo.update()
end
def delete_article(%Article{} = article) do
Repo.delete(article)
end
def change_article(%Article{} = article) do
Article.changeset(article, %{})
end
end
마찬가지로 이것은 기능 모델에 따라 상하문에서 하는 일은 데이터와 상호작용하는 방법을 제공하고 저장소 모델을 사용하여 실현하는 것이다.만약 이 개념에 익숙하지 않다면 데이터베이스(또는 다른 저장소)의 추상적인 것으로 간주할 수 있으며, 여기서 필요한 데이터를 보내서 조회하고 갱신하며 기록을 만들 수 있다.이런 모델은 상하문이 쉽게 이해된 후에 데이터를 저장 방식에서 분리할 수 있게 한다.이런 데이터 층과 업무 논리를 관리하는 방식은 기회의 세계를 열었다.예를 들어 블로그에 게시하는 절차가 있다고 가정하면 모든 글은 변경 후 게시 전에 검토해야 한다.우리는 우리의 모델에서 검증을 할 수 있으며, 비준을 받은 상태에서만 그것을 삽입할 수 있으며, 우리의 상하문에서도 마찬가지다.그러나 우리도 관리자가 이러한 검증을 빙빙 돌려서 할 수 있도록 허용하는 것을 좋아한다. 이것은 흔히 볼 수 있는 상황이며, 수시로 발표된다.따라서 Rails에서는 이러한 새로운 상황을 반영하기 위해 코드를 변경할 수도 있고 Phoenix에서는 새로운 상하문을 만들기를 원할 수도 있습니다.
어떤 선택과 마찬가지로, 당신은 항상 장점과 단점을 가지고 있지만, 나는 상하문이 당신이 서로 다른 책임을 가진 모델을 오염시키지 않도록 허락하는 방식을 정말 좋아한다.만약 당신이 Rails에서 충분한 시간을 일했다면, 당신은 그들이 서비스 대상과 비슷한 용도를 가지고 있다는 것을 알게 될 것입니다. 지역사회는 이러한 서비스 대상을 받아들였습니다. 이것은 우리의 일상적인 개발 주기의 일부분입니다.
결론
내가 Rails와 일하는 방식에 흙을 많이 뿌렸다고 생각할 수도 있으니 더 이상 Rails를 사용하지 말고 Phoenix를 사용하자고 제안합니다.이것은'왜 X가 썩었는지, 너는 모든 코드를 Y로 옮겨야 한다'는 것이 아니라,'헤이, 이 멋진 새로운 도구를 봐라. 너는 그것이 매우 유용하다/재미있다는 것을 발견할 수 있을 것이다'.나는 여전히 매일 Rails를 사용하고 있다. 나는 Rails의 작업 방식을 좋아하고, 시범자, 서비스, 폼 대상과 다른 많은 것들을 줄일 수 있는 방법도 많다.
따라서 만약 당신도 Rails를 좋아한다면 Phoenix를 시도해 보세요. 당신은 처음부터 그 어떤 신기술과도 싸울 수 있지만, 그것은 나처럼 당신에게서 성장할 것이라고 믿습니다.학습을 시작하기 위해서 저는 공식 안내서를 추천합니다. 안내서는 매우 우호적이고 완전합니다.
Reference
이 문제에 관하여(Phoenix for Rails 개발자: 실용적인 예 - 섹션 2), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/rootstrap/phoenix-for-rails-developers-a-practical-example-part-2-374k텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)