۱۰ دلیل که باید از AngularJS استفاده کنیم
۱۰ دلیل که باید از AngularJS استفاده کنیم

اگر تا کنون از Angular استفاده نکرده باشید، درک نمی کنید که چرا برنامه نویسان میگویند Javascript قابل انعطاف ترین زبان دنیاست.
بیشتر فریم ورک های امروزی فقط انباشته ای از ابزارهای موجود هستند. آنها مجموعه ابزاری یکپارچه هستند اما چندان چشمگیر نیستند.
Angular فریم ورک نسل بعدی است که در آن هر ابزاری طراحی شده تا با تمام ابزارهای دیگر به طرز به هم پیوسته ای در ارتباط باشد.
ما به ۱۰ دلیل زیر به شما پیشنهاد می دهیم که ازهمین امروز استفاده از Angular را شروع کنید:

۱۰ دلیل که باید از AngularJS استفاده کنیم

۱.MVC در آن به درستی انجام میشود

بیشتر فریم ورک ها برای اجرای MVC از شما میخواهند که برنامه تان را به کامپوننت های MVC تقسیم کنید، سپس از شما میخواهند که دوباره آنها را با کد نویسی به هم متصل کنید و این کار زیادی را می طلبد. Angular ازشما میخواهد تا برنامه تان را به کامپوننت های MVC تقسیم کنید، سپس خودAngular بقیه کارها را انجام می دهد. Angular کامپوننت های شمارا مدیریت کرده و به همچون خطوط لوله ، آنها را به هم وصل میکند.

۲. رابط کاربری اعلانی

Angular از HTML برای تعریف رابط کاربری برنامه استفاده می کند. HTML یک زبان بیانی است که از تعریف رابط کاربری به صورت رویه ای در Javascript راحت تر و قابل درک تر است. همچنین HTML نسبت به رابط کاربری نوشته شده توسط Javascript شکنندگی کمتری دارد، یعنی احتمال بهم ریختن اجزا کمتر است. به علاوه اگر رابط کاربری با HTML نوشته شده باشد میتوان توسعه دهندگان بسیار بیشتری را به کار گرفت.
HTML برای تعیین اجرای برنامه نیز استفاده میشود. صفات خاصی در HTML تعیین میکنند که برای هر المنت از کدام کنترلر استفاده کنیم. این صفات تعیین میکنند چه چیزی خوانده شود، اما به چگونه خوانده شدن آن کاری ندرند. این رویکرد اعلانی توسعه برنامه را به شیوه WYSIWYG (چیزی که میبینید چیزی است که دریافت می کنید) به طور چشمگیری ساده می کند.به جای اینکه وقتتان را صرف این کنید که روند برنامه چگونه است و چه چیزی باید اول بارگذاری شود، کافی است تعریف کنید که چه چیزی میخواهید و Angular بقیه کارها ر ا انجام میدهد.

۳. Data Modelها به صورت POJO هستن

Data Model های موجود در این فریم ورک اشیاء قدیمی جاواسکریپت (POJO) هستند، و توابع Getter و Setter فرعی نیاز ندارند. شما میتوانید خصوصیات را مستقیما به آن افزوده یا از آن تغییر دهید . ر.ی آرایه ها و Object ها به دلخواه loop کنید. کد شما بسیار تمیزتر و واقعی تر خواهد بود.
Data Model های سنتی محافظ و مسئول ماندگاری دیتا بوده وهمگام سازی سرور را به عهده دارند. این Data Modelها مانند ارائه دهنگان هوشمند داده عمل میکنند.اما چون Data Modelهای انگولار اشیاء ساده هستند، بیشتر شبیه Cork Board عمل میکنند. یک Cork Board چیزی بیشتر از یک فضای ذخیره موقت برای قرار دادن و دریافت کردن داده های افراد نیست. البته Cork Board های انگولار رابطه نزدیکی با Controller و View دارند. برای تمییز آنها از Data Model های قدیمی انگولار آنها را Scope مینامد.
تمام خوصیات یافت شده در شیء scope به صورت خودکار توسط انگولار به view متصل می شوند. به عبارت دیگر، انگولار بی سروصدا تغییرات ایجاد شده در این خصوصیات را بررسی کرده و به صورت خودکار view را آپدیت می کند.
Scope هیچ داده ای برای شروع کار ندارد و بر controllerها متکی است تا متناسب با نیاز های منطقی کار به آنها دیتا دهد.

۴- رفتار با دایرکتیو ها

