모델 상태를 Angular.js에 저장해야하는 위치

모델 상태를 Angular.js에 저장해야하는 위치

---

Angular의 모델 사용이 혼란 스럽습니다. Angular는 모델이 원하는 모든 것이 될 수 있다는 접근 방식을 취하는 것 같습니다. IE Angular는 명시 적 모델 클래스를 포함하지 않으며 바닐라 JavaScript 개체를 모델로 사용할 수 있습니다.

내가 본 거의 모든 Angular 예제에서 모델은 실제로 손으로 만들거나 리소스를 통해 API 호출에서 반환 된 객체입니다. 내가 살펴본 거의 모든 Angular 예제는 간단하기 때문에 일반적으로 컨트롤러의 $ scope에 저장된 모델 데이터와 모델과 관련된 모든 상태 (예 : 선택)도 컨트롤러의 $ scope에 저장됩니다. 간단한 앱 / 예제에서는 잘 작동하지만 앱이 더 복잡해지면 지나치게 단순화 된 것처럼 보입니다. 컨트롤러에 저장된 모델 상태는 컨텍스트가 될 위험이 있으며 컨텍스트가 변경되면 손실 될 위험이 있습니다. 컨트롤러는 저장 selectedGallery하고 selectedPhoto글로벌 만 저장할 수 있습니다 selectedImage.selectedPhoto갤러리 당. 이러한 상황에서 갤러리 당 컨트롤러를 사용하면이 문제가 해결 될 수 있지만 UI 관점에서 보면 낭비적이고 부적절하고 불필요 해 보일 수 있습니다.

Angular의 모델 정의는 서버와 클라이언트 사이에 전달되는 멍청한 객체 인 VO / DTO라고 생각하는 것과 비슷해 보입니다. 내 본능은 DTO / VO (예 : 선택)와 관련된 상태를 유지하고 DTO / VO를 조작하는 데 필요에 따라 뮤 테이터를 제공하고 나머지에 알리는 클래스 인 모델이라고 생각하는 것으로 이러한 객체를 래핑하는 것입니다. 기본 데이터에 대한 변경 적용. 분명히이 마지막 부분은 Angular의 바인딩에 의해 잘 처리되지만 처음 두 가지 책임에 대한 강력한 사용 사례를 볼 수 있습니다.

그러나 나는 내가 본 예제에서이 패턴이 실제로 사용되는 것을 보지 못했지만, 내가 확장 가능한 대안이라고 생각하는 것을 보지 못했다. Angular는 Singleton을 적용하여 서비스를 모델로 사용하는 것을 암시 적으로 권장하지 않는 것 같습니다 (이 문제를 해결할 수있는 방법이 있지만 널리 사용되거나 승인되지 않은 것 같습니다).

그렇다면 모델 데이터의 상태를 어떻게 유지해야합니까?

[편집] 이 질문 의 두 번째 대답 은 흥미롭고 제가 현재 사용하고있는 것과 비슷합니다.

---

상태 (및 모델)는 $ scope에 저장됩니다.

$ scope는 Angular의 데이터 저장 개체입니다. 데이터베이스와 유사합니다. $ scope 자체는 모델이 아니지만 $ scope에 모델을 저장할 수 있습니다.

각 $ scope에는 부모 $ scope가 있으며 $ rootScope까지 DOM을 느슨하게 미러링하는 트리 구조를 형성합니다. ng-controller와 같이 새 $ scope가 필요한 지시문을 호출하면 새 $ scope 개체가 생성되어 트리에 추가됩니다.

$ scope 개체는 프로토 타입 상속을 사용하여 연결됩니다. 즉, 트리의 상위 수준에서 모델을 추가하면 모든 하위 수준에서 사용할 수 있습니다. 이것은 $ scope 계층 구조를 템플릿 작성자에게 거의 투명하게 만드는 놀랍도록 강력한 기능입니다.

컨트롤러가 $ scope 초기화

컨트롤러의 목적은 $ scope를 초기화하는 것입니다 . 동일한 컨트롤러는 페이지의 다른 부분에서 많은 $ scope 개체를 초기화 할 수 있습니다. 컨트롤러가 인스턴스화되고 $ scope 개체를 설정 한 다음 종료됩니다. 동일한 컨트롤러를 사용하여 페이지의 다른 부분에서 많은 $ scope를 초기화 할 수 있습니다.

이미지 갤러리의 경우 ng-controller 지시문을 사용하여 갤러리가 될 DOM의 모든 부분에 적용 할 imageGallery 컨트롤러가 있습니다. 페이지의 해당 부분은 selectedPhoto 속성을 저장하는 데 사용할 자체 $ scope를 가져옵니다.

프로토 타입 범위

$ scope는 $ rootScope까지 평범한 오래된 프로토 타입 상속을 사용하여 부모로부터 상속하므로 계층 구조의 어느 곳에 나 적절한 개체를 저장할 수 있습니다. 현재 DOM과 대략적으로 관련된 $ scope 객체 트리를 얻습니다. DOM이 변경되면 필요에 따라 새 $ scope 객체가 생성됩니다.

$ scope는 단순한 JavaScript 객체입니다. 여러 개의 currentImage 객체로 배열을 만드는 것보다 여러 $ scope 객체를 만드는 것이 더 이상 낭비가 아닙니다. 코드를 구성하는 현명한 방법입니다.

이런 식으로 Angular는 자바 스크립트에서 자주 발견되는 "내 데이터를 어디에 저장합니까"라는 오래된 문제를 해결합니다. Angular에서 얻을 수있는 정말 큰 생산성 향상의 원천입니다.

