찾다

집  >  Q&A  >  본문

angular.js - AngularJS是不是不适合地图类应用

看了AngularJS官网的一些例子，觉得很给力，将开发人员的注意力从满屏的DOM操作中转移到传统的业务中，以数据为中心，绑定View，实现二者的绑定和更新。

自己平时做的较多的是地图类应用，类似百度地图PC版和腾讯地图那种，考虑过用AngularJS，可是想来想去觉得不大合适,主要原因是地图类应用一般依赖第三方地图API，比如基于百度地图需要百度地图Javascript API，腾讯也有自己的JS API，这些API的普遍概念是提供一个页面元素，然后在这个元素里创建一个可交互的地图界面。

1 地图初始化

假如我们希望在页面p#map-p这个位置创建一个地图，通常代码如下：

<p id="map-p"></p>

var map=new BMap.Map("map-p",{});

这个map对象有包含了许多方法比如添加叠加物、地图绘制等，这些方法大多数又会引起地图界面的更新，比如下面的代码会在地图界面上弹出一个窗口：

map.addInfoWindow();

如果按照AngularJS的里面，我们应该在页面里声明一个地图的View,类似这样

这样的话，我们需要创建一个bd-map的directive，意味着需要针对不同的地图SDK建立不同的directive，虽然这个是一劳永逸的工作，算起来这个不算啥。

2 地图交互

这一块我觉得如果完全通过AngularJS封装会导致把简单问题复杂化，比如我从后台请求了10个酒店的数据markers，每个酒店有一个位置信息，一般情况下，我会这么干：

for(var i......){
  var item=...
  var marker=new BMap.Marker(...);
  map.addOverlay(marker);
}

但是按照AngularJS的理念，markers明显应该是某个scope里面的数据，我们的业务应该关注在这个数据的获取和更新上，界面的更新应该交由directive完成，于是我好像还需要创建marker对应的directive，到这一步我已经觉得有点复杂了，有一种多此一举的感觉。

3 事件

地图本身，以及地图上面的叠加物多少都有一些事件的，比如你点击了地图，点击了一个图标等等，这些在地图类应用里面很常见，如果使用AngularjS的话好像又要封装一下。

我的感觉是，地图类SDK本身已经可以看作是一个MVC的实现，比如你把地图的各种参数（数据）设置好，然后通过一句SDK提供的接口，一个地图界面（View）就创建了，通过修改地图中心点等接口，地图视图也跟着变化，这种情况下跟AngularJS强行结合好像会适得其反，这种情况我觉得还是Backbone更合适一点，毕竟Backbone的view还是比较灵活的，Model的渲染完全在自己手里，可以手工操作dom，也可以调用通过地图SDK完成，并没有耦合的很紧密，不需要额外的工作。

学AngularJS时间比较短，大概1周，有这种想法，不知道有没有哪里理解不到位的地方？

补充，我觉得AngularJS最适合的场景是应用只需要原生的页面元素的组合，比如不同的view只是将数据注入到不同的template的中，比如todolist，gmail这种，就是原生html元素的拼凑。

黄舟黄舟2753일 전795

