Backbone.js 모델 데이터를 저장하는 방법?

Question 1

나는 프론트 엔드 개발에 더 관심이 있으며 최근에 내 앱에서 Backbone.js를 탐색하기 시작했습니다. 모델 데이터를 서버에 유지하고 싶습니다.

모델 데이터를 저장하는 다양한 방법 (json 형식 사용)에 대해 설명해 주시겠습니까? 서버 측에서 Java를 사용하고 있습니다. 또한 주로 REST가 데이터를 저장하는 데 사용되는 것을 보았습니다. 나는 프론트 엔드 개발에 더 관심이 많기 때문에 REST 및 기타 유사한 것들을 알지 못합니다.

누군가가 간단한 예를 들어 과정을 설명해 주시면 좋을 것입니다.

Question 2

기본적으로 모델에는 특정 모델이 가질 수있는 다양한 값인 속성이라는 속성이 있습니다. Backbone은 JSON 객체를 사용하는 다양한 방법을 사용하여 이러한 값을 채우는 간단한 방법으로 JSON 객체를 사용합니다. 예:

Donuts = Backbone.Model.extend({
    defaults: {
        flavor: 'Boston Cream',  // Some string
        price: '0.50'  // Dollars
    }
});

모델을 채우려면 몇 가지 방법이 있습니다. 예를 들어 JSON을 전달하여 모델 인스턴스를 설정하거나 속성의 JSON 개체를 사용하는 set () 메서드를 사용할 수 있습니다.

myDonut = new Donut({'flavor':'lemon', 'price':'0.75'});
mySecondHelping = new Donut();
mySecondHelping.set({'flavor':'plain', 'price':'0.25'});

console.log(myDonut.toJSON());
// {'flavor':'lemon', 'price':'0.75'}
console.log(mySecondHelping.toJSON());
// {'flavor':'plain', 'price':'0.25'}

그래서 이것은 모델을 저장하고 서버에 유지하도록합니다. "REST / RESTful이란 무엇입니까?"에 관한 많은 세부 정보가 있습니다. 그리고이 모든 것을 짧은 설명으로 설명하기는 다소 어렵습니다. 특히 REST 및 백본 저장과 관련하여 머리를 감싸는 것은 HTTP 요청의 의미와 데이터로 수행하는 작업입니다.

두 가지 종류의 HTTP 요청에 익숙 할 것입니다. GET 및 POST. RESTful 환경에서 이러한 동사는 Backbone이 가정하는 특정 용도에 대해 특별한 의미를 갖습니다. 서버에서 특정 리소스 (예 : 지난 시간에 저장 한 도넛 모델, 블로그 항목, 컴퓨터 사양)를 얻고 싶을 때 해당 리소스가 존재하면 GET 요청을 수행합니다. 반대로 새 리소스를 만들려면 POST를 사용합니다.

Backbone에 들어가기 전에 다음 두 가지 HTTP 요청 메서드를 건드리지 않았습니다. PUT 및 DELETE. 이 두 동사는 또한 Backbone에 특정한 의미를 가지고 있습니다. 리소스를 업데이트하려면 (예 : 레몬 도넛의 맛을 리몬 도넛으로 변경하는 등) PUT 요청을 사용합니다. 서버에서 해당 모델을 모두 삭제하려면 DELETE 요청을 사용합니다.

RESTful 앱을 사용하면 사용하는 요청 동사의 종류에 따라 적절한 작업을 수행하는 URI 지정이 있기 때문에 이러한 기본 사항은 매우 중요합니다. 예를 들면 :

// The URI pattern
http://localhost:8888/donut/:id

// My URI call
http://localhost:8888/donut/17

해당 URI에 GET을 만들면 ID가 17 인 도넛 모델을 얻을 수 있습니다. : id는 서버 측에 저장하는 방법에 따라 다릅니다. 이것은 데이터베이스 테이블에있는 도넛 리소스의 ID 일 수 있습니다.

새 데이터로 해당 URI에 PUT를 만들면이를 업데이트하여 저장합니다. 그리고 해당 URI로 삭제하면 시스템에서 제거됩니다.

POST를 사용하면 리소스를 아직 만들지 않았으므로 설정된 리소스 ID가 없습니다. 리소스를 생성하려는 URI 대상은 다음과 같습니다.

http://localhost:8888/donut

