首先，学 Angular 只有一周就能想到这么深已经是很不容易了，比我当初强太多，我相信你能把 Angular 用的很好。

其次，很遗憾我没有怎么接触过地图类应用，特别是不了解那些 SDK 究竟复杂到什么程度，所以我很难说换用 Angular 是否能让事情变得更好。

先说句题外话，我觉得 API 和 SDK 是不同的，特别是对 webapp 来说。API 通常是用于数据交换的，一般不会涉及到 DOM 对象；而 SDK 才是你说的那种，它们本身就有一套封装好的逻辑，并且通常都提供了和 DOM 紧密耦合的接口调用。

API 对于 Angular 来说可以处理得很好，自带的 Resource 特别适合用于封装 API 服务。但是 SDK 的话其本身的封装就比较完备了，在 Angular 的世界里由于强调不直接操作 DOM 反而使得 SDK 的融入会变得复杂和困难一些。这个现象的确是存在的，解决之道也的确和你想的差不多，利用 directive 抽象 DOM 交互，利用 service 抽象逻辑部分。比如说想 Highcharts 这样的东东——虽然不是地图 SDK，但也是类似的较复杂且封装完备的第三方库——它与 Angular 的整合就相当不容易，坑也不少，所以才会有很多人单独做了 Angular＋Highcharts 的模块用于重用，你可以搜搜这方面的例子看看其实现大概能估量出是否合适了。

Angular 的封装是否会让简单问题复杂化？有时候是的。这其实取决于问题本身，Angular 也不是万能药，它并非适合所有类型的应用。你觉得 Backbone 完全能 handle 你现在的工作？那就继续用，不用理会“潮流”。反之等你确实发现 Angular 有 Backbone 无法媲美的部分，那就果断用 Angular 上手，反正没有一个框架是完美的，该解决的问题只要你碰了就还得解决，不碰就没有必要操心。

另外我想延伸一下这个探讨。

让我们把技术粗略的分为三个部分：过去的技术（或者说成熟的技术），眼下的技术（或者说流行的技术），以及未来的技术（或者说代表着趋势的技术）。

我们很容易冲动的决定用“眼下的技术”来替代“过去的技术”，大体上来说会有代价，但也绝对不会没有好处，并且处理得当的话，好处总是胜于代价的。

问题是“眼下的技术”总有很多选择，我们会比较容易陷入这种选择中无法决断，甚至会觉得退回到过去的技术似乎也没有什么大不了的，至少很安全。

我没法说怎样是对的，最近一年回答了很多次这样的问题，自己都有些疲倦了，我只能说说自己的判断。

我倾向于通过学习和了解“未来的技术”来选择“眼下的技术”，并坚决取代“过去的技术”。

“过去的技术”总会过去，迟与早不过是一个时间问题，我是那种“逆水行舟，不进则退”的类型，即使代价会大也在所不惜。

“眼下的技术”是否与“未来的技术”合拍其实反映了作者／团队对于技术趋势的理解和判断，也反映了你个人的理解和判断，这里面会带一点赌博的成分，有没有这份自信和决断能力就得看自己了。

我为什么谈到“未来的技术”呢？就拿你做的地图类应用来说吧，你觉得像现在的这些 SDK 还能用多久？不单单指它们的代码本身，而是它们的技术栈，基于 SDK 以 DOM 为导向的地图类应用开发模式还能持续多久？

如果你觉得这个问题很难回答，那么第一可以回顾一下业界领头羊们的发展历史，比如 Google Maps；再一个去了解一下同行中领先者的技术架构。

我们差不多都知道并可以预期 WebComponents 将会是 webapp 的下一个 big thing，那么，当 WebComponents 变成“眼下的技术”的时候（说不定用不了多久），现在的这一套基于 SDK 以 DOM 为导向的地图类应用开发模式还有多少进步空间和生存空间？

我不知道答案，也不想灌输给你什么“价值观”，我只是描述一下我会如何思考并如何决断。通过你对问题的描述我感觉你并非只是一个程序员，说不定你在你的团队里也扮演者“架构师”一类的角色，所以我才多说这些，总的意思就是四个字：高瞻远瞩。

感觉map部分不一定要和angular扯上什么关系，可以把地图放在angular之外或者让angular不去编译map部分。但是不影响你去使用正常的map（毕竟已经被他们封装好了），在需要angular做处理的时候，再交由angular去处理。

虽然你用了angular，但是不一定页面上所有元素都要和angular相关，把它用在它擅长的地方的就可以了。不要为了用angular而去把所有东西都和angular挂钩。

本人之前做过一段时间的Openlayers开发,对Angularjs也有一些初步的认识

这属于两个不同领域的框架
地图API专注于G的展现,AngularJS专注于IS的展现,两者并不冲突.举个例子
当我们做查询时,服务端返回一系列的要素信息,现在一般的做法都是便利要素,获取信息,然后通过模板拼凑出HTML,显示结果列表,同时,将这些要素信息添加到图层,绘制到地图上.

地图API帮我们完成了地理要素的绘制,但是信息数据是需要我们自己来控制的.

让我们来模拟一段鼠标和要素交互的例子

function highlight(feature){
    map.control.select(feature)
}

//伪代码(原始),或者其他前端模板

var i=0,l=arrs.length,str=[],$case,map;
for(;i<l;i++){
    str.push("<li>"+arrs[i].name+"</li>")
}
$case.on("mouseenter","li",function(){
    var index=$(this).index();
    var feature=arrs[index];
    highlight(feature);
})

//AngularJS

<li ng-repeat="item in arrs" ng-mouseenter="highlight(item)">{{item.name}}</li>

当然,原始采用其他的js模板也可进行MVC,但是使用AngularJS的好处在于单页面应用,中间实现过程都只是条条大道通罗马而已.

但是,需求改变了,我们在高亮要素的同时,能够高亮当前的li元素,或者其他的新需求,这时候就会发现,我们改动代码的点不在一个位置

原始方法需要在事件绑定的过程里增加样式的切换

//AngularJS

<li ng-repeat="item in arrs" 
    ng-mouseenter="highlight(item);item.active=true"
    ng-mouseleave="item.active=false"
    ng-class="{'highlight':item.active}"
    >{{item.name}}</li>

简单来讲,维护变的更快速,原有业务不受影响.

的确，地图SDK已经帮你完成了DOM的管理，这部分的工作和ng的重复了，所以再强加ng上去就会感觉怪怪的。如果地图SDK的提供本身就是ng方式的那可能就会带来不一样的开发体验了。

刚开始觉得是有点麻烦，不过逐渐理解angular就觉得比较顺手了。
要知道不管什么JS框架，对象都是传递的引用。
然后对于SDK，其实把SDK的对象绑到一个service上，注意在回调里$apply一下就好了