تا حدود 4 سال پیش بین کیفیت oracle db و sql server اختلاف فاحشی وجود داشت. چه از نظر سرعت و چه از نظر دیگر امکانات، اوراکل کاملا برتر از رقیب خود بود. در نسخهی sql server 2012، امکانات قابل توجهی به محصول شرکت مایکروسافت افزوده شد. از مهمترین این امکانات میتوان به ویژگی AlwaysOn و ColumnStore Indexها اشاره کرد. امکانات این نسخه باعث شد که اختلاف بین oracle db و sql server تا حدی کاهش یابد. مایکروسافت سرانجام در نسخهی sql server 2014 خود تغییرات اساسی بوجود آورد. مهمترین این تغییرات ایجاد موتور درونی In-Memory OLTP میباشد که برای تراکنشهای درون حافظه بهینه شده است. با استفاده از امکانات این نسخه میتوان بدون نیاز به دوباره نویسی محصولات، سرعت اجرای کوئریهای آنها را به طور متوسط ده برابر کرد. در شکل ذیل ساختار جدید sql server مشاهده میشود.
شرکت بوین که یک شرکت مشهور ارائه خدمات آنلاین و پیش بینی بازیهای ورزشی است و در هر لحظه، کاربران آنلاین بسیاری در وب سایت شرکت، کوئری اجرا میکنند، از قابلیتهای جدید اس کیو ال سرور 2014 استفاده کرده است و با استفاده از این قابلیتها توانسته سرعت اجرای پرس و جوهای مشتریانش را از 15 هزار پرس و جو در ثانیه به 250 هزار پرس و جو در ثانیه برساند. در نتیجه کارایی سرور این شرکت 16 برابر شده است.
در تحقیقی دیگر، یک محقق، با استفاده از قابلیتهای جدید اس کیو ال سرور 2014 توانسته است دو رکورد جدید را از اجرای کوئریهای انبار داده ای برای حجمهای 3 ترابایت و 10 ترابایت و نوع پارتیشن بندی نشده به ثبت برساند و رکوردهای قبلی را که متعلق به اوراکل بوده، بشکند. این محقق توانسته 404005 کوئری نسبتا سنگین انبار دادهای را در پایگاه دادهای با 10 ترابایت اطلاعات، در یک ساعت اجرا کند و رکورد قبلی را که متعلق به اوراکل و برابر 377594 کوئری با همین شرایط بوده، بشکند. همچنین هزینهی اجرای کوئریهای سرور اس کیو ال مذکور برابر 2.04 دلار در هر ساعت اجرای کوئری بوده است. به این معنی است که کمتر از نصف هزینهی مشابه در رکورد ثبت شدهی اوراکل که برابر 4.65 دلار در ساعت اجرای کوئری بوده است، هزینه داشته است.
در واقع اگر بخواهیم سیستمهای مدیریت پایگاه داده عملیاتی را رتبه بندی کنیم، به جز سرعت، باید عوامل مختلفی را در نظر بگیریم که چنین کاری نیاز به همکاری گروهی بزرگ دارد. خوشبختانه چنین گروههایی وجود دارند و آن قدر معتبر هستند که اکثر شرکتهای بزرگ به آمارهای آنها استناد میکنند. در فناوریهای مربوط به آی تی، برای رسیدن به معتبرترین نتایج باید به گزارشهای ارائه شدهی شرکت گارتنر رجوع کنیم. گارتنر، شرکت پژوهشی و مشاورهی آمریکایی است، که در زمینهی ارائه خدمات برونسپاری، تحقیق و پژوهش و مشاوره فناوری اطلاعات فعالیت مینماید. این شرکت در سال 1979 راهاندازی شد و در سال 2014 بیش از 6500 نفر کارمند داشته که در 85 کشور بودهاند. در این بین حدود 1500 نفر از آنها در بخش تحقیق و توسعه فعالیت داشتهاند. همچنین در این سال، درآمد شرکت گارتنر که عمدتا از طریق مشاوره دادن به شرکتهای مختلف بوده، بیش از 2 میلیارد دلار در سال 2014 بوده است.
شرکت گارتنر معمولا خلاصهی نتیجهی بررسیهای خود را در نمودارهایی خاص به نام مربع جادویی گارتنر ارائه میکند. در این نمودار، قابلیتهای اجرایی که بیانگر کیفیت فعلی محصول هستند، در محور عمودی نمایش داده میشوند و از پایین به بالا زیاد میشوند. یعنی هر چه محصولی بالاتر باشد، در حال حاضر کیفیت بهتری دارد. محور افقی نمودار بیانگر بصیرت و آینده نگری محصول میباشد و از چپ به راست زیاد میشود. به این ترتیب رهبران یک حوزهی خاص، در ربع بالا و سمت راست مربع جای میگیرند.
حال که با نحوهی تفسیر مربع جادویی گارتنر آشنا شدیم، به بررسی نمودارهای مربوط به سیستمهای مدیریت پایگاه داده عملیاتی در سه سال اخیر میپردازیم.
در شکل ذیل میبینیم که در سال 2013 و پس از ارائهی نسخهی sql server 2012 توسط مایکروسافت، اوراکل همچنان پیشتاز است و شرکتهای مایکروسافت، آی بی ام و SAP پس از آن قرار گرفتهاند. البته در این سال شرکت مایکروسافت فاصلهی زیاد قبلی خود را با اوراکل، کم کرده است.
در سال 2014، شرکت مایکروسافت از نظر آینده نگری و بصیرت، از اوراکل پیشی گرفته ولی هنوز در قابلیتهای اجرایی عقبتر از اوراکل قرار دارد.
اما چند روز پیش در تاریخ 12 اکتبر 2015، شرکت گارتنر گزارشی ارائه کرد که خیلی از فعالان آی تی را شگفت زده کرد. این گزارش در حال حاضر در وب سایت شرکت گارتنر قابل دسترسی است؛ ولی معمولا گارتنر پس از مدتی آن را از حالت رایگان به پولی تغییر میدهد.
لینک موقت گزارش
در گزارش سال 2015 و پس از ارائهی نسخهی sql server 2014 و کاربردی شدن و تست قابلیتهای آن در عمل توسط شرکتهای مختلف، بالاخره طلسم چند ده سالهی اوراکل شکسته شده و اگرچه اوراکل نسبت به سال قبل رشد داشته است، ولی sql server مایکروسافت توانسته، هم در قابلیت اجرای فعلی و هم در بصیرت و آینده نگری بالاتر از محصول شرکت اوراکل بایستد. بنابراین عملا دوران پادشاهی مطلق اوراکل در حوزهی پایگاههای دادهی عملیاتی به سر رسیده است.
در انتها لازم میبینم به نکاتی مهم اشاره کنم:
- شرکت اوراکل بر خلاف تصور خیلی از افراد، همانند شرکتهای مایکروسافت، آی بی ام و ... محصولات گسترده و مختلفی دارد و این بررسی و نتایج تنها در حوزهی سیستمهای مدیریت پایگاه داده عملیاتی بود.
- بالاتر بودن sql server مایکروسافت از اوراکل در سال 2015 به این معنا نیست که اوراکل نمیتواند به جایگاه قبلی خود برگردد؛ بلکه شاید در سالهای آینده این رتبه بندی باز هم تغییر کند. در واقع این گزارش به این معنا است که فاصلهی زیاد قدیم بین sql server و oracle db از بین رفته و در حال حاضر این دو به رقیب سر سختی برای یکدیگر تبدیل شدهاند.
- وجود رقابت نزدیک بین شرکتهای بزرگ باعث میشود که این شرکتها حداکثر تلاش خود را برای بهتر کردن محصولات خود انجام بدهند و برندگان اصلی این وضعیت، استفاده کنندگان از این محصولات هستند.
- بنده به عنوان نگارندهی این پست شخصا با هر دو محصول oracle db و sql server کار میکنم و تلاش کردم که این پست بی طرفانه باشد؛ پس لطفا متعصبانه قضاوت نکنید.
سرعت واکشی اطلاعات در List و Dictionary
اول اینکه، کیفیت دادههای ذخیرهشده در دستگاههای تلفن همراه کاربر بیشتر شخصی میشود تا مواردی دیگر! به غیر از ایمیل، پیامهای فوری، SMS / MMS ، لاگ تماسها، عکسها و پست صوتی وجود دارند که عموما توسعه دهندگان را دچار مشکل میکند.
برخی از گزینههای فوق بر روی یک کامپیوتر رومیزی هم وجود دارند، ولی اهمیت این دادهها بر روی اندروید و اجزای آن اهمیت فوق العادهای دارد. اطلاعات روی دستگاه موبایل شما به احتمال زیاد از ارزش بیشتری برخوردار خواهد بود، چرا که آنها را در یک صفحه 4 - 5 اینچی به همراه خود حمل میکنید و با خود هر کجا میبرید! این حالت، یک پلتفرم همگرا را بوجود میآورد؛ به این دلیل که سیستم رومیزی شما و تلفن همراه یک مجموعه غنی و کامل از اطلاعات حساس هستند که هردوی آنها شامل اطلاعات شخصی میباشند و برای شما اهمیت زیادی خواهند داشت. تصور کنید زمانیکه برای جلوگیری از نفوذ یا به سرقت رفتن شماره تلفنهای خود، یک پشتیبان بر روی سیستم رو میزی خود تهیه میکنید و فایل پشتیبان شمارههای تماس را بر روی سیستم شخصی نگه داری میکنید! آیا این همان پلتفرم همگرا نیست؟ آیا این دو سیستم مکمل هم نیستند؟حتی اگر همگامسازی را با یک مکان دوردست (Google Drive) انجام دهید، با این حال شما فقط در مقابل از دست دادن دادهها محافظت کردهاید و نه از دست دادن حریم خصوصی!
همچنین در نظر بگیرید که فرمت دادههای ذخیرهشده در دستگاههای تلفن همراه، تعیین و مشخص شوند! این کار اطلاعات حساس شما را به مرز سرقت نزدیکتر میکند. هر تلفن همراه SMS / MMS ، تماسها، و پست صوتی خواهد داشت. مکانهای ذخیره شده از روی GPS و مواردی دیگر که قطعا اطلاع دارید، تمامی اینها جزء مواردی هستند که خطرات امنیتی را در سیستم عامل اندروید شامل میشود. حالا در نظر بگیرید که این اطلاعات تا چه حد مهم است؟ برای کاربرانی که هیچ گونه پشتیبانی از اطلاعاتی از خود ندارند، از دست دادن دادهها قابل تصور نیست!
خطرناکترین نوع حملات بر روی پلتفرم اندروید انجام میشوند، در سکوت کامل و چندین هزار مایل دروتر از شما و فرد مهاجم نیازی به دسترسی فیزیکی و لمس تلفن همراه شما نخواهد داشت! این نوع حملات در هر زمانی ممکن است رخ دهد و اغلب میتواند به دلیل امنیت ضعیف در جای دیگری بر روی دستگاه رخ دهد.
در مطلب بعدی پیرامون امنیت معماری اندروید صبحت خواهیم کرد...
MongoDB #14
- برای ایمن نگه داری اطلاعات
- دسترسی پذیری بالای اطلاعات (شبانه روزی)
- بازیابی اطلاعات
- نیازی به از کار افتادن هنگام انجام عملیات نگهداری ندارد
- مقایس پذیری خواندن دادهها (کپی برداریهای اضافه برای عمل خواندن)
- کپی اطلاعات برای نرم افزارها شفاف و قابل دستیابی است.
تکثیر در MongoDB چگونه کار میکند
- یک مجموعهی کپی، یک گروه از دویا چند گره است. (عموما حداقل 3 گره نیاز است.)
- در یک مجموعهی کپی، یک گره، گره اصلی است و بقیه گرهها گرههای ثانویه هستند.
- همهی دادهها از گرهی اصلی به گرههای ثانویه تکثیر میشوند.
- هنگام انجام عملیات نگه داری یا ازدسترس خارج شدن سرور، گزینش برای گره اصلی و انتخاب گره اصلی جدید آغاز میشود.
- گره از کار افتاده، بعد از بازیابی دوباره، به مجموعه کپی ملحق میشود و بعنوان یک گره ثانویه کار میکند.
ویژگیهای مجموعهی کپی
- یک کلاستر از N عدد گره
- هر گرهایی میتواند گره اصلی باشد
- همهی عملیات نوشتن بر روی گره اصلی انجام میشود
- عمل ازدسترس خارج شدن سرور و جایگزین شدن یک گره بصورت اتوماتیک
- بازیابی بصورت اتوماتیک
- همراهی و توافق در گزینش گره اصلی
ساختن یک مجموعه کپی
- همهی نمونههای در حال اجرای mongod را در سمت سرور، متوقف کنید.
- اکنون mongod سمت سرور را با سوئیچ –replSet راه اندازی کنید.
mongod --port "PORT" --dbpath "YOUR_DB_DATA_PATH" --replSet "REPLICA_SET_INSTANCE_NAME"
mongod --port 27017 --dbpath "D:\set up\mongodb\data" --replSet rs0
گرامر
>rs.add(HOST_NAME:PORT)
>rs.add("mongod1.net:27017") >
معماری میکرو سرویس یا یکپارچه؟
برای درک میکروسرویسها، باید بدانیم کاربرد سیستمهای یکپارچه چیست و چه چیزی باعث شد در زمانهای اخیر از برنامههای یکپارچه به میکروسرویسها حرکت کنیم.
سیستمهای یکپارچه ( Monolithic applications )
اگر تمام عملکردهای یک پروژه در یک بخش واحد وجود داشته باشند، آن برنامه به عنوان یک برنامهی یکپارچه شناخته میشود. ما برنامهی خود را در لایههای مختلفی مانند Presentation ، Service ، UI طراحی میکنیم و سپس آن بخش از کدهای نوشته شده را به عنوان یک فایل خروجی به کار میگیریم. این چیزی نیست جز یک برنامهی یکپارچه، که در آن " mono " یک پایگاه کد منفرد حاوی تمام عملکردهای مورد نیاز را نشان میدهد.
چرا اصلا به سمت میکروسرویسها برویم؟
خب برای جواب به این سوال بهتر است معایب سیستمهای یکپارچه را مرور کنیم:
- مدیریت دشوار بخاطر گسترش برنامه در گذشت زمان
- برای تغییری کوچک، کل برنامه را دوباره باید منتشر ( publish ) کنیم
- با تغییر و آپدیت برنامه، زمان انتشار افزایش مییابد.
- درک دشوار برای توسعه دهندههای جدید هر پروژه
- برای تقسیم ترافیک روی قسمتهای مختلف برنامه، باید نمونههای کل برنامه را در چندین سرور منتشر کنیم که بسیار ناکارآمد و باعث استفادهی بیهوده از منابع میشود
- اگر از فناوری یا تکنولوژیهای جدید استفاده کنیم، برای عملکردی خاص، چه از نظر هزینه و چه از نظر زمان، بر کل برنامه تاثیر گذار است
- و در نهایت وجود یک باگ در هر ماژول میتواند کل برنامه را مختل کند.
و اما مزایای سیستمهای یکپارچه:
- توسعهی آن نسبت به میکروسرویسها ساده است.
- انتشار آن آسانتر است؛ زیرا فقط یک خروجی، مستقر شدهاست.
- در مقایسه با معماری میکروسرویسها، توسعهی آن نسبتا آسانتر و سادهتر است.
- مشکلات تأخیر و امنیت شبکه در مقایسه با معماری میکروسرویسها نسبتاً کمتر است.
- توسعه دهندگان نیازی به یادگیری برنامههای مختلف ندارند؛ آنها میتوانند تمرکز خود را بر روی یک برنامه حفظ کنند.
میکروسرویس ها
این یک سبک توسعه معماری است که در آن برنامه از سرویسهای کوچکتری تشکیل شدهاست که بخش کوچکی از عملکرد و دادهها را با برقراری ارتباط مستقیم با یکدیگر، با استفاده از پروتکلی مانند HTTP مدیریت میکند. به عبارتی دیگر خدمات یا سرویسهای کوچکی هستند که با هم کار میکنند.
معماری میکروسرویس تأثیر بسزایی در رابطهی بین برنامه و پایگاه داده دارد. بجای اشتراک گذاری یک پایگاه داده با سایر میکروسرویسها، هر میکروسرویس، پایگاه داده خاص خود را دارد که اغلب منجر به تکثیر برخی از دادهها میشود، اما اگر میخواهید از این معماری بهره مند شوید، داشتن یک پایگاه داده در هر میکروسرویس، ضروری است؛ زیرا اتصال ضعیف را تضمین میکند. مزیت دیگر داشتن یک پایگاه دادهی مجزا برای هر میکروسرویس این است که هر میکروسرویس میتواند از نوع پایگاه دادهای که برای نیازهای خود مناسبتر است، استفاده کند. هر سرویس یک ماژول را ارائه میدهد، به طوری که خدمات مختلف را میتوان به زبانهای برنامه نویسی مختلف نوشت. الگوهای زیادی در معماری میکروسرویس دخیل هستند مانند discovery و registry service ، Caching ، ارتباط API ، امنیت و غیره.
اصول میکروسرویسها:
تک مسئولیتی: یکی از اصولی است که به عنوان بخشی از الگوی طراحی SOLID تعریف شده است. بیان میکند که یک Unit ، یا یک کلاس، یک متد یا یک میکروسرویس باید تنها یک مسئولیت را داشته باشد. هر میکروسرویس باید یک مسئولیت داشته باشد و یک عملکرد واحد را ارائه دهد. شما همچنین میتوانید بگویید تعداد میکروسرویسهایی که باید توسعه دهید، برابر با تعداد عملکردهای مورد نیاز شما است. پایگاه داده نیز غیرمتمرکز است و به طور کلی، هر میکروسرویس، پایگاه داده خاص خود را دارد.
بر اساس قابلیتهای تجاری ساخته شده است: در دنیای امروزی که فناوریهای زیادی وجود دارند، همیشه فناوریای وجود دارد که برای اجرای یک عملکرد خاص مناسبتر است. اما در برنامههای یکپارچه، این یک اشکال بزرگ بود؛ زیرا ما نمیتوانیم از فناوریهای مختلف برای هر عملکرد استفاده کنیم و از این رو، نیاز به مصالحه در زمینههای خاص داریم. یک میکروسرویس هرگز نباید خود را از پذیرش پشته فناوری مناسب یا ذخیرهسازی پایگاه داده پشتیبان که برای حل هدف تجاری مناسبتر است، محدود کند؛ بهعنوان مثال، هر میکروسرویس میتواند بر اساس نیازهای تجاری از فناوریهای متفاوتی استفاده کند.
طراحی برای مدیریت خطاها: میکروسرویسها باید با در نظر گرفتن مدیریت خطاها طراحی شوند. میکروسرویسها باید از مزیت این معماری استفاده کنند و پایین آمدن یک میکروسرویس نباید بر کل سیستم تأثیر بگذارد و سایر عملکردها باید در دسترس کاربر باقی بمانند. اما در برنامههای کاربردی سیستمهای یکپارچه که خطای یک ماژول منجر به سقوط کل برنامه میشود، اینگونه نبود.
مزایای میکروسرویس ها:
- مدیریت آن آسان است زیرا نسبتا کوچکتر است.
- اگر در یکی از میکروسرویسها، بروزرسانی وجود داشته باشد، باید فقط آن میکروسرویس را مجدداً منتشر کنیم.
- میکروسرویسها مستقل هستند و از این رو به طور مستقل منتشر میشوند. زمان راه اندازی و انتشار آنها نسبتاً کمتر است.
- برای یک توسعهدهنده جدید بسیار آسان است که وارد پروژه شود، زیرا او باید فقط یک میکروسرویس خاص را که عملکردی را که روی آن کار میکند، درک کند و نه کل سیستم را.
- اگر یک میکروسرویس خاص به دلیل استفاده بیش از حد کاربران از آن عملکرد، با بار زیادی مواجه است، ما باید فقط آن میکروسرویس را تنظیم کنیم. از این رو، معماری میکروسرویس از مقیاس بندی افقی پشتیبانی میکند.
- هر میکروسرویس بر اساس نیازهای تجاری میتواند از فناوریهای مختلفی استفاده کند.
- اگر یک میکروسرویس خاص به دلیل برخی باگها از کار بیفتد، بر روی سایر میکروسرویسها تأثیر نمیگذارد و کل سیستم دست نخورده باقی میماند و به ارائه سایر عملکردها به کاربران ادامه میدهد.
معایب میکروسرویس ها:
- پیچیده است و پیچیدگی آن با افزایش تعداد ریز سرویسها افزایش مییابد.
- نیاز به نیروهای متخصص
- استقرار مستقل میکروسرویسها پیچیدهاست.
- میکروسرویسها از نظر استفاده از شبکه پرهزینه هستند؛ زیرا نیاز به تعامل با یکدیگر دارند و همه این تماسهای راه دور منجر به تأخیر شبکه میشود.
- امنیت کمتر به دلیل ارتباط بین سرویسها
- اشکال زدایی دشوار است
AngularJS #3
<!DOCTYPE html> <html ng-app> <head> <title>Sample2</title> </head> <body> <div> <input type="text" ng-model="greeting.text" /> <p>{{greeting.text}}, World!</p> </div> <script src="../Scripts/angular.js"></script> </body> </html>
<!DOCTYPE html> <html ng-app> <head> <title>Sample2</title> </head> <body> <div ng-controller="GreetingController"> <input type="text" ng-model="greeting.text" /> <p>{{greeting.text}}, World!</p> <button ng-click="showData()">Show</button> </div> <script src="../Scripts/angular.js"></script> <script> var GreetingController = function ($scope, $window) { $scope.greeting = { text: "Hello" }; $scope.showData = function () { $window.alert($scope.greeting.text); }; }; </script> </body> </html>
var FN_ARGS = /^function\s*[^\(]*\(\s*([^\)]*)\)/m; var FN_ARG_SPLIT = /,/; var FN_ARG = /^\s*(_?)(\S+?)\1\s*$/; var STRIP_COMMENTS = /((\/\/.*$)|(\/\*[\s\S]*?\*\/))/mg;
قسمت اول : تبادل دادهها بین لایه ها- قسمت اول
روش دوم: Uniform(Entity classes)
روش دیگر پاس دادن دادهها، روش uniform است. در این روش کلاسهای Entity، یک سری کلاس ساده به همراه یکسری Property های Get و Set میباشند. این کلاسها شامل هیچ منطق کاری نمیباشند. برای مثال کلاس CustomerEntity که دارای دو Property ، Customer Name و Customer Code میباشد. شما میتوانید تمام Entity ها را به صورت یک پروژهی مجزا ایجاد کرده و به تمام لایهها رفرنس دهید.
public class CustomerEntity { protected string _CustomerName = ""; protected string _CustomerCode = ""; public string CustomerCode { get { return _CustomerCode; } set { _CustomerCode = value; } } public string CustomerName { get { return _CustomerName; } set { _CustomerName = value; } } }
خوب، اجازه دهید تا از CustomerDal شروع کنیم. این کلاس یک Collection از CustomerEntity را بر میگرداند و همچنین یک CustomerEntity را برای اضافه کردن به دیتابیس . توجه داشته باشید که لایه Data Access وظیفه دارد تا دیتای دریافتی از دیتابیس را به CustomerEntity تبدیل کند.
public class CustomerDal { public List<CustomerEntity> getCustomers() { // fetch customer records return new List<CustomerEntity>(); } public bool Add(CustomerEntity obj) { // Insert in to DB return true; } }
لایه Middle از CustomerEntity ارث بری میکند و یکسری operation را به entity class اضافه خواهد کرد. دادهها در قالب Entity Class به لایه Data Access ارسال میشوند و در همین قالب نیز بازگشت داده میشوند. این مسئله در کد ذیل به روشنی مشاهده میشود.
public class Customer : CustomerEntity { public List<CustomerEntity> getCustomers() { CustomerDal obj = new CustomerDal(); return obj.getCustomers(); } public void Add() { CustomerDal obj = new CustomerDal(); obj.Add(this); } }
لایه UI هم با تعریف یک Customer و فراخوانی operation های مربوط به آن، دادهی مد نظر خود را در قالب CustomerEntity بازیابی خواهد کرد. اگر بخواهیم عمکرد روش uniform را خلاصه کنیم باید بگوییم، در این روش دیتای رد و بدل شدهی مابین کلیه لایهها با یک ساختار استاندارد، یعنی Entity پاس داده میشوند.
مزایا و معایب روش uniform
مزایا
·Strongly typed به صورت در تمامی لایهها قابل دسترسی و استفاده میباشد.
· به دلیل اینکه از ساختار عمومی Entity استفاده میکند، بنابراین فقط یکبار نیاز به تبدیل دادهها وجود دارد. به این معنی که کافی است یک بار دیتای واکشی شده از دیتابیس را به یک ساختار Entity تبدیل کنید و در ادامه بدون هیچ تبدیل دیگری از این Entity استفاده کنید.
معایب
· تنها مشکلی که این روش دارد، مشکلی است به نام Double Loop . هنگامیکه شما در مورد کلاسهای entity بحث میکنید، ساختارهای دنیای واقعی را مدل میکنید. حال فرض کنید شما به دلیل یکسری مسایل فنی دیتابیس خود را Optimize کرده اید. بنابراین ساختار دنیای واقعی با ساختاری که شما در نرم افزار مدل کردهاید متفاوت میباشد. بگذارید یک مثال بزنیم؛ فرض کنید که یک customer دارید، به همراه یکسری Address. همان طور که ذکر کردیم، به دلیل برخی مسایل فنی ( denormalized ) به صورت یک جدول در دیتا بیس ذخیره شده است. بنابراین سرعت واکشی اطلاعات بیشتر است. اما خوب اگر ما بخواهیم این ساختار را در دنیای واقعی بررسی کنیم، ممکن است با یک ساختار یک به چند مانند شکل ذیل برخورد کنیم.
بنابراین مجبوریم یکسری کد جهت این تبدیل همانند کد ذیل بنویسیم.
foreach (DataRow o1 in oCustomers.Tables[0].Rows) { obj.Add(new CustomerEntyityAddress()); // Fills customer foreach (DataRow o in oAddress.Tables[0].Rows) { obj[0].Add(new AddressEntity()); // Fills address } }
سایت databaseanswers.org قسمتی را دارد تحت عنوان Data models که طراحی دیتابیس بیش از 600 سیستم را جمع آوری کرده است.
از data model سیستم مدیریت ارتباطات
تا data model یک باغ وحش
Ionic , react native , flutter , xamarin ….
مزایای نوشتن یک اپلیکیشن با فریم ورکها:
1- نوشتن کد به مراتب آسانتر است.
۲- چون اکثر فریم ورکها، فریم ورکهای جاوا اسکریپتی هستند، سرعت بالایی هنگام run کردن برنامه دارند ولی در build آخر و خروجی نهایی بر روی پلتفرم، این سرعت کندتر میشود.
۳- cossplatform بودن. با طراحی یک اپلیکیشن برای یک پلتفرم میتوان همزمان برای پلتفرمهای دیگر خروجی گرفت.
۱- برنامه نویس را محدود میکند.
۲- سرعت اجرای پایینی دارد.
۳- حجم برنامه به مراتب بالاتر میباشد.
۴- از منابع سخت افزاری بیشتری استفاده میکند.
اگر شما هم میخواهید از فریم ورکها برای طراحی اپلیکیشن استفاده کنید در اینجا میتوانید اطلاعات بیشتری را درباره هر کدام از فریم ورکها ببینید. هر کدام از این فریم ورکها دارای مزایا معایب و همچنین رزومه کاری خوب میباشند. بیشتر فریم ورکهای بالا در رندر آخر، همان کد native را تولید میکنند؛ مثلا اگر برنامهای را با react native بنویسید، میتوانید همان برنامه را بر روی اندروید استودیو و کد native بالا بیارید. توضیحات بالا مقایسه فریم ورکهای Cross Platform با زبانهای native بود. اما در این مقاله قصد آشنایی با تکنولوژی جدیدی را داریم که شما را قادر میسازد یک وب اپلیکیشن را با آن طراحی کنید.
pwa مخفف Progressive Web Apps است و یک تکنولوژی برای طراحی وب اپلیکیشنهای تحت مرورگر میباشد. شما با pwa میتوانید اپلیکیشن خود را بر روی پلتفرمهای مختلفی اجرا کنید، طوری که کاربران متوجه نشوند با یک صفحهی وبی دارند کار میکنند. شاید شما هم فکر کنید این کار را هم میتوان با html ,css و responsive کردن صفحه انجام داد! ولی اگر بخواهید کاربر متوجه استفادهی از یک صفحهی وبی نشود، باید حتما از pwa استفاده کنید! برای مثال یک صفحهی وبی معمولی حتما باید در بستر اینترنت اجرا شود، ولی با pwa با یکبار وصل شدن به اینترنت و کش کردن دادهها، برای بار دوم دیگر نیازی به اینترنت ندارد و میتواند به صورت offline کار کند. شما حتی با pwa میتوانید اپلیکیشن را در background اجرا کنید و notification ارسال کنید.
۱- یکی از مزیتهای مهم pwa، حالت offline آن میباشد که حتی با قطع اینترنت، شما میتوانید همچنان با اپلیکیشن کار کنید.
۲- با توجه به اینکه شما در حقیقت با یک صفحهی وبی کار میکنید، دیگر نیازی به دانلود و نصب ندارید.
۳- امکان بهروز رسانی کردن، بدون اعلام کردن نسخه جدید.
۴- از سرعت بسیار زیادی برخوردار است.
۵- چون pwa از پروتکل https استفاده میکند، دارای امنیت بالایی میباشد.
۱- محدود به مرورگر میباشد.
۲- هرچند امروزه اکثر مرورگرها pwa را پشتیبانی میکنند، ولی در بعضی از مرورگرها و مرورگرهای با ورژن پایین، pwa پشتیبانی نمیشود.
3- نمیتوان یک برنامهی مبتنی بر os را نوشت و محدود به مرورگر میباشد
1- برای pwa لزومی ندارد حتما از فریم ورکهای spa استفاده کنید. شما از هر فریم ورک Client Side ای میتوانید استفاده کنید.
۲- چون صفحات شما در پلتفرمهای مختلف و با صفحه نمایشهای مختلفی اجرا میشود، باید صفحات به صورت کاملا responsive شده طراحی شوند.
۳- باید از پروتکل https استفاده کنید.
ما در این مقاله از فریم ورک angular استفاده خواهیم کرد.
قبل از شروع، با شیوه کار pwa آشنا خواهیم شد. یکی از قسمتهای مهم Service Worker ،pwa میباشد که از جمله کش کردن، notification فرستادن و اجرای پردازشها در پس زمینه را بر عهده دارد.
چند نکته در رابطه با Service Worker
- نباید برای نگهداری داده global از Service Worker استفاد کرد. برای استفاده از دادههای Global میتوان از Local Storage یا IndexedDB استفاده کرد.
- service worker به dom دسترسی ندارند.
قبل از شروع، سناریوی پروژه را تشریح خواهیم کرد. رکن اصلی یک برنامهی وب، UI آن میباشد و قصد داریم کاربران را متوجه کار با یک صفحهی وبی نکنیم. قالبی که ما در این مثال در نظر گرفتیم خیلی شبیه به یک اپلیکیشن پلتفرم اندرویدی میباشد. یک کاربر با کشیدن منوی کشویی میتواند گزینههای خود را انتخاب نمایند. اولین گزینهای که قصد پیاده سازی آن را داریم، ثبت کاربران میباشد. بعد از ثبت کاربران در یک Component جدا، کاربران را در یک جدول نمایش خواهیم داد.
1- سرویس crud را به صورت کامل در پروژه قرار خواهیم داد، ولی چون از حوصلهی مقاله خارج است، فقط ثبت کاربران و نمایش کاربران را پیاده سازی خواهیم کرد.
شروع به کار
پیش نیازهای یک پروژهی انگیولاری را بر روی سیستم خود فراهم کنید. ما در این مثال از یک template آماده انگیولاری استفاده خواهیم کرد. پس برای اینکه با جزئیات و طراحی ui درگیر نشویم، از لینک github پروژه را دریافت کنید.
سپس وارد root پروژه شوید و با دستور زیر پکیجهای پروژه را نصب کنید:
npm install
قبل از اینکه کاری را انجام دهید، چند بار صفحه را refresh کنید! صفحه بدون هیچ تغییری refresh میشود. اینبار گزینهی offline را فعال کنید و مجددا صفحه را refresh کنید.
نصب pwa بر روی پروژه
برای اضافه کردن pwa به پروژه وارد ریشهی پروژه شوید و دستور زیر را وارد کنید:
ng add @angular/PWA
Manifest.json : اگر محتویات فایل را مشاهده کرده باشید، شامل تنظیمات فنی وب اپلیکیشن میباشد؛ از جمله Home Screen Icon و نام وب اپلیکیشن و سایر تنظیمات دیگر.
Nsgw-config.json : این فایل نسبت به فایل manifest فنیتر میباشد و بیشتر به کانفیگ مد آفلاین و کش کردن مرتبط میشود. در ادامه با این فایل بیشتر کار داریم.
اجرا کردن وب اپلیکیشن
برای اجرا کردن و نمایش خروجی از وب اپلیکیشن، ابتدا باید از پروژه build گرفت. با استفاده از دستور زیر از پروژه خود build بگیرید:
ng build -- prod
cd dist/Web Application Pwa
Http-server -o
npm i http-server
برسی فایل Nsgw-config.json
وارد فایل Nsgw-config.json شوید:
"$schema": "./node_modules/@angular/service-worker/config/schema.json", "index": "/index.html", "assetGroups": [ { "name": "app", "installMode": "prefetch", "resources": { "files": [ "/favicon.ico", "/index.html", "/*.css", "/*.js" ] } }, { "name": "assets", "installMode": "lazy", "updateMode": "prefetch", "resources": { "files": [ "/assets/**", "/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)" ] } } ], "dataGroups": [ { "name": "api-performance", "urls": [ "https://api/**" ], "cacheConfig": { "strategy": "performance", "maxSize": 100, "maxAge": "3d" } } ] }
۱- assetGroups : کش کردن اطلاعات مربوط به اپلیکیشن
۲- Index : کش کردن فایل مربوط به index.html
۳- assetGroups : کش کردن فایلهای مربوط به asset، شامل فایلهای js، css و غیره
۴- dataGroups : این object مربوط به وقتی است که برنامه در حال اجرا است. میتوان دادههای در حال اجرای اپلیکیشن را کش کرد. دادهی در حال اجرا میتواند شامل فراخوانی apiها باشد. برای مثال فرض کنید شما در حالت کار کردن online با اپلیکیشن، لیستی از اسامی کاربران را از api گرفته و نمایش میدهید. وقتی دفعهی بعد در حالت offline اپلیکیشن را باز کنیم، اگر api را کش کرده باشیم، اپلیکیشن دادهها را از کش فراخوانی میکند. این عمل درباره post کردن دادهها هم صدق میکند.
خود dataGroups شامل چند object زیر میباشد:
۱- name : یک نام انتخابی برای Groups میباشد.
۲- urls : شامل آرایهای از آدرسها میباشد. میتوان آدرس یک دومین را همراه با کل apiها به صورت زیر کش کرد:
"https://api/**"
۱- maxSize : حداکثر تعداد کشهای مربوط به Groups .
۲- maxAge : حداکثر lifetime مربوط به کش.
۳- strategy : که میتواند یکی از مقادیر freshness به معنی Network-First یا performance به معنی Cache-First باشد.
پیاده سازی پیغام نمایش بهروزرسانی جدید وب اپلیکیشن
در اپلیکیشنهای native وقتی بهروزرسانی جدیدی برای app اعلام میشود، در فروشگاهای اینترنتی پیغامی مبنی بر بهروزرسانی جدید app برای کاربران ارسال میشود که کاربران میتوانند app خود را بهروزرسانی کنند. ولی در pwa تنها با یک رفرش صفحه میتوان اپلیکیشن را به جدیدترین امکانات بهروزرسانی کرد! برای اینکه بتوانیم با هر تغییر، پیغامی را جهت بهروزرسانی نسخه یا هر پیغامی دیگری را نمایش دهیم، از کد زیر استفاده میکنم:
if(this.swUpdate.isEnabled) { this.swUpdate.available.subscribe(()=> { if(confirm("New Version available.Load New Version?")){ window.location.reload(); } }) }
در منوی سمت چپ، بر روی database کلیک کنید و یک دیتابیس را در حالت test mode ایجاد نماید. سپس یک collection را به نام user ایجاد کرده و فیلدهای زیر را به آن اضافه کنید:
Age :number Fullname :string Mobile : string
npm install --save firebase @angular/fire
@NgModule({ declarations: [AppComponent, RegisterComponent,AboutComponent, UserListComponent], imports: [ BrowserModule, FormsModule, HttpClientModule, HttpClientModule, SharedModule, AppRoutingModule, AngularFireModule.initializeApp(environmentFirebase.firebase), AngularFireDatabaseModule, ServiceWorkerModule.register('ngsw-worker.js', { enabled: environment.production }), ], providers: [FirebaseService], bootstrap: [AppComponent] }) export class AppModule {}
export const environment ={ production: true, firebase: { apiKey: "AIz×××××××××××××××××××××××××××××××××8", authDomain: "pwaangular-6c041.firebaseapp.com", databaseURL: "https://pwaangular-6c041.firebaseio.com", projectId: "pwaangular-6c041", storageBucket: "pwaangular-6c041.appspot.com", messagingSenderId: "545522081966" } }
FirebaseService در قسمت providers مربوط به سرویس crud میباشد. اگر وارد فایل مربوطه شوید، چند عمل اصلی به صورت زیر در آن پیاده سازی شده است:
import { Injectable } from '@angular/core'; import { Observable } from 'rxjs'; import * as firebase from 'firebase'; import { AngularFireDatabase } from '@angular/fire/database'; import { HttpClient } from '@angular/common/http'; import { map } from 'rxjs/operators'; import { ThrowStmt } from '@angular/compiler'; @Injectable({ providedIn: 'root' }) export class FirebaseService { ref = firebase.firestore().collection('users'); constructor(public db: AngularFireDatabase,public _http:HttpClient) { } getUsers(): Observable<any> { return new Observable((observer) => { this.ref.onSnapshot((querySnapshot) => { let User = []; querySnapshot.forEach((doc) => { let data = doc.data(); User.push({ key: doc.id, fullname: data.fullname, age: data.age, mobile: data.mobile }); }); observer.next(User); }); }); } getUser(id: string): Observable<any> { return new Observable((observer) => { this.ref.doc(id).get().then((doc) => { let data = doc.data(); observer.next({ key: doc.id, title: data.title, description: data.description, author: data.author }); }); }); } postUser(user): Observable<any> { return new Observable((observer) => { this.ref.add(user).then((doc) => { observer.next({ key: doc.id, }); }); }); } updateUser(id: string, data): Observable<any> { return new Observable((observer) => { this.ref.doc(id).set(data).then(() => { observer.next(); }); }); } deleteUser(id: string): Observable<{}> { return new Observable((observer) => { this.ref.doc(id).delete().then(() => { observer.next(); }); }); } getDataOnApi(){ return this._http.get('https://site.com/api/General/Getprovince') .pipe( map((res: Response) => { return res; }) ); } getOnApi(){ return this._http.get("https://site.com/api/General/Getprovince",).pipe( map((response:any) => { return response } ) ); } }
با دستورات زیر میتوانید مجددا پروژه را اجرا کنید:
ng build --prod cd dist/Pwa-WepApp Http-server -o
تست وب اپلیکیشن بر روی پلتفرمهای مختلف
برای اینکه بتوانیم خروجی وب اپلیکیشن را بر روی پلتفرمهای مختلفی تست کنیم، میتوانیم آن را آپلود کرده و مثل یک سایت اینترنتی، با وارد کردن دومین، وارده پروژه شد. ولی کم هزینهترین راه، استفاده از ابزار ngrok میباشد. میتوانید توسط این مقاله پروژه خودتان در لوکال بر روی https سوار کنید.
نکته! توجه کنید apiهای مربوط به firebase را نمیتوان کش کرد.
کدهای مربوط به این قسمت را میتوانید از این repository دریافت کنید .