글로벌 데이터 (예 : userId)가 있습니까? $ rootScope에 저장하십시오. 로컬 데이터 (예 : 여러 갤러리 인스턴스가있는 갤러리의 currentImage)가 있습니까? 해당 갤러리에 속한 $ scope 개체에 저장하십시오.

$ scope는 템플릿의 올바른 부분에서 자동으로 사용할 수 있습니다.

각도 모델은 얇습니다

뚱뚱한 모델과 마른 컨트롤러를 강조하는 Rails 배경에서 왔기 때문에 Angular의 '거의없는'모델이 놀랍다는 것을 알았습니다. 사실, 모델에 많은 비즈니스 로직을 넣는 것은 종종 Rails의 User 모델에서 볼 수 있듯이 문제가 발생할 수 있습니다. 조심하지 않으면 유지 보수가 불가능해질 때까지 커집니다.

각도 모델은 단순히 JavaScript 객체 또는 기본 요소입니다.

모든 개체가 모델이 될 수 있습니다. 모델은 일반적으로 컨트롤러에서 JSON을 사용하거나 서버에서 AJAX를 사용하여 정의됩니다. 모델은 JSON 객체이거나 문자열, 배열 또는 숫자 일 수 있습니다.

물론 원하는 경우 모델에 추가 기능을 추가하고 JSON 객체에 저장하는 것을 막을 수는 없지만 Angular와 실제로 맞지 않는 패러다임으로 포팅되는 것입니다.

Angular 객체는 일반적으로 함수가 아닌 데이터 저장소입니다.

프런트 엔드의 모델은 실제 모델이 아닙니다.

물론 당신이 클라이언트에게 가지고있는 모델은 실제 모델이 아닙니다. 실제 모델, 단일 진실 소스가 서버에 있습니다. API를 사용하여 동기화하지만 둘 사이에 충돌이있는 경우 데이터베이스의 모델이 분명히 궁극적 인 승리자입니다.

이것은 할인 코드 등과 같은 것에 대한 프라이버시를 제공합니다. 프런트 엔드에서 찾은 모델은 원격 인 실제 모델의 공용 속성의 동기화 된 버전입니다.

비즈니스 로직은 서비스에 존재할 수 있습니다.

예를 들어 모델에 작업을 수행하거나 동기화하거나 유효성을 검사하는 메서드를 작성하고 싶다고 가정 해 보겠습니다. 다른 프레임 워크에서는이를 수행하는 방법으로 모델을 확장하고 싶을 수 있습니다. Angular에서는 서비스를 작성할 가능성이 더 높습니다.

서비스는 싱글 톤 객체입니다. 다른 JavaScript 객체와 마찬가지로 함수 나 데이터를 넣을 수 있습니다. Angular는 $ http와 같은 여러 내장 서비스와 함께 제공됩니다. 직접 빌드하고 종속성 주입을 사용하여 컨트롤러에 자동으로 제공 할 수 있습니다.

서비스에는 예를 들어 RESTful API와 통신하거나 데이터의 유효성을 검사하거나 수행해야하는 기타 작업을위한 메서드가 포함될 수 있습니다.

서비스는 모델이 아닙니다

물론 서비스를 모델로 사용해서는 안됩니다. 물건을 할 수있는 물건으로 사용하십시오. 때때로 그들은 당신의 모델에 뭔가를합니다. 다른 사고 방식이지만 실행 가능한 방식입니다.

---

우선 Angular는 웹 기반 프레임 워크이며 개체에만 "상태를 유지"하면 사용자가 브라우저에서 새로 고침을 눌러도 살아남지 못합니다. 따라서 웹 기반 애플리케이션에서 모델 데이터의 상태를 유지하는 방법을 알아내는 것은 코드가 브라우저 환경에서 작동하도록 유지하는 방법을 파악하는 것을 의미합니다.

Angular는 다음을 사용하여 상태를 유지하는 것이 정말 쉽습니다.

1. RESTful $ resource에 대한 호출
2. 모델의 인스턴스를 나타내는 URL

간단한 예에서 selectedGallery및 같은 사용자 작업 저장은 selectedPhoto다음과 같은 URL을 사용하여 나타낼 수 있습니다.

// List of galleries
.../gallery

// List of photos in a gallery
.../gallery/23

// A specific photo
.../gallery/23/photo/2

URL은 사용자가 back및 forward버튼 을 사용하여 브라우저 기록을 탐색 할 수 있기 때문에 중요 합니다. 이 상태를 응용 프로그램의 다른 부분과 공유하려는 경우 웹 응용 프로그램은 쿠키 / localStorage, 숨겨진 프레임 / 필드를 사용하거나 서버에 저장하는 데 필요한 다양한 방법을 제공합니다.

애플리케이션의 다양한 상태를 유지하는 방법에 대한 전략을 정의한 후에는에서 제공하는 싱글 톤 객체를 사용 .service하거나를 통해 인스턴스를 사용하여 이러한 지속 된 정보에 액세스할지 여부를 결정하는 것이 더 쉬울 것 .factory입니다.

---

Angular does not have an opinion on how you store what you call "model objects". The Angular controller $scope exists solely as a "view model" for the purposes of managing your UI. I suggest separating these two concepts in your code.

If you want the nicety of Angular scope change notification ($watch), you can use a scope object to store your model data if you wish (var myScope = $rootScope.$new()). Just don't use the same scope object to which your UI is bound.

I recommend writing custom services to this end. So the data flow goes like this:

AJAX --> Custom Service --> Model Scope Object --> Controller --> UI Scope Object --> DOM

Or this:

AJAX --> Custom Services --> Plain old JavaScript Objects --> Controller --> UI Scope Object --> DOM

참고URL : https://stackoverflow.com/questions/16607874/where-should-model-state-be-stored-in-angular-js