URI에 ID 조각이 없습니다. 이러한 모든 URI 디자인은 사용자와 리소스에 대한 생각에 달려 있습니다. 그러나 RESTful 디자인과 관련하여 내 이해는 HTTP 요청에 대한 동작의 동사를 유지하고 URI를 읽기 쉽고 인간 친화적으로 만드는 명사로 리소스를 유지하고 싶다는 것입니다.

아직도 나와 함께있어? :-)

이제 Backbone에 대해 다시 생각해 보겠습니다. 백본은 당신을 위해 많은 일을하기 때문에 훌륭합니다. 도넛과 secondHelping을 저장하려면 다음과 같이하면됩니다.

myDonut.save();
mySecondHelping.save();

백본은 똑똑합니다. 방금 도넛 리소스를 만든 경우 서버의 ID가 없습니다. Backbone이 내부적으로 사용하는 cID라는 것이 있지만 공식 ID가 없기 때문에 새 리소스를 만들어야한다는 것을 알고 POST 요청을 보냅니다. 서버에서 모델을 얻은 경우 모든 것이 맞다면 ID가있을 것입니다. 이 경우 save () Backbone은 서버를 업데이트하고 싶다고 가정하고 PUT를 보냅니다. 특정 리소스를 얻으려면 Backbone 메서드 .fetch ()를 사용하고 GET 요청을 보냅니다. 모델에서 .destroy ()를 호출하면 DELETE를 보냅니다.

이전 예에서는 URI가 어디에 있는지 Backbone에 명시 적으로 알려주지 않았습니다. 다음 예제에서 그렇게합시다.

thirdHelping = Backbone.Model.extend({
    url: 'donut'
});
thirdHelping.set({id:15});  // Set the id attribute of model to 15
thirdHelping.fetch();  // Backbone assumes this model exists on server as ID 15

Backbone은 세 번째를 얻을 http://localhost:8888/donut/15것입니다 .Helping at It은 단순히 사이트 루트에 / donut stem을 추가합니다.

당신이 여전히 나와 함께 있다면 좋습니다. 나는 생각한다. 당신이 혼란스럽지 않는 한. 그러나 어쨌든 우리는 터벅 터벅 걸어 갈 것입니다. 두 번째 부분은 SERVER 측입니다. 우리는 HTTP의 다양한 동사와 그 뒤에있는 의미 론적 의미에 대해 이야기했습니다. 귀하, 백본 및 귀하의 서버가 공유해야 함을 의미합니다.

서버는 GET, POST, PUT 및 DELETE 요청의 차이점을 이해해야합니다. 위의 예에서 보았 듯이 GET, PUT 및 DELETE는 모두 동일한 URI를 가리킬 http://localhost:8888/donut/07수 있습니다. 서버가 이러한 HTTP 요청을 구별 할 수없는 경우 해당 리소스로 수행 할 작업에 대해 매우 혼란 스러울 것입니다.

이것은 RESTful 서버 종료 코드에 대해 생각하기 시작할 때입니다. 어떤 사람들은 Ruby를 좋아하고 어떤 사람들은 .net을 좋아하고 저는 PHP를 좋아합니다. 특히 저는 SLIM PHP 마이크로 프레임 워크를 좋아합니다. SLIM PHP는 RESTful 활동을 처리하기위한 매우 우아하고 간단한 도구 세트가있는 마이크로 프레임 워크입니다. 위의 예에서와 같이 경로 (URI)를 정의 할 수 있으며 호출이 GET, POST, PUT 또는 DELETE인지에 따라 올바른 코드를 실행합니다. Recess, Tonic과 같은 SLIM과 유사한 다른 솔루션이 있습니다. 저는 Cake와 CodeIgniter와 같은 더 큰 프레임 워크도 최소한의 것을 좋아하지만 비슷한 일을한다고 생각합니다. 내가 슬림을 좋아한다고 말했나? ;-)

이것은 서버의 발췌 코드가 보일 수있는 것입니다 (즉, 특히 경로와 관련하여).

$app->get('/donut/:id', function($id) use ($app) {
    // get donut model with id of $id from database.
    $donut = ...

    // Looks something like this maybe:
    // $donut = array('id'=>7, 'flavor'=>'chocolate', 'price'=>'1.00')

    $response = $app->response();
    $response['Content-Type'] = 'application/json';
    $response->body(json_encode($donut));
});

여기서 Backbone은 JSON 객체를 기대한다는 점에 유의하는 것이 중요합니다. 항상 서버에서 콘텐츠 유형을 'application / json'으로 지정하고 가능한 경우 json 형식으로 인코딩하십시오. 그런 다음 Backbone이 JSON 객체를 수신하면 요청한 모델을 채우는 방법을 알고 있습니다.

