Pertama sekali, bukan mudah untuk dapat memikirkan perkara ini secara mendalam selepas hanya satu minggu mempelajari Angular pada mulanya. Saya percaya anda boleh menggunakan Angular dengan baik.

Kedua, malangnya, saya tidak banyak terdedah kepada aplikasi peta, terutamanya kerana saya tidak tahu betapa rumitnya SDK tersebut, jadi sukar bagi saya untuk mengatakan sama ada menukar kepada Angular akan menjadikan keadaan lebih baik.

Sebagai penyimpangan, saya rasa API dan SDK adalah berbeza, terutamanya untuk aplikasi web. API biasanya digunakan untuk pertukaran data dan secara amnya tidak melibatkan objek DOM adalah perkara yang anda maksudkan. Ia mempunyai set logik terkapsul mereka sendiri dan biasanya menyediakan panggilan antara muka yang digabungkan dengan DOM.

API boleh dikendalikan dengan baik oleh Angular, dan Sumber terbina dalam amat sesuai untuk merangkum perkhidmatan API. Walau bagaimanapun, SDK itu sendiri agak lengkap dalam enkapsulasinya Dalam dunia Sudut, penekanan untuk tidak mengendalikan DOM secara langsung menjadikan penyepaduan SDK lebih rumit dan sukar. Fenomena ini memang wujud, dan penyelesaiannya memang serupa dengan apa yang anda fikirkan Gunakan arahan untuk mengabstrakkan interaksi DOM, dan menggunakan perkhidmatan untuk mengabstrak bahagian logik. Sebagai contoh, jika anda memikirkan sesuatu seperti Highcharts - walaupun ia bukan SDK peta, ia adalah perpustakaan pihak ketiga yang kompleks dan terkapsul dengan baik - penyepaduannya dengan Angular tidak mudah, dan terdapat banyak perangkap, jadi terdapat ramai Orang telah membuat modul Angular+Highcharts secara berasingan untuk digunakan semula Anda boleh mencari contoh di kawasan ini untuk melihat bagaimana pelaksanaannya, dan anda mungkin boleh menganggarkan sama ada ia sesuai.

Adakah pengkapsulan Angular merumitkan masalah mudah? Kadang-kadang ya. Ia benar-benar bergantung pada masalah itu sendiri, Angular bukan ubat penawar, ia tidak sesuai untuk semua jenis aplikasi. Adakah anda fikir Backbone boleh mengendalikan kerja semasa anda? Kemudian teruskan menggunakannya dan abaikan "trend". Sebaliknya, apabila anda benar-benar mendapati bahawa Angular mempunyai bahagian yang Backbone tidak dapat dipadankan, maka dengan tegas mula menggunakan Angular Bagaimanapun, tiada rangka kerja yang sempurna Selagi anda menyentuh masalah yang perlu diselesaikan, anda perlu menyelesaikannya mereka. Jika anda tidak menyentuhnya, anda tidak perlu risau.

Selain itu, saya ingin memanjangkan perbincangan ini.

Mari kita bahagikan secara kasar teknologi kepada tiga bahagian: teknologi masa lalu (atau teknologi matang), teknologi semasa (atau teknologi popular) dan teknologi masa depan (atau teknologi yang mewakili arah aliran) .

Adalah mudah untuk kita membuat keputusan secara impulsif untuk menggunakan "teknologi semasa" untuk menggantikan "teknologi lepas" Secara umumnya, akan ada kos, tetapi ia pastinya tidak akan ada faedah, dan jika dikendalikan dengan betul, faedahnya akan sentiasa. mengatasi kos.

Masalahnya ialah sentiasa ada banyak pilihan dalam "teknologi semasa". Lebih mudah untuk kita jatuh ke dalam pilihan ini dan tidak dapat membuat keputusan kepada teknologi masa lalu, sekurang-kurangnya ia selamat.

Saya tidak boleh mengatakan apa yang betul Saya telah menjawab soalan ini berkali-kali pada tahun lalu dan saya hanya boleh menyatakan pertimbangan saya sendiri.

Saya cenderung memilih "teknologi semasa" dengan mempelajari dan memahami "teknologi masa depan" dan dengan tegas menggantikan "teknologi lepas".

"Teknologi masa lalu" akan sentiasa berlalu, lambat laun hanya tinggal masa saya adalah jenis orang yang "berlayar melawan arus, jika saya tidak maju, saya akan berundur", walaupun kosnya. adalah tinggi.

