آموزش TypeScript #1
MySQL مدتی است که جزو یکی از محصولات شرکت اوراکل محسوب شده و توسعه دهندگان تجاری باید برای استفاده از آن هزینه کنند. این هزینه نیز اخیرا افزایش یافته و به حداقل 2000 دلار به ازای هر سرور رسیده است (+). این عدد واقعا رقم بالایی برای محصولی محسوب میشود که بسیاری از توسعه دهندهها تصور میکنند رایگان است. استفاده از این محصول با توجه به مدل تجاری جدید آن فقط در پروژههای سورس باز رایگان است (بله فقط در پروژههایی که با مجوز GPL منتشر شوند) و اگر شما یک سیستم تجاری کلاینت سرور را بر این اساس طراحی کنید حتما باید هزینههای مرتبط را نیز پرداخت نمائید (+).
توضیحی در مورد GPL و MySQL
The change from the LGPL to the GPL for the client libraries was made in 2001 during the development of MySQL 4.0 to help MySQL AB more easily differentiate between a proprietary user who should buy a commercial license and a free software user who should use the GPL license.
MySQL با توجه به مجوز GPL آن در شرایط زیر رایگان خواهد بود:
- قصد توزیع مجدد آنرا نداشته باشید.
- همچنین برنامهی شما نیز به صورت سورس باز تحت مجوز GPL ارائه گردد.
و تنها زمانی در مورد MySQL باید هزینه کنید که:
-قصد توزیع مجدد آنرا داشته باشید.
-برنامهی شما سورس باز نبوده و قصد ندارید آنرا تحت مجوز GPL ارائه دهید. (که عموما در مورد برنامههای تجاری به همین صورت است)
نکتهی دیگری را که باید به آن دقت داشت این است که برای واگذاری MySQL به شرکت اوراکل، اتحادیه اروپا نیز با توجه به وجود بیش از 50 هزار توسعه دهندهی اروپایی که از MySQL استفاده میکنند، شرکت اوراکل را موظف کرده است تا این dual licensing (تجاری و سورس باز) را تا سال 2015 حفظ کرده و ادامه دهد (+). به این معنا که شرکت اوراکل پس از سال 2015 هیچگونه تعهدی به ارائهی نگارش سورس باز این محصول به هیچ نهاد و یا سازمانی ندارد.
البته اینها به معنای پایان دنیا نیست. هم اکنون چهار fork سورس باز از این محصول وجود دارند (Drizzle ، MariaDB ، OurDelta و Percona Server) ولی تنها آینده است که میزان موفقیت، پایداری و تداوم آنها را مشخص خواهد کرد.
وبلاگها ، سایتها و مقالات ایرانی (داخل و خارج از ایران)
Visual Studio
ASP. Net
طراحی و توسعه وب
PHP
اسکیوال سرور
سی شارپ
عمومی دات نت
ویندوز
مسایل اجتماعی و انسانی برنامه نویسی
متفرقه
مقدمه ای بر سیستم مبتنی بر نقش کاربران
یک سیستم مدیریت کاربر مبتنی بر نقش، سیستمی است که در آن نقشهای گوناگونی تعریف میگردد. به گونهای که هر نقش شامل یک سری دسترسی هایی است که به کاربر اجازه میدهد تا به بخشی از سیستم دسترسی داشته باشد. هر کاربر در این سیستم میتواند یک و یا چند نقش متفاوت داشته باشد و بر اساس آن نقشها و دسترسیهای تعریف شده، درون هر نقش به قسمتی از سیستم دسترسی داشته باشد.بر اساس این تعریف ما در نهایت سه موجودیت نقش (Role)، دسترسی (Permission) و کاربر (User) را خواهیم داشت. در این سیستم دسترسی را اینگونه تعریف میکنیم:
دسترسی در یک سیستم، مجموعهای از حوزهها و یا ناحیههایی است که در سیستم تعریف میشود. این حوزهها میتوانند شامل یک متد یا مجموعهای از متدهای نوشته شده و یا فراتر از آن، شامل مجموعهای از کنترلرها باشد که کاربر اجازهی فراخوانی آنها را دارد.
بدیهی است کاربر برای ما موجودیتی مشخص است. یک کاربر ویژگیهایی مانند نام، نام کاربری، سن، رمز عبور و ... خاص خود را داراست که به واسطه این ویژگیها از کاربری دیگر تمییز داده میشود. کاربر در سیستم طی دو مرحله جداگانه Authentication و Authorization مجاز است تا از بخشهایی از سیستم استفاده کند. مرحله Authentication به طور خلاصه شامل مرحلهای است که هویت کاربر (به عنوان مثال نام کاربری و رمز عبور) تایید صلاحیت میشود. این مرحله در واقع تایید کننده کاربر است و اما بخش بعدی که ما قصد داریم تا در این مورد راهکاری را ارائه دهیم بخش Authorization است. در این بخش به کاربر بر اساس نقش وی دسترسیهایی اعطا میگردد و کاربر را به استفاده از بخشهایی از سیستم مجاز میدارد.
دیاگرام زیر نمود سه موجودیت کاربر، نقش و دسترسی میباشد.
برای شرح دیاگرام فوق این چنین میتوان گفت که هر کاربر مجاز است چندین نقش داشته باشد و هر نقش نیز میتواند به چندین کاربر انتساب شود. در مورد دسترسیها نیز به همین صورت، هر دسترسی نیز میتواند به چندین نقش انتساب شود.
ارائه یک سیستم مبتنی بر نقش کاربران با استفاده از تکنولوژی Web API و AngularJs
- تعریف هر یک از متدهای اتمیک به عنوان یک مجوز دسترسی: در این روش نام کنترلر و نام متد به عنوان یک دسترسی تعریف خواهد شد. در این روش به ازای هر متد ما یک آیتم جدید را باید به جدول Permissions، اضافه نماییم و در نهایت برای تعریف یک نقش و انتساب دسترسیها به یک کاربر، بایستی یک مجموعه چک باکس را که در نهایت به یک متد API ختم میشود، فعال یا غیر فعال کنیم.
- تعریف ناحیههای مختلف و کنترلهای قابل انجام در آن ناحیه: در این روش ما قصد داریم تا مجموعهای از متدها را که هدف مشترکی را انجام خواهند داد، در یک ناحیه و یک کنترل بگنجانیم و از به وجود آمدن تعداد زیادی مجوز دسترسی جلوگیری نماییم. به عنوان مثال فرض کنید میخواهیم یک سطح دسترسی را با نام ویرایش کاربران تعریف کنیم. همانگونه که گفتیم ممکن است برای یک عملیات، دو و یا چندین متد درون یک کنترلر تعریف شوند. حال ما این متدها را درون یک ناحیه دسترسی قرار خواهیم داد و آن را در یک حوزه و یک کنترل (Area & Control) میگنجانیم.
آیا با وجود سیاماس فروشگاهی قدرتمندی مثل nopCommerce یا SmartStore آیا منطقی است که ما دوباره خودمان از صفر کد بزنیم؟
- woocommerce (فروشگاههای تا متوسط و عملیات تجاری سبک) - سفارشی سازی در حد وردپرس - راحته ولی رو اعصابه
- prestashop (فروشگاههای تا متوسط و عملیات تجاری متوسط) - سفارشی سازی متوسط - زیرساختهای خیلی پیشرفته درش وجود ندارد
- magento (فروشگاههای تا سایز بزرگ و عملیات تجاری بزرگ) - سفارشی سازی پیشرفته
- nopCommerce(فروشگاههای تا متوسط و عملیات تجاری متوسط) -سفارشی سازی متوسط
- VirtoCommerce(فروشگاههای تا سایز بزرگ و عملیات تجاری بزرگ) -سفارشی سازی پیشرفته، زمان بر است ولی برای کارهای بزرگ لازم است.
- با ASP.NET چند مورد توسعه داشتیم.
قبل از اینکه صحبت را آغاز کنیم باید این نکته اشاره کنیم که انواع هاست چیست؟
انواع هاست
هاستها بر سه نوع تقسیم میشوند:
- هاست اشتراکی
- سرورهای مجازی
- سرور اختصاصی
هاست اشتراکی
در این حالت شرکت میزبان یک سرور را به چند سایت تقسیم کرده و به هر وب سایت، با توجه به پلنی که مشتری انتخاب کرده، مقداری از منابع را اختصاص میدهد که عموما این تخصیص منابع در زمان خرید توسط WHMCS به طور خودکار صورت میگیرد. در این حالت ممکن است بر روی یک سرور بیش از یکصد وب سایت در حال سرویس گرفتن باشند. مزیت این هاستها قیمت ارزان آنها میباشد . عموما وب سایتهای با بازدید کم و نیاز به منابع کمتر، از این دست هاستها استفاده میکنند. در این نوع هاستها در صورتیکه استفادهی از منابع به نهایت مقداری که برای آن مشخص شده است برسد، از قبیل ترافیک (که بیشتر مسئله مربوط به آن است) یا دیسک سخت و ... به حد مشخص شده برسند، سایت را متوقف یا suspend میکنند. پرداخت این نوع هاستها به خاطر قیمت پایین به صورت یکساله دریافت میشود. قیمست سالیانه آنها در بعضی جاها از 50 هزار تومان تا صدهزار تومان به عنوان مبلغ آغازین شروع میشود.
سرورهای مجازی VPS یا Virtual Private Server
اینها هم تقریبا مثل هاستهای اشتراکی هستند با این تفاوت که منابع بیشتر و دسترسی بیشتری به شما داده میشوند؛ به طوری که احساس میکنید به شما یک سرور واقعی را دادهاند و عموما تعداد سایت هایی که روی آن سرویس میگیرند، به مراتب کمتر از هاست اشتراکی است. اکثر وب سایتهایی که توانایی استفاده از هاستهای اشتراکی را ندارند، از این نوع هاستینگ بهره میبرند. قیمتش بالاتر از یک هاست اشتراکی است ولی به مراتب پایینتر از یک سرور اختصاصی است. پرداخت این نوع هاست عموما به دو صورت ماهیانه و یا سالانه است که احتمال زیادی دارد پرداخت سالیانه تخفیف خوبی را شامل شود. در صورت رسیدن به حد نهایت منابع همانند هاست اشتراکی با شما رفتار خواهد شد. این سرورهای مجازی در ایران عموما از مبلغ ماهیانه 20 هزار تومان به بالا آغاز میشوند.
سروهای اختصاصی یا Dedicate
اینها دیگر سروهای واقعی هستند و صاحب اول و آخرشان شمایید و دسترسی کامل به همه اجزا و منابع آن را دارید. این سرورهای عموما برای فعالیتهای بزرگ تجاری و بازدیدهای همزمان به شدت بالا استفاده میشوند. قیمت، بسته به مشخصات آن متفاوت است و ممکن است یکی ماهیانه 200 هزار تومان، یکی ماهیانه 500 هزار تومان و .. آغاز شود.
نکته ای در مورد سرورهای اختصاصی و حتی گاها VPSها هست اینکه عموما پشتیبانی اینها توسط شما تامین میشود و یا باید یک مدیر سرور با حق ماهیانه اختیار کنید یا در صورت بروز مشکل به صورت ساعتی حق حل مشکل را بدهید. بهتر هست این مورد را از قبل توسط میزبان جویا شوید.
سرورهای ابری
اگر قصد انجام عملیات رایانش برای را دارید بهتر هست که دنبال چنین سرورهایی باشید که مورد بحث این مقاله نیست و صرفا جهت تکمیل معرفی انواع هاستها آمده است.
چک لیست
فضای دیسک و پهنای باند (ترافیک)
اولین نکاتی که همیشه توسط میزبانها و خریداران مورد توجه قرار میگیرند، این دو مورد هست. در صورتیکه سایت شما اجازه آپلودی به کاربران نمیدهد، یا خودتان هم آپلود چندانی ندارید، میتوانید فضای دیسک سخت پایینتری را انتخاب کنید. مثلا اگر شما تعدادی تصویر دارید و مقدار زیادی فایل متنی و ... به نظر یک گیگ کفایت میکند و در صورتیکه بعدها دیدید این فضا رو به اتمام است، میتوانید به میزبان درخواست افزایش و ارتقاء آن را بدهید؛ اما برای بار اول یک گیگ به خوبی کفایت میکند. ولی اگر چنانچه با فایلهای حجیم سرو کله میزنید و یا تعداد فایلهایی چون تصاویر، صوت و ویدیو در آن زیاد دیده میشود، بهتر است به فکر فضایی بیشتر و حتی گاها unlimited باشید. برای سایتهایی که حجم به شدت بالایی دارند و یا مثلا نیاز به راه اندازی بخش دانلود دارند، بهتر هست از یک هاستینگ به نام هاست دانلود استفاده کنند. این نوع هاستها به شما اجازه میزبانی فایلهای وب سایتهایی چون aspx,mvc,php را نمیدهند و بیشتر پهنای باند و فضای دیسک سخت آن مدنظر است. در این حالت سایت خود را روی یک هاست معمولی به اشتراک میگذارید و فایلهای خود را روی هاست دانلود قرار میدهید و ارتباط آنها را لینک میکنید.
در مورد پهنای باند باید تعداد کاربر و همچنین نوع اطلاعاتی که جابجا میشوند را مورد بررسی قرار دهید. اگر تعداد کاربران پایین است عموما این مقدار کم است و یا اگر اطلاعات متنی فقط جابجا میشود این مقدار کمتر هم میشود.
در سناریوی اول یک انجمن VB را بررسی میکنیم: عموم انجمنها در زمینهی چند رسانهای مثل تصاویر و ...، چیزی جز تصاویر پوسته خود (که کش هم میشوند) را انتقال نمیدهند. به این دلیل که اجازهی آپلود را به کار نمیدهند و کاربرها بیشتر از سرویسهای ثالث برای تصاویر بهره میبرند و به غیر از پوستهی، سایت متون انجمن هستند که متن هم ترافیک پایینی را مصرف میکند. پس در این حالت ترافیک ماهیانهی 10 گیگ میتواند برای شروع کار تا مدتی که سایت بازدیدکنندههای خودش را پیدا کند، مناسب باشد. از نظر دیسک سخت هم به نظر من اگر شما نیاز به قرار دادن تصاویری چون اسلایدشوها و ... را دارید، به انضمام آواتار کاربران، 500 مگابایت میتواند کافی باشد. حجم آواتار کاربران در قسمت مدیریت، کنترل شده است و تنظیم دستی آن میتواند این مقدار حجم آواتارها را افزایش دهد.
در سناریوی دوم ما یک وب سرویس مثلا برای یک برنامهی اندرویدی را مثال میزنیم: عموما وب سرویسها چیزی جز یک فایل متنی را انتقال نمیدهند؛ مگر اینکه از تصاویر، صورت و ویدیو هم بهره برده باشید. در صورتیکه بیشتر همان متن را بخواهید انتقال دهید، ترافیکی جز همان متن مصرف نمیشود و حتی از یک انجمن هم مصرف پایینتری دارد و میتواند ماهیانه 10 گیگ یا حتی کمتر هم مورد استفاده قرار بگیرد. در صورت اضافه شدن تصویر و دیگر موارد چندرسانهای و کاربران در حال افزایش، این مقدار هم به همان تناسب بالا میرود.
سرعت Speed و توان سرویس دهی(Uptime)
بعد از ارزیابی موارد بالا نوبت به این دو مورد میرسد. اینکه هاست شما به قولی چقدر دوام و ایستادگی دارد، بسیار مهم است و در صورتیکه این امر محقق نگردد، میتواند موجب از دست دادن و شنیدن اعتراض کاربرها باشید. uptime به معنی این است که در یک دورهی زمانی چقدر وب سایت شما در دسترس بوده است؛ درست شنیدید! حتما پیش خودتان میگویید خوب، یک وب سایت همیشه در دسترس است. ولی واقعیت را بخواهید خیر، اینگونه نیست. اگر سرویس دهندهی خوبی را انتخاب نکنید، ممکن است در روز یا هفته یا در هرمقطع زمانی، با در دسترس نبودن وب سایت روبرو شوید؛ تقریبا مشابه زمانیکه adsl شما قطع میشود، چند لحظهای (طولانیتر از زمان عادی) مرورگر شما سعی کرده و میبیند که زورش نمیرسد و یک پیام عدم دسترسی را به شما نمایش میدهد.
به خوبی به یاد دارم که یک میزبان، هاستهای ارزان قیمتی را ارائه میکرد، ولی گاها در روز دو الی سه بار پنج دقیقهای سرور از دسترس خارج میشد و میگفتیم این هاست برای کسانی است که پول کافی ندارند و یا خیلی نمیخواهند خرج کنند و حالا پنج دقیقهای هم در روز در دسترس نباشد اهمیتی ندارد. در سایتها بیشتر این مورد را با اعدادی شبیه 99.9% مشخص میکنند و پیشنهاد میکنم هاستی را بخرید که این عدد را به شما نشان میدهد، یا حداقل دیگر 99.5% کمتر نباشد. البته تمامی هاستها همین را مینویسند، ولی واقعیت چیز دیگری است و بهتر از از دوستان و آشنایان و جستجوی در اینترنت و انجمنها به این مورد برسید.
فاکتور بعدی سرعت سرور است و کاربران به این مورد هم اهمیت ویژهای میدهند. به خوبی به یاد دارم، اولین هاستی که در کارم استفاده کردم و به پیشنهاد دوستم که در آن کار میکرد این هاست را خریداری کردم، اوایل خوب بود، ولی مشکل سرعت بعدها اضافه شد که حتی ورود به پنل مدیریتی چند دقیقهای طول میکشید. یا اینکه چند وقت پیش وب سایتی را مطالعه میکردم که فقط متن جابجا میکرد، ولی به طوری که کندتر از زمان اجرای یک سایت با گرافیک متوسط طول میکشید. (البته این نکته حائز اهمیت است خود وب سایت هم باید از این لحاظ مورد بررسی قرار گیرد و مشکل را سریعا گردن سرویس دهنده نیندازیم).
برای اینکه بدانیم که سرعت یک هاست چگونه باید ارزیابی شود باید سه مورد را بررسی کنیم :
- دیتاسنتر
- سرور
- نزدیکی سرور به محل زندگی کاربران هدف
مورد سوم نزدیکی سرور به کاربران هدف است. هر چقدر traceroute و پینگ زمانی کمتری به سرور داشته باشید، دسترسی به اطلاعات آن سریعتر میشود. در ایران عموما از کشورهایی چون آمریکا، کانادا ، انگلیس ، آلمان و استرالیا سرور خریده میشود و به مدت چندسالی است که در ایران هم این امکان فراهم شده است ولی خب مسائلی که این سرورها در ایران دارند باعث میشوند عدهی زیادی دور آنها را که هیچ روی آنها را هم خط بکشند.
مشکلاتی که این سرورها دارند بیشتر به سه مورد زیر بر میگردد:
هزینهی سنگین ترافیک : این مورد آن قدر به وضوح پیداست که شما را به کل برای هر نوع خریدی پشیمان میکند؛ مگر اینکه پولتان از جایی تامین میشود. ادارات دولتی عموما این نوع هاست را بر میدارند و یا سایتهای اشتراکی که منابع زیادی را مصرف نمیکنند و یا شرکتها یا اشخاصی که پول تامین را دارند.
عدم دسترسی به شبکههای اجتماعی یا هرسرویس دهندهی مسدود شده : من این را تست نکردم ولی با دو دوتا چهارتا کردن این حساب دستم آمد که وقتی سایتی مثل فیس بوک و توئیتر در ایران مسدود باشند، باید روی این سرورها هم مسدود باشند. در نتیجه اگر سایت شما مطالبش را در این سایتها معرفی میکند و میخواهید پست و توئیتی روی آنها داشته باشید، احتمالا توانایی این کار را نخواهید داشت. مگه اینکه خودتان دستی بروید در سایت مربوطه و اضافه کنید.
جایگاه پایینتر SEO : گفتیم که یکی از عوامل سرعت، نزدیک بودن سرور به کاربر هدف است. این مورد برای سرور موتورهای جستجویی مثل گوگل که در ایران سروری ندارند هم اتفاق میافتد و در نتیجه گوگل از لحاظ امتیاز بندی سرعت، امتیاز شما را کم میکند ولی این مورد همیشه چندان صدق نمیکند و مبحث ترافیک سایت بیشتر مورد ارزیابی قرار میگیرد.
امنیت
این مورد شامل دو بخش میشود یکی امنیت دسترسی به سرور و دیگر امنیت نگهداری اطلاعات. نصب فایروالها روی سرور و نظارت 24 ساعته روی سرورهای شرکت (که شامل بخش پشتیبانی میشود) میتواند این موردها را پوشش دهد. هر چند این مورد را زیاد نمیتوانید محک بزنید، ولی اگر اخباری چون «همکاری با یک شرکت امنیتی جهت تست سرور و همکاری با تعدادی هکر جهت تست سرور» و ... را شنیدید، میتوانید این اطمینان را کسب کنید که آنها به این مورد اهمیت میدهند.
امنیت اطلاعات چون پشتیبانهای روزانه و نگهداری اطلاعات تا مدتی معین پس از اتمام قرارداد و موارد این چنینی، میتواند شما را مطمئن سازد. در مورد یکی از مشتریانم به خاطر دارم که فراموش کرده بود هاست را تمدید کند و یک روز بعد از انقضاء ما درخواست دیتابیس را داشتیم که برای ما ارسال کنند و به گفتهی خودشان ما مسئولیتی در قبال نگه داری اطلاعات نداریم، ولی تا 5 روز نگه میداریم که البته گفتند هر چه به دنبال دیتابیس گشتند، چیزی پیدا نکردند که البته این مشکل را از راهکار دیگری حل کردیم و ماجرا به خوشی تمام شد. ولی جالب این بود که اینقدر که من حرص خوردم، چطوری به مدیر اینها بگوئیم که اطلاعات تیمشان پریده و اینها حرص نخوردند و بی خیال.
کنترل پنل
میگویند کنترل پنل هم چیز مهمی است ولی در اکثر اوقات اکثر هاستینگها از همان پنلهای معروف استفاده میکنند. برای مثال در لینوکس "سی پنل" و در ویندوز "وب سایت پنل" و "پلسک" میباشد . تا آخرین باری که من با آنها کار کردم، وب سایت پنل، یک پنل سبک بود که برای انجام عملیات ساده تا متوسط در زمینه کاری پنلها میباشد و پلسک نسبت به آن امکانات خیلی زیادتری دارد. اکثرا آنها حاوی امکانی چون نصب یک کلیکی CMS هایی چون وردپرس و جوملا و ... هستند.
اگر از یک سرور اختصاصی بهره ببرید خودتان مختار نصب هر نوع چیزی روی آن هستید و در مورد کنترل پنل هم صدق میکند ولی عموما شرکتها یک سری الگوهای پیش فرضی را برای سرویسهای خود دارند که در صورت تغییر باید به آنها، تغییرات را طلاع دهید.
موردی را تصور کنید که ساعت 2 شب هست و سایت شما هم که در زمینهی مهم و حساسی فعالیت میکند، یک دفعه سرویس آن قطع میشود و برای سرور مشکلی پیش میآید. در این موقع چکاری را انجام میدهید؟ صبر میکنید تا صبح شود و سرویس شما راه بیفتد و کاربران هم از سایت شما نا امید شوند؟ اگر این مشکل به دفعات رخ بدهد چه؟ اگر چند روز پشت سرهم تعطیلی باشد چه؟
همهی این موارد مربوط به پشتیبانی میشود. این پشتیبانیها عموما به صورت چت و تلفنی (بیشتر مربوط به ساعات اداری) و ارسال تیکت در سامانه پشتیبانی میشود. البته تجربهی من میگوید در ایران زیاد به متون نوشتهی روی سایت میزبان توجهی نکنید و این را هم به موضوع تحقیق خود اضافه کنید. بعضیها میگویند 24 ساعته پشتیبانی تلفنی دارند ولی هر بار زنگ میزنی کسی پاسخی نمیدهد. یا تیکت میزنید و بارها و بارها پشت سر هم تیکت "چی شد؟" را برای جویا شدن ارسال میکنید. (البته انصاف هم داشته باشید و پنج دقیقه پنج دقیقه این تیکت را نفرستید).
پشتیبانی هر نوع سرور را مطلع شوید. بعضیها واقعا پشتیبانی دارند!؟ ولی وقتی زنگ میزنید میگویند این پشتیبانی مربوط به لینوکس است و بچههای ویندوز فقط ساعات اداری هستند. خلاصه حواستان را جمع کنید که بچههای آن بخش همیشه باشند.
بنابراین مطمئن شوید که یک پشتیبانی 24/7 واقعی داشته باشند.
امکانات اضافه
در کنار خود هاست یک سری ویژگیهایی چون FTP و تعدادی دامنههای پشتیبانی شده و زیر دامنهها و تعداد دیتابیسها و ایمیل و ... هم هستند که در قدیم یادم هست محدودیتهایی در این رابطه ایجاد کرده بودند که امروزه از این نظر در اکثر هاستها آن طور که دیدم این محدودیتها رفع شده است که البته خیلی هم خوب هست و این محدودیتها بیشتر شبیه سودجویی بود تا چیز دیگر.
هزینه
با همهی حرفهای بالا به نظر میرسد که هزینه، همه این معادلات را به هم میریزد. هاستینگهای مختلف و قیمتهای مختلف، تصمیم گیرنده شما هستید که چقدر به عوامل بالا اهمیت میدهید و چگونه آنها را در راستای قیمت اولویت بندی میکنید. اگر محدودیتی ندارید سعی کنید همهی عوامل را بررسی کنید. نکته اینکه اکثر هاستها طرحی به نام ضمانت برگشت پول را در هفت روز یا گاها یک ماه، دارند و در صورتیکه از سرویس خریداری شده راضی نبودید میتوانید پول خود را پس گرفته و سرویس معلق شود.
کل مطالب گفته شده در چک لیست به طور خلاصه : اول از همه بررسی فضای ذخیره سازی و پهنای باند، بعد از آن بررسی توانایی سرویس دهی و سرعت سرورها، داشتن محیط امن و پشتیبانی مناسب بود.
هاستینگ در قرارداد
هنگام عقد قرارداد با مشتری، در قرارداد در مورد هاستینگ که خودش تهیه میکند، این نکته ذکر شود که شما در مورد مسائلی که مربوط به هاست و دامنه میشود هیچ مسئولیتی ندارید و باید مشکلات را با مسئولان آن در میان بگذارد.
همچنین این نکته هم ذکر شود در مورد مسائلی چون عدم پشتیبانی مناسب هاست، از محصول یا سرویس شما، شما هیچگونه مسئولیتی در قبال آن ندارید و یا باید این مورد توسط شما دنبال شود یا خرید ایشان با مشاوره و تایید شما از هاست مربوطه باشد.
در صورتی که مشتری نمیتواند شخصا خرید هاستینگ را انجام دهد یا در شرکت مسئولین IT ندارند که این کار را انجام دهند و این مورد به شما محول میشود، در قرارداد ذکر شود که شما هیچ گونه مسئولیتی در قبال مشکلاتی که برای هاست و دامنه رخ میدهد ندارید و تنها میتوانید به عنوان یک واسط یا وکیل در ازای مبلغ توافق شدهای مشکل را با مسئولین هاست و دامنه در میان گذاشته و ماجرا را برای حل مشکل ایجاد شده دنبال کنید یا این کار را به عنوان هدیه ای از طرف خدمات طلایی شما به مشتریان به صورت رایگان انجام دهید.
توضیحاتی در مورد سیستم Identity پروژه
ببینید پروژه شما طوری طراحی شده که میشه به هر Role چندین مجوز داده بشه.
فرض کنید مجوزهای ما به این صورت هستند : مجوز A و B و C و D و E و ...
مثلا Role "مدیرارشد" دارای مجوز های A و B و C و D و E هستش
و Role "مدیر" دارای مجوزهای C و D و E
زمانی که مثلا میخوام یک کاربر ثبت نام کنم میتونم دو نقش مدیر و مدیر ارشد رو بهش بدم در صورتی که مجوزهای مشترکی بینشون هست . میخواستم بدونم دقیقا اصول این طراحی بر چه اساسه. آیا نیاز است این اجازه رو به کاربرا بدیم که به کاربرتعریف شده توسط خودشان چند Role اختصاص بدن ؟
ممنون میشم اگر یک خورده در این مورد توضیح بدید
تنظیمات پایه و گزارشات
در پروژهی iOS، در فایل AppDelegate.cs، بعد از Forms.Init، کد زیر را کپی کنید:
SfListViewRenderer.Init();
همین کد را در MainPage.xaml.cs در پروژه UWP، قبل از LoadApplication قرار دهید. نیازی به انجام کاری در Android نیست.
سپس Product Key این محصول را به دست آورده و در پروژه XamApp، فولدر Views در فایل SyncfusionLicense قرار دهید.
حال برای نمایش لیستی از محصولات، ابتدا کلاس Product را ایجاد میکنیم. چه در زمانیکه یک Rest api را در سمت سرور فراخوانی میکنیم و چه زمانیکه با دیتابیس بر روی گوشی یعنی Sqlite کار میکنیم، در نهایت لیستی از یک کلاس را داریم (در اینجا Product).
public class Product : Bindable { public int Id { get; set; } public string Name { get; set; } public bool IsActive { get; set; } public decimal Price { get; set; } }
در یک View Model جدید با نام ProductsViewModel، در OnNavigatedToAsync، دیتا را از سرور یا دیتابیس، بر روی گوشی دریافت میکنیم؛ اما در این مثال، برای راحتی بیشتر یک List را New میکنیم:
public class ProductsViewModel : BitViewModelBase { public List<Product> Products { get; set; } public async override Task OnNavigatedToAsync(INavigationParameters parameters) { Products = new List<Product> // getting products from server or sqlite database { new Product { Id = 1, IsActive = true, Name = "Product1" , Price = 12.2m /* m => decimal */ }, new Product { Id = 2, IsActive = false, Name = "Product2" , Price = 14 }, new Product { Id = 3, IsActive = true, Name = "Product3" , Price = 11 }, }; await base.OnNavigatedToAsync(parameters); } }
حال نوبت به دادن یک Template میرسد. مثلا فرض کنید میخواهیم نام را درون یک Label نمایش دهیم و بر اساس فعال یا غیر فعال بودن Product، یک Checkbox را تغییر داده، تیک بزنیم یا نزنیم و در نهایت نمایش قیمت را در یک Label دیگر خواهیم داشت.
<sfListView:SfListView ItemsSource="{Binding Products}"> <sfListView:SfListView.ItemTemplate> <DataTemplate> <FlexLayout x:DataType="model:Product" Direction="Row"> <Label FlexLayout.Basis="50%" Text="{Binding Name}" VerticalTextAlignment="Center" /> <bitControls:BitCheckbox InputTransparent="True" FlexLayout.Basis="25%" IsChecked="{Binding IsActive}" /> <Label FlexLayout.Basis="25%" Text="{Binding Price}" VerticalTextAlignment="Center" /> </FlexLayout> </DataTemplate> </sfListView:SfListView.ItemTemplate> </sfListView:SfListView>
همانطور که میبینید، در DataTemplate از Flex Layout استفاده شده است. Flex Layout در کنار Grid, Stack, Relative, Absolute و سایر Layoutهای Xamarin Forms در پروژه قابلیت استفاده دارد و مزیتهای خاص خود را دارد.
این Data Template توسط List View، حداکثر سه بار ساخته میشود؛ چون View Model در لیست مثال خود، سه Product دارد. خود List View تکنیکهای Virtualization و Cell Reuse را بدون نیاز به هیچ کد اضافهای هندل میکند و Performance خوبی دارد. در View مربوطه یعنی ProductsView.xaml، هر Binding ای (مثل Binding Products) به View Model اشاره میکند، اما درون Data Template، هر Binding به Product ای اشاره میکند که آن ردیف List View، دارد نمایشاش میدهد. برای همین x:DataType را روی Flex Layout درون Data Template به Product وصل کردهایم. در این صورت اگر بنویسیم Binding N_ame، به ما خطا داده میشود که کلاس Product هیچ Property با نام N_ame ندارد که خطای درستی است.
روی BitCheckbox مقدار InputTransparent را برابر با True دادهایم که باعث میشود کلیک روی Checkbox عملا در نظر گرفته نشود. این منطقی است، زیرا عوض کردن مقدار Checkbox در این مثال ما ذخیره نمیشود و کاربرد نمایشی دارد و فقط باعث گیج شدن کاربر میشود.
کنترل BitCheckbox از مجموعه کنترلهای Bit است که اخیرا با BitDatePicker آن آشنا شدهاید. برای آشنایی با نحوه افزودن این کنترلها به یک پروژه، به مستندات Bit Framework مراجعه کنید. خود Syncfusion نیز Checkbox دارد.
حال فرض کنید که قرار است دکمهای برای هر ردیف List View داشته باشیم که با زدن روی آن، اطلاعات Product به سرور ارسال شود و جزئیات بیشتری دریافت و در قالب یک Alert نمایش داده شود. برای این کار، ابتدا به Data Template که Flex Layout است، یک دکمه اضافه میکنیم. سپس Command آن دکمه را به View Model بایند میکنیم. در آن Command البته احتیاج داریم بدانیم درخواست نمایش جزئیات بیشتر، برای کدام Product داده شده. این مهم با Command Parameter شدنی است.
برای پیاده سازی این مثال، در سمت View Model داریم:
public BitDelegateCommand<Product> ShowProductDetailsCommand { get; set; }public IUserDialogs UserDialogs { get; set; } async Task ShowProductDetails(Product product) { string productDetail = $"Product: {product.Name}'s more info: ..."; // get more info from server. await UserDialogs.AlertAsync(productDetail, "Product Detail"); }
کامند ShowProductDetailCommand یک پارامتر را از جنس Product میگیرد و آن Product ای است که روی دکمه آن کلیک شدهاست. با Clone کردن آخرین نسخه XamApp و درخواست نمایش صفحهی Products در App.xaml.cs به صورت زیر و اجرای برنامه، میتوانید درک بهتری از عملکرد آن داشته باشید:
await NavigationService.NavigateAsync("/Nav/Products", animated: false);
سپس در View مربوطه داریم:
...<Button Command="{Binding ShowProductDetailsCommand}" CommandParameter="{Binding .}" Text="Detail..." /> </FlexLayout> </DataTemplate>
CommandParameter اگر برابر با Binding Id میبود، به Command در سمت View Model، بجای کل Product، فقط Id آن ارسال میشد. ولی Show Product Detail Command منتظر یک Product کامل است، نه فقط Id آن. با نوشتن
CommandParameter="{Binding .}"
کل Product با کلیک روی دکمه به Command ارسال میشود.
اکنون اگر پروژه را Build کنید، خطایی را از x:DataType خواهید گرفت که منطقی است. اگر Binding Name و Binding Price دو Property با نامهای Name و Price را از کلاس Product جستجو میکنند، پس قاعدتا ShowProductDetailCommand نیز در همان کلاس مدل، یعنی Product جستجو میشود! ولی میدانیم که این Command در View Model ما یعنی ProductsViewModel است. برای حل این مشکل، به جای Binding از bit:ViewModelBinding استفاده میکنیم:
Command="{bit:ViewModelBinding ShowProductDetailsCommand}"
در این صورت، بجای جستجو کردن ShowProductDetailCommand در کلاس Product، این را در ProductsViewModel جستجو میکند که منجر به خروجی درست میشود.
این List View دارای امکاناتی چون Infinite loading، Pull to refresh و Grouping-Sorting-Filtering و ... است که میتوانید از روی مستندات خوب Syncfusion، آنها را راه اندازی کنید و اگر به مشکلی برخوردید نیز اینجا بپرسید. همچنین نگاهی به لیست 129 کنترل دیگر بیاندازید و ببینید که در برنامههای خود از کدام یک از آنها میتوانید استفاده کنید.