قدیمیترین برنامه Hello World ویندوز
امکان ساخت قالب برای پروژههای NET Core.
Blazor WebAssembly 6x به همراه قابلیتی است به نام ahead-of-time (AOT) compilation که در این حالت، کدهای دات نتی برنامه، مستقیما به native WebAssembly کامپایل میشوند. این مورد سبب بالا رفتن کارآیی برنامه خواهد شد؛ در عوض بالا رفتن حجم نهایی قابل توزیع.
اگر از AOT compilation استفاده نشود (یعنی حالت متداول)، Blazor WebAssembly در مرورگر، به کمک مفسر IL یا همان NET Intermediate Language. که به صورت WebAssembly تهیه شدهاست، اجرا خواهد شد. یک چنین حالتی به دلیل استفادهی از مفسر، نسبت به حالت استفادهی از JIT سمت سرور (یا همان NET just-in-time (JIT) runtime.)، اندکی کندتر است. AOT compilation جهت رفع یک چنین کمبودی ارائه شدهاست تا کدهای دات نتی را مستقیما و بدون نیاز به مفسر، تبدیل به یک native WebAssembly کند. این مورد سرعت و کارآیی برنامههایی را که کارهای محاسباتی مبتنی بر CPU را انجام میدهند، به نحو قابل ملاحظهای افزایش میدهد. در مقابل باید درنظر داشت که حجم نهایی WebAssemblyهای واقعی تولید شده، از نمونهی IL آنها بالاتر است (حدود 2 برابر) که مدت زمان ابتدایی دریافت برنامه را افزایش میدهند.
روش فعالسازی کامپایل AOT
ابتدا نیاز است work load آنرا توسط دستور زیر دریافت کرد (ابزارهای کامپایل AOT، جزئی از SDK نیستند):
dotnet workload install wasm-tools
<PropertyGroup> <RunAOTCompilation>true</RunAOTCompilation> </PropertyGroup>
یک نکته: هنوز در نگارش 6.0 RTM، یکسری از قابلیتهای AOT اضافه نشدهاند که باید منتظر سرویسپکهای آن بود. برای مثال اگر این کامپایل، بر روی پروژهای که فقط سورس کد است اجرا شود، با موفقیت به پایان میرسد؛ اما با اضافه شدن کتابخانههای ثالث ممکن است با شکست مواجه شود. اگر در این حالت خطایی را دریافت کردید، عملیات publish را به صورت dotnet publish -p:RunAOTCompilation=true -bl انجام دهید. سوئیچ bl- سبب میشود تا فایلی به نام msbuild.binlog در ریشهی پروژهی شما تولید شود. این فایل در حقیقت لاگ باینری MSBuild است که توسط برنامهی Viewer آن قابل مشاهدهاست. در اینجا به دنبال exit codeها بگردید؛ یک نمونهی آن.
من تا به حال برنامه نویسهای زیادی را دیدهام که میپرسند «چه تفاوتی بین الگوهای معماری MVC و Three-Tier وجود دارد؟» قصد من روشن کردن این سردرگمی، بوسیله مقایسه هردو، با کنار هم قرار دادن آنها میباشد. حداقل در این بخش، من اعتقاد دارم، منبع بیشتر این سردرگمیها در این است که هر دوی آنها، دارای سه لایه متمایز و گره، در دیاگرام مربوطهاشان هستند.
اگر شما به دقت به دیاگرام آنها نگاه کنید، پیوستگی را خواهید دید. بین گرهها و راه اندازی آنها، کمی تفاوت است.
معماری سه لایه
سیستمهای سه لایه، واقعاً لایهها را میسازند: لایه UI به
لایه Business logic دسترسی دارد و لایه Business logic به
لایه Data دسترسی دارد. اما لایه UI دسترسی مستقیمی
به لایه Data ندارد و باید از طریق لایه Business logic و روابط آنها
عمل کند. بنابراین میتوانید فکر کنید که هر لایه، بعنوان یک جزء،
آزاد است؛ همراه با قوانین محکم طراحی دسترسی بین لایه ها.
MVC
در مقابل، اینPattern ، لایههای سیستم را نگهداری نمیکند. کنترلر به
مدل و View (برای انتخاب یا ارسال مقادیر) دسترسی
دارد. View نیز دسترسی دارد به مدل . دقیقاً چطور کار میکند؟
کنترلر در نهایت نقطه تصمیم گیری منطقی است. چه نوع منطقی؟ نوعاً، کنترلر، ساخت و تغییر مدل را در اکشنهای مربوطه، کنترل
خواهد کرد. کنترلر سپس تصمیم گیری میکند که برای
منطق داخلیش، کدام View مناسب
است. در آن نقطه، کنترلر مدل را به View ارسال میکند. من در اینجا چون هدف بحث مورد دیگهای میباشد،
مختصر توضیح دادم.
چه موقع و چه طراحی را انتخاب کنم؟
اول از همه، هر دو طراحی قطعاً و متقابلاً منحصر بفرد
نیستند. در واقع طبق تجربهی من، هر دو آنها کاملاً هماهنگ هستند. اغلب ما از معماری چند
لایه استفاده میکنیم مانند معماری سه لایه، برای یک ساختار معماری کلی. سپس من در
داخل لایه UI، از MVC استفاده میکنم، که در زیر دیاگرام آن را آورده
ام.
برای افزودن یک ماژول به پروژه از طریق گریدل، به صورت زیر اقدام میکنیم:
هر ماژول شامل یک فایل به نام build.gradle است که تنظیمات سطح آن ماژول را به عهده دارد و پروژه نیز یک build.gradle دارد که تنظیمات آن در سطح پروژه صورت میگیرد. برای اقزودن سورس در سطح یک ماژول لازم است که تعدادی خط کد را که معرف و آدرس آن سورس را دارد، به فایل build.gradle اضافه کنیم. به عنوان مثال برای سورس Active Android را که یک ORM عالی در سطح اندروید به شمار میآید، به ماژولمان اضافه میکنیم:
dependencies { compile 'com.michaelpardo:activeandroid:3.1.0-SNAPSHOT' }
سوال : اندروید استودیو، کتابخانههای اندرویدی را از کجا دانلود میکند؟
Apache Maven یک سیستم آزاد است که برای توزیع کتابخانهها مورد استفاده قرار میگیرد. سرورهای این سیستم شامل یک مخزن maven هستند که کتابخانهها در آن قرار میگیرند و شناسهی دسترسی به آن کتابخانه از طریق همان شناسهای است که شما در build.gradle تعریف میکنید. به طور عادی دو سرور استاندارد برای اینکار وجود دارند که یکی از آنها jcenter و دیگری mavenCnteral است. البته سرورهای دیگری نیز وجود دارند، یا اینکه حتی خودتان هم میتوانید میزبانی را به عهده بگیرید و یا بعضی از شرکتها برای خود مخزنی جداگانه دارند.
JCenter
این سرور که یک مخزن maven است، توسط Bintray میزبانی میشود که میتوانید آن را در این آدرس بیابید. برای اینکه شناسههای gradle مربوط به این سرور در اندروید استودیو دانلود شود، نیاز است خط زیر را به build.gradle سطح پروژه اضافه کنید:
allprojects { repositories { jcenter() } }
MavenCentral
این مخزن توسط Sonatype.org میزبانی میشود که کل مخزن آن را میتوانید در این آدرس بیابید. برای دسترسی به مخازن این سرور نیاز است خطوط زیر را به gradle سطح پروژه اضافه کنید:
allprojects { repositories { mavenCentral() } }
به عنوان مثال Twitter's Fabric.io خودش کتابخانهی خودش را میزبانی میکند و مخزن آن در این آدرس https://maven.fabric.io/public قرار گرفته است و برای افزودن این کتابخانه به پروژه نیاز است مسیر زیر طی شود:
//project build.gradle repositories { maven { url 'https://maven.fabric.io/public' } } //module build.gradle dependencies { compile 'com.crashlytics.sdk.android:crashlytics:2.2.4@aar' }
سوال : کدامیک از مخازن بالا را انتخاب کنیم؟
دلایل مهاجرت از mavencentral به jcenter:
- سیستم jcenter از طریق یک CDN عمل میکند که در این صورت میتواند تجربهی خوبی از سرعت بهتر را برای توسعه دهندگان به همراه داشته باشد.
- کتابخانههای jcenter بسیار بیشتر از mavencentral هستند؛ تا جایی که میتوان گفت اکثر کتابخانههایی که روی mavencenteral پیدا میشوند، روی jcenter هم هست و jcenter بزرگترین مخزن به شمار میآید.
- آپلود کتابخانه بر روی jcenter بسیار راحتتر است و نیاز به کار پیچیدهای ندارد.
بررسی قسمتهای یک شناسه Gradle
هر شناسه شامل سه قسمت میشود:
GROUP_ID:ARTIFACT_ID:VERSION
کتابخانههای زیر، از یک خانواده هستند که به راحتی میتوانید آنها را از هم تشخیص دهید:
dependencies { compile 'com.squareup:otto:1.3.7' compile 'com.squareup.picasso:picasso:2.5.2' compile 'com.squareup.okhttp:okhttp:2.4.0' compile 'com.squareup.retrofit:retrofit:1.9.0' }
شناخت فایلهای AAR
همانطور که میدانید فرمت فایلهای بایت کدی جاوا JAR میباشد که هم توسط جاوا و هم اندروید پشتیبانی میشود. ولی در صورتیکه کلاس شما یک پروژهی اندرویدی باشد، نمیتوانید آن را در قالب یک فایل JAR منتشر کنید. چرا که که کلاس اندرویدی میتواند شامل فایل مانیفست، منابع و ... باشد که در فایل JAR جایی برای آنها مهیا نشده است. به همین علت فایلهای نوع AAR برای اینکار مهیا شدهاند که این فایل در واقع یک فایل زیپ است که محتویات مورد نظر داخل آن قرار گرفته است و یکی از آن فایل Classes.jar برای کدهاست و مابقی آن به شرح زیر است:
- /AndroidManifest.xml (الزامی) - /classes.jar (الزامی ) - /res/ (الزامی ) - /R.txt (الزامی ) - /assets/ (اختیاری) - /libs/*.jar (اختیاری ) - /jni/<abi>/*.so (اختیاری ) - /proguard.txt (اختیاری ) - /lint.jar (اختیاری )
در مقالهی بعدی کار را با jcenter آغاز میکنیم.