انگولار از دایرکتیو ها برای افزودن کارایی های جدید به HTML استفاده می کند. دنیایی را تصور کنید که HTML دارای المنت های بسیار غنی مثل <accordion></accordion>, <grid></grid>, <lightbox></lightbox> که ما هرگز مجبور به تغییر DOM برای شبیه سازی آنها نیستیم باشد تنها کاری که اپلیکیشن ما باید انجام دهد نسبت دادن attribute ها به المنت ها می باشد تا هر کاری را امکان پذیر کند.
دایرکتیو ها با ایجاد امکان ابداع المنت های جدید HTML، این کار را برای ما انجام می دهند. با قرار دادن تمام کد های تغییر DOM در دایرکتیوها، می توانیم آنها را از اپلیکیشن MVC خود مجزا کنیم. این امر باعث می شود که اپلیکیشن MVC ما تنها بر روی آپدیت کردن view با داده های جدید تمرکز کند. نحوه ی رفتار متعاقب view به دایرکتیو ها بستگی دارد.
دستورات به شکل المنت های دستی HTML می آیند

۰۱ <myticker></myticker>

ویژگی های دستی

۰۱ <div data-myticker></div>

و نام کلاس های دستی

۰۱ <div class="myticker"></div>

که باعث می شود بتوانیم از آنها مانند المنت های معمولی HTML استفاده کنیم.
دایرکتیو های به صورت المنت های قابل استفاده ی مجدد طراحی شده اند که از اپلیکیشن شما مجزا هستند. در واقع، اگر یک المنت خاص توسط استاندارد HTML5 پذیرفته شود، باید دایرکتیو خود را حذف کرده و اپلیکیشن شما باید دقیقا مانند قبل عمل کند بدون اینکه نیازی به تغییر اپلیکیشن باشد.
به یاد داشته باشید که controller نباید مستقیما DOM را تغییر دهد. تمام تغییرات DOM باید توسط دایرکتیوها اجرا شود.

۵- انعطاف پذیری در کار با فیلتر ها

فیلتر ها داده را قبل از رسیدن به view فیلتر کرده و می توانند در کارهای ساده ای مانند فرمت کردن مکان های دسیمال برای یک عدد، حفظ ترتیب یک آرایه، فیلتر کردن یک آرایه بر اساس یک پارامتر یا اجرای عمل صفحه بندی شرکت کنند. فیلتر ها به صورت توابع مستقلی طراحی شده اند که مشابه با Directive ها از اپلیکیشن شما مجزا می باشد اما ارتباط آنها فقط با تغییر شکل داده می باشد.
فیلتر ها بسیار کارامد هستند و این امکان وجود دارد که یک جدول قابل طبقه بندی HTML را با استفاده از فیلتر ها و بدون نیاز به نوشتن هیچ گونه جاوا اسکریپت ایجاد کرد.

۶- نوشتن کد های کمتر

تمام نکاتی که تا اینجا گفته شد به این معنی بود که شما باید کد های کمتری بنویسید. نیازی نیست که شما خودتان ارتباطات MVC را بنویسید. View با استفاده از HTML تعریف می شود که خلاصه تر است. نوشتن Data model ها بدون getter/setter ساده تر می باشد. Data binding به این معنی است که نیازی نیست که شما به صورت manual داده ها را در view قرار دهید. به دلیل اینکه دایرکتیوها از کدهای اپلیکیشن جدا هستند، می توان آنها را با یک تیم دیگر و به صورت موازی نوشت و مشکلات مربوط به یکپارچگی نیز وجود نخواهد داشت. فیلتر ها به شما این امکان را می دهند که بدون تغییر controller ها، داده را در سطح view تغییر دهید.

۷- تغییرات DOM

View معمولا DOM را اصلاح می کند تا داده ها را نمایش دهد و DOM را تغییر می دهد (یا jQuery را فراخوانی می کند) تا رفتاری را به آن بیافزاید. در فریم ورک انگولار، کد تغییرات DOM باید در داخل دایرکتیو ها قرار گیرد نه داخل view. انگولار view را به عنوان یک صفحه ی HTML دیگر می بیند که دارای placeholder هایی برای داده می باشد. این روش نگاه کردن به view به خوبی با دیدگاه طراحان رابط کاربری (UI) منطبق می شود.
با abstract ساختن تغییرات DOM و فراخوانی های jQuery، طراحان رابط کاربری می توانند به راحتی بر view تمرکز کنند. اگر اپلیکیشن MVC شما برای ارائه ی داده های کاری در view ها طراحی شده باشد و نگرانی در مورد تغییر DOM وجود نداشته باشد، توسعه ی وب اپلیکیشن ها کاری مفرح خواهد بود.

۸- سرویس دهندگان