Sama ada "teknologi semasa" konsisten dengan "teknologi masa hadapan" sebenarnya mencerminkan pemahaman dan pertimbangan pengarang/pasukan tentang aliran teknologi, serta pemahaman dan pertimbangan peribadi anda, adakah terdapat sedikit perjudian? Keyakinan dan keupayaan membuat keputusan ini bergantung kepada diri sendiri.

Mengapa saya bercakap tentang "teknologi masa depan"? Ambil aplikasi peta yang anda buat sebagai contoh Berapa lama pada pendapat anda SDK semasa boleh digunakan? Bukan sahaja kod mereka sendiri, tetapi tindanan teknologi mereka Berapa lama model pembangunan aplikasi peta berorientasikan DOM berasaskan SDK boleh bertahan?

Jika anda mendapati soalan ini sukar untuk dijawab, mula-mula anda boleh menyemak sejarah pembangunan pemimpin industri, seperti Peta Google, kedua, anda boleh belajar tentang seni bina teknikal pemimpin dalam industri.

Kita hampir semua tahu dan boleh menjangkakan bahawa WebComponents akan menjadi perkara besar seterusnya dalam aplikasi web Jadi, apabila WebComponents menjadi "teknologi semasa" (mungkin ia tidak akan lama), set semasa adalah berdasarkan SDK dan Berapa banyak. ruang untuk kemajuan dan kelangsungan hidup adakah model pembangunan aplikasi peta berorientasikan DOM ada?

Saya tidak tahu jawapannya, dan saya tidak mahu menanam sebarang "nilai" dalam diri anda, saya hanya menerangkan cara saya berfikir dan membuat keputusan. Daripada penerangan anda tentang masalah itu, saya merasakan bahawa anda bukan hanya seorang pengaturcara Mungkin anda juga memainkan peranan "arkitek" dalam pasukan anda, jadi saya akan mengatakan lebih lanjut tentang ini .

Saya rasa bahagian peta tidak ada kaitan dengan sudut Anda boleh meletakkan peta di luar sudut atau biarkan sudut tidak menyusun bahagian peta. Tetapi ia tidak menjejaskan anda untuk menggunakan peta biasa (lagipun, ia telah dikapsulkan oleh mereka apabila anda memerlukan sudut untuk mengendalikannya, biarkan sudut mengendalikannya).

Walaupun anda menggunakan sudut, tidak semua elemen pada halaman mesti berkaitan dengan sudut. Hanya gunakannya di tempat yang sesuai. Jangan kaitkan semuanya dengan Angular hanya untuk menggunakan Angular.

Saya telah melakukan pembangunan Openlayers untuk satu tempoh masa sebelum ini dan mempunyai beberapa pemahaman awal tentang Angularjs

Ini adalah rangka kerja yang dimiliki oleh dua medan berbeza
API Peta memfokuskan pada paparan G, dan AngularJS memfokuskan pada paparan IS Tiada konflik antara kedua-duanya Apabila kami membuat pertanyaan, pelayan mengembalikan satu siri maklumat elemen Sekarang pendekatan umum adalah untuk memudahkan elemen, mendapatkan maklumat, dan kemudian menggabungkan HTML melalui templat untuk memaparkan senarai keputusan Pada masa yang sama, tambah maklumat elemen ini ke lapisan dan lukis Pergi ke peta.

API peta membantu kami melengkapkan lukisan elemen geografi, tetapi data maklumat perlu dikawal oleh kami sendiri Mari kita meniru contoh interaksi tetikus dan elemen

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);
})

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

<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>

Sememangnya, SDK peta telah pun menyelesaikan pengurusan DOM untuk anda Bahagian kerja ini diulang dengan ng, jadi ia akan berasa pelik untuk mengenakan ng padanya. Jika SDK peta itu sendiri disediakan dalam mod ng, ia mungkin membawa pengalaman pembangunan yang berbeza.

Saya fikir ia agak menyusahkan pada mulanya, tetapi apabila saya secara beransur-ansur memahami Angular, ia menjadi lebih mudah.
Anda mesti tahu bahawa tidak kira apa rangka kerja JS, objek adalah rujukan yang diluluskan.
Kemudian untuk SDK, sebenarnya ikat objek SDK pada perkhidmatan. Hanya perhatikan $apply dalam panggilan balik