SLIM PHP를 사용하면 경로가 위와 비슷하게 작동합니다.

$app->post('/donut', function() use ($app) {
    // Code to create new donut
    // Returns a full donut resource with ID
});
$app->put('/donut/:id', function($id) use ($app) {
    // Code to update donut with id, $id
    $response = $app->response();
    $response->status(200);  // OK!
    // But you can send back other status like 400 which can trigger an error callback.
});
$app->delete('/donut/:id', function($id) use ($app) {
    // Code to delete donut with id, $id
    // Bye bye resource
});

그래서 거의 모든 왕복 여행을 마쳤습니다! 가서 탄산 음료 마시기. 저는 Diet Mountain Dew를 좋아합니다. 나도 하나 사주세요.

서버가 요청을 처리하고 데이터베이스 및 리소스로 작업을 수행하고 응답을 준비하면 (단순 http 상태 번호이든 전체 JSON 리소스이든) 최종 처리를 위해 데이터가 Backbone으로 돌아옵니다.

save (), fetch () 등의 메소드를 사용하여 성공 및 오류에 대한 선택적 콜백을 추가 할 수 있습니다. 다음은이 특정 케이크를 설정하는 방법의 예입니다.

Cake = Backbone.Model.extend({
    defaults: {
        type: 'plain',
        nuts: false
    },
    url: 'cake'
});

myCake = new Cake();
myCake.toJSON()  // Shows us that it is a plain cake without nuts

myCake.save({type:'coconut', nuts:true}, {
    wait:true,
    success:function(model, response) {
        console.log('Successfully saved!');
    },
    error: function(model, error) {
        console.log(model.toJSON());
        console.log('error.responseText');
    }
});

// ASSUME my server is set up to respond with a status(403)
// ASSUME my server responds with string payload saying 'we don't like nuts'

이 예제에는 몇 가지 다른 점이 있습니다. 내 케이크에 대해 저장하기 전에 속성을 set ()하는 대신 새 속성을 저장 호출에 전달했음을 알 수 있습니다. Backbone은 JSON 데이터를 모든 곳에서 가져와 챔피언처럼 처리하는 데 꽤 닌자입니다. 그래서 저는 코코넛과 견과류로 케이크를 저장하고 싶습니다. (그게 견과류 2 개인가요?) 어쨌든, 나는 두 개의 물건을 내 저장에 전달했습니다. 속성 JSON 개체 및 일부 옵션. 첫 번째, {wait : true}는 서버 측 트립이 성공할 때까지 클라이언트 측 모델을 업데이트하지 않음을 의미합니다. 성공 콜백은 서버가 성공적으로 응답을 반환 할 때 발생합니다. 그러나이 예에서 오류가 발생하기 때문에 (200이 아닌 상태는 Backbone에 오류 콜백을 사용하도록 표시됨) 변경없이 모델을 표시합니다. 여전히 평범하고 견과류가 없어야합니다. 또한 서버가 다시 보낸 오류 개체에 액세스 할 수 있습니다. 문자열을 다시 보냈지 만 더 많은 속성이있는 JSON 오류 개체 일 수 있습니다. 이것은 error.responseText 속성에 있습니다. 예, '우리는 견과류를 좋아하지 않습니다.'

축하합니다. 모델을 설정하고 서버 측에 저장 한 후 돌아 오는 첫 번째 왕복 여행을 완료했습니다. 이 답변 서사시가이 모든 것이 어떻게 결합되는지에 대한 아이디어를 제공하기를 바랍니다. 물론 내가 과거에 순항하고있는 많은 세부 사항이 있지만 Backbone save, RESTful 동사, Server-side action, Response의 기본 아이디어가 여기에 있습니다. Backbone 문서 (다른 문서에 비해 읽기 쉬움)를 계속 살펴 보되, 머리를 감싸는 데 시간이 걸린다는 점을 명심하십시오. 더 많이할수록 더 유창해질 것입니다. 저는 Backbone을 통해 매일 새로운 것을 배우고 있습니다. 도약을 시작하고이 프레임 워크에 대한 유창함이 커지는 것을 보면 정말 재미있어집니다. :-)

즐거운 코딩 되세요!

편집 : 유용 할 수있는 리소스 :

SO에 대한 다른 유사한 답변 : Backbone으로 모델 ID를 생성하는 방법

REST : http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic- 팁