Controller ها در فریم ورک انگولار توابع ساده ای هستند که تنها یک کار دارند و آن هم تغییر scope می باشد. برای مثال، شما می توانید آن را برای قرار دادن داده از سرور به درون scope یا اجرای اعتبار سنجی منطقی کار به کار برید. بر خلاف سایر فریم ورک ها، در انگولار controller ها شیء نیستند و از چیزی به ارث نمی رسند.
اگر controller ها تا این حد ساده هستند، پس کارهای سنگین و پیچیده در کجا اجرا می شود؟ انگولار سرویس هایی را معرفی می کند (Services) که دقیقا این کار را انجام می دهند. سرویس ها دقیقا همان چیزی هستند که باید باشند. آنها در معماری MVC شما دخیل نیستند اما یک API بیرونی یا ظاهری برای نمایش هر آنچه که شما بخواهید نمایش یابد، ارائه می دهد. اکثر مواقع با سرور sync می شود تا یک data store آفلاین را حفظ کرده و متد ها را فراخوانی می کند تا داده ها را از سرور گرفته و به آن بفرستد. یا می توان از آن برای ایجاد یک سرویس اشتراک منابع استفاده کرد که این امکان را ایجاد می کند که controller های متعدد از منابع مشترک استفاده کنند.
سرویس ها (Services) به صورت اشیاء مستقلی طراحی می شوند که از اپلیکیشن مجزا هستند و به controller این امکان را می دهند که به view و scope که به آنها نسبت داده شده است، اختصاص یابد. البته پیاده سازی سرویس ها لازم نیست و این امر کاملا پذیرفته شده است که تغییرات کمی در داخل controller انجام شود تا از پیچیدگی های اضافی جلوگیری شود.

۹- ارتباطات متن-آگاه context-aware

سیستم PubSub یک ابزار کاملا رایج است که امکان ارتباطات نا همبسته را می دهد. پیاده سازی PubSub بر روی وب، متن-آگاه نیست. گاهی اوقات شما می خواهید که یک پیام PubSub تنها برای فرزندان یک گره خاص قابل خواندن باشد یا تنها توسط اجداد یک فرزند خاص قابل خواندن باشد. به عبارت دیگر، گاهی شما نمی خواهید کامپوننت های غیر مرتبط MVC بتوانند پیام شما را بخوانند.
سیستم PubSub در فریم ورک انگولار بسیار دقیق است و broadcast() یک پیام به تمام controller های فرزندان ارسال می کند، در حالی که emit() یک پیام به همه ی اجداد ارسال می کند.
اما PubSub تنها روش برای ارتباط بین controller ها نیست. در واقع اگر تمام کاری که انجام می دهید این است که به controller های دیگر بگویید که هنگامی که یک خصوصیت تغییر می کند، view های خود را آپدیت کنند، شما باید بر data binding تکیه کنید. میدانیم که view می تواند به خصوصیات موجود بر روی scope جاری متصل شود. اما آنچه که گفته نشده است این است که scope ها خصوصیات را از scope های والد خود به ارث می برند. به عبارت دیگر اگر یک خصوصیت بر روی scope والد وجود داشته باشد و scope فرزند آن را تغییر دهد، تمام scope هایی که از آن scope والد ارث بری داشته باشند آن تغییر را دیده و view های آن به صورت خودکار توسط انگولار آپدیت خواهند شد. این روش خودکار بر استفاده از PubSub غلبه می کند.

۱۰- آمادگیunit testing

کدام تعریف انگولار بدون صحبت از آمادگی unit testing آن کامل خواهد بود؟ تمامی قسمت های فریم ورک انگولار به طور کامل توسط (DI) Dependency Injection (تزریق وابستگی) به هم مرتبط می شود. فریم ورک انگولار از آن برای مدیریت controller ها و scope ها استفاده می کند. به دلیل این که تمام controller ها به DI وابسته هستند تا اطلاعات آن را منتقل کنند، unit test های انگولار می توانند DI را تسخیر کنند تا عمل unit testing را با استفاده از تزریق داده های کاذب به درون controller و سنجش خروجی و رفتار آن، انجام دهند. در واقع انگولار دارای یک HTML provider جعلی برای تزریق پاسخ های جعلی سرور به درون controller ها می باشد.
این روش بر سایر روش های قدیمی تست وب اپلیکیشن ها که از طریق ایجاد صفحات مجزا برای تست و سپس فراخوانی یک کامپوننت و پس از آن تعامل با آن برای مشاهده ی کارکرد صحیح آن انجام می شد، برتری دارد.
این ۱۰ دلیل می تواند به شما بگوید که چرا انگولار یک فریم ورک فوق العاده قدرتمند است. البته نباید تمام وب اپلیکیشن ها را با انگولار ایجاد کنیم. برای مثال اگر می خواهید یک بازی یا یک برنامه ی ریاضیاتی گسترده بنویسید، انگولار گزینه ی مناسبی نیس. اما برای وب اپلیکیشن های گرافیکی، می توان گفت که انگولار یک فریم ورک کارا و قابل اعتماد است.

منبع:mspsoft

 بازنشر: ایده ساز

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *