링크:/question/26712920/answer/33768647

출처: 지평.

저작권은 저자가 소유하니 허가는 저자에게 연락해 주십시오.

개인적인 조언을 드리겠습니다.

제품 형태로는 Angular 를 사용해도 되지만, 이 경우 jQuery 를 도입할 필요는 없다. BootStrap 은 적절한 선택이지만 style 은 JS 를 소개할 필요가 없습니다. 제품 UI 의 복잡성이 높지 않아 DOM 을 수동으로 조작할 필요가 거의 없기 때문에 JS 라이브러리를 도입해야 할 수도 있습니다. Angular 외에도 몇 가지 유사한 텍스트 편집기, 코드 강조 등이 있습니다. 나는 대충 훑어보았는데, 처리가 잘 되었다고 느꼈다.

라우팅도 계획되어 있습니다. 그렇습니다. 기본 접두사는 좀 이상합니다. 。 。

컨트롤러 코드에 대해 할 말이 있습니다.

코드는 실제로 계층화되지 않습니다. Angular 에서 소위 컨트롤러라고 하는 것은 사실 뷰 모델이다. 안에 있는 것은 기본적으로 뷰에 직접 필요한 것이어야 한다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언) 그게 무슨 뜻이에요? 특별히 단순하지 않은 프로세스가 있다면, 뷰에는 이 프로세스의 결과만 있으면 됩니다. 프로세스를 앞으로 밀고 서비스로 만든 다음 서비스를 호출하여 컨트롤러의 데이터를 얻을 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언)

이 코드를 받으면 데이터 획득과 관련된 코드를 추출할 수 있다고 합니다. 즉, $http.get 입니다. 다른 컨트롤러에서 재사용될 가능성이 높기 때문입니다. 따라서 유형별로 다른 서비스에 넣으면 각 서비스의 방법이 promise 로 반환되므로 더욱 명확해집니다. 인터페이스의 여러 뷰에 대한 일부 데이터가 전역적으로 동기화되어야 하는 경우와 같이 데이터를 즐길 필요가 있다면, 서비스를 사용하여 store 를 만들고 이 데이터 모델을 singleton 으로 저장하여 서로 다른 뷰 모델을 함께 잡을 수도 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마), 스포츠명언)

또한 일부 섹션에서는 컨트롤러에서 직접 DOM 코드를 처리하는 것이 좋지 않습니다. 이와 같은 일은 일반적으로 directive 에 개별적으로 제출되므로 뷰 모델에 배치하지 마십시오. 이 부분을 다시 생각해 보세요.