모든 응답(5)나는 대답할 것이다

  • 大家讲道理

    大家讲道理2017-05-15 16:52:21

    일단 Angular를 일주일만 배운 후에는 이 부분에 대해 깊이 생각하기가 쉽지 않습니다. 처음에 저보다 훨씬 잘 사용하실 수 있을 거라 믿습니다.

    두 번째로, 안타깝게도 저는 지도 애플리케이션을 많이 접해본 적이 없습니다. 특히 SDK가 얼마나 복잡한지 이해하지 못하기 때문에 Angular로 전환하면 상황이 좋아질지 여부를 말하기가 어렵습니다.

    우선 다른 이야기로 넘어가겠습니다. 특히 웹앱의 경우 API와 SDK가 다르다고 생각합니다. API는 일반적으로 데이터 교환에 사용되며 일반적으로 DOM 객체를 포함하지 않습니다. SDK는 자체 캡슐화된 논리 세트를 가지며 일반적으로 DOM과 긴밀하게 결합된 인터페이스 호출을 제공합니다.

    API는 Angular에서 매우 잘 처리할 수 있으며 내장된 리소스는 특히 API 서비스를 캡슐화하는 데 적합합니다. 그러나 SDK 자체는 캡슐화 측면에서 비교적 완벽합니다. Angular 세계에서는 DOM을 직접 작동하지 않는다는 점을 강조하므로 SDK 통합이 더욱 복잡하고 어려워집니다. 이러한 현상은 실제로 존재하며 솔루션은 실제로 여러분이 생각하는 것과 유사합니다. 지시문을 사용하여 DOM 상호 작용을 추상화하고 서비스를 사용하여 논리 부분을 추상화합니다. 예를 들어, Highcharts와 같은 것을 생각해보면 - 비록 지도 SDK는 아니지만 비슷하고 복잡하고 잘 캡슐화된 타사 라이브러리입니다. - Angular와의 통합이 쉽지 않고 함정이 많기 때문에 많은 사람들이 재사용을 위해 Angular + Highcharts 모듈을 별도로 만들었습니다. 이 영역에서 예제를 검색하여 구현 방법을 확인하고 적합한지 추정할 수 있습니다.

    Angular의 캡슐화는 간단한 문제를 복잡하게 만드나요? 때로는 그렇습니다. 실제로는 문제 자체에 따라 다릅니다. Angular는 만병통치약이 아니며 모든 유형의 애플리케이션에 적합하지 않습니다. Backbone이 귀하의 현재 업무를 처리할 수 있다고 생각하십니까? 그런 다음 계속 사용하고 "추세"를 무시하십시오. 반면에 Angular가 Backbone과 일치하지 않는 부분이 있다는 것을 알게 되면 과감하게 Angular를 사용하기 시작하세요. 어쨌든, 해결해야 할 문제만 건드리면 완벽한 프레임워크는 없습니다. 만지지 않으면 걱정할 필요가 없습니다.

    추가로 이 논의를 확장하고 싶습니다.

    기술을 과거 기술(또는 성숙 기술), 현재 기술(또는 대중 기술), 미래 기술(또는 트렌드를 대표하는 기술)의 세 부분으로 크게 나누어 보겠습니다.

    "과거의 기술"을 "현재의 기술"로 대체하기로 충동적으로 결정하기 쉽습니다. 일반적으로 비용이 들지만 확실히 이점이 없을 수 없으며, 제대로 처리하면 항상 비용보다 이점이 더 큽니다. .

    문제는 '현재 기술'에는 항상 선택의 여지가 많다는 것입니다. 우리는 이 선택에 빠져 결정을 내리지 못하는 것이 더 쉽습니다. 과거의 기술은 적어도 안전합니다.

    지난 1년 동안 이 질문에 여러 번 답변을 드렸는데 무엇이 옳다고 말씀드릴 수가 없네요.

    나는 "미래 기술"을 학습하고 이해하여 "현재 기술"을 선택하고 "과거 기술"을 과감하게 대체하는 경향이 있습니다.

    "과거의 기술"은 언젠가는 시간 문제일 뿐입니다. 나는 비용이 많이 들더라도 "전진하지 않으면 퇴보하는" 유형입니다.

    '현재 기술'이 '미래 기술'과 일치하는지 여부는 실제로 기술 동향에 대한 작성자/팀의 이해 및 판단뿐만 아니라 귀하의 개인적인 이해 및 판단을 반영합니다. 자신감과 의사결정 능력은 본인에게 달려있습니다.

    내가 '미래기술'을 얘기한 이유는 무엇인가요? 당신이 만드는 지도 애플리케이션을 예로 들어보겠습니다. 현재 SDK를 얼마나 오랫동안 사용할 수 있다고 생각하시나요? 코드 자체뿐만 아니라 기술 스택도 SDK 기반 DOM 기반 지도 애플리케이션 개발 모델이 얼마나 오래 지속될 수 있습니까?

    이 질문에 대답하기 어렵다면 먼저 Google 지도와 같은 업계 리더의 개발 이력을 검토하고 두 번째로 업계 리더의 기술 아키텍처에 대해 알아볼 수 있습니다.

    우리는 WebComponents가 웹앱의 차세대 기술이 될 것이라는 것을 거의 모두 알고 있고 예상할 수 있습니다. 따라서 WebComponents가 "현재 기술"이 되면(아마도 그리 오래 걸리지는 않을 것입니다) 현재 세트는 SDK를 기반으로 하며 DOM을 지향적인 지도 응용 프로그램 개발 모델에는 발전과 생존의 여지가 얼마나 있습니까?

    나는 답을 모르고, 당신에게 어떤 "가치"를 심어주고 싶지도 않습니다. 나는 단지 내가 어떻게 생각하고 결정하는지 설명할 뿐입니다. 문제에 대한 귀하의 설명을 보면 귀하는 단순한 프로그래머가 아닐 수도 있으며 팀에서 "설계자" 역할도 수행할 수도 있으므로 이에 대해 더 자세히 설명하겠습니다. 즉, 광범위하게 생각하십시오. .

    회신하다
    0
  • phpcn_u1582

    phpcn_u15822017-05-15 16:52:21

    지도 부분은 각도와 아무 관련이 없다고 생각합니다. 지도를 각도 외부에 배치하거나 각도가 지도 부분을 컴파일하지 않도록 할 수 있습니다. 그러나 노멀 맵을 사용하는 것은 영향을 미치지 않습니다(결국 노멀 맵에 의해 캡슐화되었습니다). 이를 처리하기 위해 각도가 필요한 경우 각도가 이를 처리하도록 하십시오.

    Angular를 사용하더라도 페이지의 모든 요소가 Angular와 관련되어 있어야 하는 것은 아닙니다. 단지 Angular를 사용하기 위해 모든 것을 Angular와 연결하지 마십시오.

    회신하다
    0
  • 滿天的星座

    滿天的星座2017-05-15 16:52:21

    저는 한동안 Openlayers 개발을 해왔고, Angularjs에 대해서도 어느 정도 사전 지식을 갖고 있습니다

    이것은 서로 다른 두 분야에 속하는 프레임워크입니다
    Map API는 G 표시에 중점을 두고, AngularJS는 IS 표시에 중점을 둡니다. 예를 들어 둘 사이에는 충돌이 없습니다. 쿼리를 수행하면 서버는 일련의 요소 정보를 반환합니다. 이제 일반적인 접근 방식은 요소를 촉진하고 정보를 얻은 다음 템플릿을 통해 HTML을 결합하여 동시에 결과 목록을 표시하는 것입니다. 이러한 요소 정보를 레이어에 추가하여 지도에 그립니다.

    지도 API는 지리 요소 그리기를 완성하는 데 도움이 되지만 정보 데이터는 스스로 제어해야 합니다.

    마우스와 요소 상호 작용의 예를 시뮬레이션해 보겠습니다

    으아악

    //의사 코드(원본) 또는 기타 프런트엔드 템플릿

    으아악

    //AngularJS

    으아악

    물론 다른 js 템플릿을 사용해 MVC를 수행할 수도 있지만 AngularJS를 사용하면 단일 페이지 애플리케이션이라는 장점이 있고 중간 구현 과정은 모든 길은 로마로 이어진다는 점만 빼면요

    요구사항이 변경되었지만, 현재의 li 요소나 다른 새로운 요구사항을 강조할 수 있습니다. 이때 코드를 변경한 지점이 같은 위치에 있지 않다는 것을 알 수 있습니다.

    원래 방법에서는 이벤트 바인딩 프로세스 중에 스타일 전환을 추가해야 합니다

    //AngularJS

    으아악

    간단히 말하면 유지관리가 빨라지고 원래 업무에는 영향을 주지 않습니다.

    회신하다
    0
  • 仅有的幸福

    仅有的幸福2017-05-15 16:52:21

    실제로 map SDK는 이미 DOM 관리를 완료했습니다. 이 부분은 ng로 반복되기 때문에 ng를 부과하면 기분이 이상해질 것입니다. Map SDK 자체가 ng 모드로 제공된다면 색다른 개발 경험을 선사할 수도 있습니다.

    회신하다
    0
  • 漂亮男人

    漂亮男人2017-05-15 16:52:21

    처음에는 조금 어렵다고 생각했는데, 점차 Angular를 이해하면서 쉬워졌습니다.
    JS 프레임워크에 관계없이 객체는 참조로 전달된다는 점을 알아야 합니다.
    그런 다음 SDK의 경우 실제로 SDK 개체를 서비스에 연결하고 콜백에서 $apply에 주의하세요

    회신하다
    0
  • 취소회신하다