با سلام. امکان دارد در مورد نحوه استخراج اطلاعات از این سرویس و نمایش در سایت کمی راهنمایی کنید؟ باتشکر.
مطالب
ASP.NET MVC #23
اجرای برنامههای ASP.NET MVC توسط نگارشهای متفاوت IIS
تا اینجا برای اجرای برنامههای ASP.NET MVC از وب سرور توکار VS.NET استفاده شد که صرفا جهت آزمایش برنامهها طراحی شده است. تا این تاریخ سه رده از وب سرورهای مایکروسافت ارائه شدهاند که برای نصب ASP.NET MVC میتوانند مورد استفاده قرار گیرند و هر کدام هم نکتههای خاص خودشان را دارند که در ادامه به بررسی آنها خواهیم پرداخت.
اجرای برنامههای ASP.NET MVC بر روی IIS 5.x ویندوز XP
پس از ایجاد یک دایرکتوری مجازی بر روی پوشه یک برنامه ASP.NET MVC و سعی در اجرای برنامه، بلافاصله پیغام خطای HTTP 403 forbidden مشاهده میشود.
اولین کاری که برای رفع این مساله باید صورت گیرد، کلیک راست بر روی نام دایرکتوری مجازی در کنسول IIS، انتخاب گزینه خواص و سپس مراجعه به برگه «ASP.NET» آن است. در اینجا شماره نگارش دات نت فریم ورک مورد استفاده را به 4 تغییر دهید (برای نمونه ASP.NET MVC 3.0 مبتنی بر دات نت فریم ورک 4 است).
بعد از این تغییر، بازهم موفق به اجرای برنامههای ASP.NET MVC بر روی IIS 5.x نخواهیم شد؛ چون در آن زمان مفاهیم مسیریابی و Routing که اصل و پایه ASP.NET MVC هستند وجود خارجی نداشتند. این نگارش از IIS به صورت پیش فرض تنها قادر به پردازش درخواستهای رسیدهای که به یک فایل فیزیکی بر روی سرور اشاره میکند، میباشد (یعنی مشکلی با اجرای برنامههای ASP.NET Web forms ندارد).
برای رفع این مشکل، مجددا بر روی نام دایرکتوری مجازی برنامه در کنسول IIS کلیک راست کرده و گزینه خواص را انتخاب کنید. در صفحه ظاهر شده، در برگه «Virtual directory» آن، بر روی دکمه «Configuration» کلیک نمائید. در صفحه باز شده مجددا بر روی دکمه «Add» کلیک کنید.
در صفحه باز شده، مسیر Executable را C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll وارد کرده و Extension را به .* (دات هرچی) تنظیم کنید. همین مقدار تنظیم، برای اجرای برنامههای ASP.NET MVC بر روی IIS 5.x ویندوز XP کفایت میکند.
کاری که در اینجا انجام شده است، نگاشت تمام درخواستهای رسیده صرفنظر از پسوند فایلها، به موتور ASP.NET میباشد. به صورت پیش فرض در IIS 5.x درخواستها تنها بر اساس پسوند فایلها پردازش میشوند. مثلا اگر فایل درخواستی aspx است، درخواست رسیده به aspnet_isapi.dll یاد شده هدایت خواهد شد. اگر پسوند فایل php است به isapi مخصوص آن (در صورت نصب) هدایت میگردد و به همین ترتیب برای سایر سیستمهای دیگر. زمانیکه Extension به «دات هرچی» و Executable به aspnet_isapi.dll دات نت 4 تنظیم میشود، دایرکتوری مجازی تنظیم شده تنها جهت سرویس دهی به یک برنامه ASP.NET عمل خواهد کرد و تمام درخواستهای رسیده به آن، به موتور اجرایی ASP.NET هدایت میشوند.
بدیهی است تنظیمات فوق تنها به یک دایرکتوری مجازی اعمال شدند. اگر نیاز باشد تا بر روی تمام سایتها تاثیر گذار شود، اینبار در کنسول IIS 5.x بر روی «Default web site» کلیک راست کرده و گزینه خواص را انتخاب کنید. در صفحه باز شده به برگه «Home directory» مراجعه کرده و مراحل ذکر شده را تکرار کنید.
مشکل! این روش بهینه نیست.
روش فوق خوبه، کار میکنه، اما بهینه نیست؛ از این جهت که «نگاشت تمام درخواستها به موتور ASP.NET» یعنی پروسه پردازش درخواست یک فایل تصویری، js یا css هم باید از فیلتر موتور ASP.NET عبور کند که ضروری نیست.
برای رفع این مشکل، توصیه شده است که سیستم مسیریابی ASP.NET MVC را در IIS 5.x «پسوند دار» کنید. به این نحو که با مراجعه به فایل Global.asax.cs، تعاریف مسیریابی را به نحو زیر ویرایش کنید:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.Add(
new Route("{controller}.aspx/{action}/{id}", new MvcRouteHandler())
{
Defaults = new RouteValueDictionary(new
{
controller = "Home",
action = "Index",
id = UrlParameter.Optional
})
});
اینبار برای مثال مسیر http://localhost/MyMvcApp/home.aspx/index به علت داشتن پسوند aspx وارد موتور پردازشی ASP.NET خواهد شد. البته در این حالت URL های تمیز ASP.NET MVC را از دست خواهیم داد و مدام باید دقت داشت که مسیرهای کنترلرها حتما باید به aspx ختم شوند. ضمنا با این تنظیم، دیگر نیازی به تغییر تعاریف نگاشتها در کنسول مدیریتی IIS، نخواهد بود.
اجرای برنامههای ASP.NET MVC بر روی IIS 6.x ویندوز سرور 2003
تمام نکات عنوان شده جهت IIS 5.x در IIS 6.x نیز صادق هستند. به علاوه برای اجرای برنامههای ASP.NET بر روی IIS 6.x باید به دو نکته مهم دیگر نیز دقت داشت:
الف) ASP.NET 4 به صورت پیش فرض در IIS 6.x غیرفعال است که باید با مراجعه به قسمت Web Services Extensions در کنسول مدیریتی IIS، آنرا از حالت prohibited خارج کرد.
ب) در هر Application pool تنها از یک نگارش دات نت فریم ورک میتوان استفاده کرد. برای مثال اگر هم اکنون AppPool1 مشغول سرویس دهی به یک سایت ASP.NET 3.5 است، از آن نمیتوانید جهت اجرای برنامههای ASP.NET MVC 3 به بعد استفاده کنید. زیرا برای مثال ASP.NET MVC 3 مبتنی بر دات نت فریم ورک 4 است. به همین جهت حتما نیاز است تا یک Application pool مجزا را برای برنامههای دات نت 4 در IIS 6 اضافه نمائید و سپس در تنظیمات سایت، از این Application pool جدید استفاده نمائید.
البته روش صحیح و اصولی کار با IIS از نگارش 6 به بعد هم مطابق شرحی است که عنوان شد. برای دستیابی به بهترین کارآیی و امنیت بیشتر، بهتر است به ازای هر سایت، از یک Application pool مجزا استفاده نمائید.
اطلاعات تکمیلی:
نکات نصب برنامههای ASP.NET 4.0 بر روی IIS 6
مروری بر تاریخچه محدودیت حافظه مصرفی برنامههای ASP.NET در IIS
اجرای برنامههای ASP.NET MVC بر روی IIS 7.x ویندوز 7 و ویندوز سرور 2008
اگر برنامه ASP.NET MVC در IIS 7.x در حالت یکپارچه (integrated mode) اجرا شود، بدون نیاز به هیچگونه تغییری در تنظیمات سرور یا برنامه، بدون مشکل قابل اجرا خواهد بود. بدیهی است در اینجا نیز بهتر است به ازای هر برنامه، یک Application pool مجزا را ایجاد کرد.
اما در حالت classic (که برای برنامههای جدید توصیه نمیشود) نیاز است همان مراحل IIS 5,x تکرار شود. البته اینبار مسیر زیر را باید طی کرد تا به صفحه افزودن نگاشتها رسید:
Right-click on a web site -> Properties -> Home Directory tab -> click on the Configuration button -> Mappings tab
نکتهای مهم در تمام نگارشهای IIS
ترتیب نصب دات نت فریم ورک 4 و IIS مهم است. اگر ابتدا IIS نصب شود و سپس دات نت فریم ورک 4، به صورت خودکار، کار نگاشت اطلاعات ASP.NET به IIS صورت خواهد گرفت.
اگر ابتدا دات نت فریم ورک 4 نصب شود و سپس IIS، برای مثال دیگر از برگه ASP.NET در IIS 6.x خبری نخواهد بود. برای رفع این مشکل دستور زیر را در خط فرمان اجرا کنید:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe /i
به این ترتیب، اطلاعات مرتبط با موتور ASP.NET مجددا به تنظیمات IIS اضافه خواهند شد.
نظرات اشتراکها
دریافت خروجی کامل NET Tips. با فرمت EPub
جهت اطلاع: خروجی CHM هم اضافه شد.
یک نکته: فایلهای CHM دریافتی از طریق مرورگرها، به صورت پیشفرض قابل نمایش نیستند. باید بر روی آنها کلیک راست کنید و سپس در برگهی خواص فایل، بر روی دکمهی unblock آن فایل کلیک کنید تا قابل استفاده شود.
IIS6 فایلهایی را که نشناسد، سرو نخواهد کرد. بنابراین اگر یکی از کاربران مثلا یک فایل docx آفیس 2007 را آپلود کرده باشد، به محض کلیک بر روی لینک دریافت فایل، با خطای زیر متوقف خواهد شد:
HTTP Error 404 - File or directory not found
فایل بر روی سرور موجود است اما کاربر قادر به دریافت آن نیست.
برای شناساندن فرمتهای جدید به IIS6 میتوان به یکی از دو روش زیر عمل کرد:
الف) اضافه کردن mime-type جدید از طریق کنسول IIS
ب) ویرایش کردن فایل MetaBase.xml مربوط به IIS
در هر دو روش فوق نیاز است تا با mime-type فایلهای جدید آشنا بود. برای مثال لیست کامل mime-types مربوط به فایلهای آفیس 2007 به صورت زیر است:
.docm,application/vnd.ms-word.document.macroEnabled.12
.docx,application/vnd.openxmlformats-officedocument.wordprocessingml.document
.dotm,application/vnd.ms-word.template.macroEnabled.12
.dotx,application/vnd.openxmlformats-officedocument.wordprocessingml.template
.potm,application/vnd.ms-powerpoint.template.macroEnabled.12
.potx,application/vnd.openxmlformats-officedocument.presentationml.template
.ppam,application/vnd.ms-powerpoint.addin.macroEnabled.12
.ppsm,application/vnd.ms-powerpoint.slideshow.macroEnabled.12
.ppsx,application/vnd.openxmlformats-officedocument.presentationml.slideshow
.pptm,application/vnd.ms-powerpoint.presentation.macroEnabled.12
.pptx,application/vnd.openxmlformats-officedocument.presentationml.presentation
.xlam,application/vnd.ms-excel.addin.macroEnabled.12
.xlsb,application/vnd.ms-excel.sheet.binary.macroEnabled.12
.xlsm,application/vnd.ms-excel.sheet.macroEnabled.12
.xlsx,application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xltm,application/vnd.ms-excel.template.macroEnabled.12
.xltx,application/vnd.openxmlformats-officedocument.spreadsheetml.template
روش ب)
ابتدا IIS6 را stop کنید (در غیر اینصورت قادر به ذخیره سازی تغییرات نخواهید بود):
iisreset /stop
C:\WINDOWS\system32\inetsrv\MetaBase.xml
تگ مربوط به IIsMimeMap را یافته و خطوط فوق را دقیقا به همین صورتیکه ملاحظه میکنید به آن اضافه نمائید.
و در آخر IIS را راه اندازی کنید:
iisreset /start
روش الف)
این روش نیازی به stop و start وب سرور ندارد و به محض اضافه شدن، به صورت خودکار اعمال خواهد شد اما کمی طولانیتر است:
کنسول IIS را باز کنید
بر روی web sites کلیک راست کنید. (منظور بالاترین سطح ممکن است)
گزینه properties را انتخاب کرده و سپس به برگه http headers مراجعه نمائید.
در اینجا بر روی دکمه mime-types کلیک کرده و در صفحه باز شده باید تک تک موارد جدید را به صورت دستی وارد نمائید (در اینجا نیازی به ذکر نقطه مربوط به پسوند فایل نیست)
لازم به ذکر است که این نوع mime-types به IIS7 اضافه شدهاند.
برای بسیاری از تازه کاران که پا به عرصهی برنامههای تحت وب میگذارند، اینکه چگونه، از کجا و چطور باید هاستی را انتخاب کنند، دچار سردرگمی هستند. دیدن پلنهای مختلف با قیمتهای مختلف، باعث افزایش سردرگمی آنها میشود. در این مقاله به بررسی اینکه چطور باید هاستی خریداری شود و اینکه اصلا خود برنامهی نوشته شده نیازش چقدر هست، صحبت میکنیم.
قبل از اینکه صحبت را آغاز کنیم باید این نکته اشاره کنیم که انواع هاست چیست؟
انواع هاست
هاستها بر سه نوع تقسیم میشوند:
هاست اشتراکی
در این حالت شرکت میزبان یک سرور را به چند سایت تقسیم کرده و به هر وب سایت، با توجه به پلنی که مشتری انتخاب کرده، مقداری از منابع را اختصاص میدهد که عموما این تخصیص منابع در زمان خرید توسط WHMCS به طور خودکار صورت میگیرد. در این حالت ممکن است بر روی یک سرور بیش از یکصد وب سایت در حال سرویس گرفتن باشند. مزیت این هاستها قیمت ارزان آنها میباشد . عموما وب سایتهای با بازدید کم و نیاز به منابع کمتر، از این دست هاستها استفاده میکنند. در این نوع هاستها در صورتیکه استفادهی از منابع به نهایت مقداری که برای آن مشخص شده است برسد، از قبیل ترافیک (که بیشتر مسئله مربوط به آن است) یا دیسک سخت و ... به حد مشخص شده برسند، سایت را متوقف یا suspend میکنند. پرداخت این نوع هاستها به خاطر قیمت پایین به صورت یکساله دریافت میشود. قیمست سالیانه آنها در بعضی جاها از 50 هزار تومان تا صدهزار تومان به عنوان مبلغ آغازین شروع میشود.
سرورهای مجازی VPS یا Virtual Private Server
اینها هم تقریبا مثل هاستهای اشتراکی هستند با این تفاوت که منابع بیشتر و دسترسی بیشتری به شما داده میشوند؛ به طوری که احساس میکنید به شما یک سرور واقعی را دادهاند و عموما تعداد سایت هایی که روی آن سرویس میگیرند، به مراتب کمتر از هاست اشتراکی است. اکثر وب سایتهایی که توانایی استفاده از هاستهای اشتراکی را ندارند، از این نوع هاستینگ بهره میبرند. قیمتش بالاتر از یک هاست اشتراکی است ولی به مراتب پایینتر از یک سرور اختصاصی است. پرداخت این نوع هاست عموما به دو صورت ماهیانه و یا سالانه است که احتمال زیادی دارد پرداخت سالیانه تخفیف خوبی را شامل شود. در صورت رسیدن به حد نهایت منابع همانند هاست اشتراکی با شما رفتار خواهد شد. این سرورهای مجازی در ایران عموما از مبلغ ماهیانه 20 هزار تومان به بالا آغاز میشوند.
سروهای اختصاصی یا Dedicate
اینها دیگر سروهای واقعی هستند و صاحب اول و آخرشان شمایید و دسترسی کامل به همه اجزا و منابع آن را دارید. این سرورهای عموما برای فعالیتهای بزرگ تجاری و بازدیدهای همزمان به شدت بالا استفاده میشوند. قیمت، بسته به مشخصات آن متفاوت است و ممکن است یکی ماهیانه 200 هزار تومان، یکی ماهیانه 500 هزار تومان و .. آغاز شود.
سرورهای ابری
اگر قصد انجام عملیات رایانش برای را دارید بهتر هست که دنبال چنین سرورهایی باشید که مورد بحث این مقاله نیست و صرفا جهت تکمیل معرفی انواع هاستها آمده است.
قبل از اینکه صحبت را آغاز کنیم باید این نکته اشاره کنیم که انواع هاست چیست؟
انواع هاست
هاستها بر سه نوع تقسیم میشوند:
- هاست اشتراکی
- سرورهای مجازی
- سرور اختصاصی
هاست اشتراکی
در این حالت شرکت میزبان یک سرور را به چند سایت تقسیم کرده و به هر وب سایت، با توجه به پلنی که مشتری انتخاب کرده، مقداری از منابع را اختصاص میدهد که عموما این تخصیص منابع در زمان خرید توسط 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 هایی چون وردپرس و جوملا و ... هستند.
اگر از یک سرور اختصاصی بهره ببرید خودتان مختار نصب هر نوع چیزی روی آن هستید و در مورد کنترل پنل هم صدق میکند ولی عموما شرکتها یک سری الگوهای پیش فرضی را برای سرویسهای خود دارند که در صورت تغییر باید به آنها، تغییرات را طلاع دهید.
فضای دیسک و پهنای باند (ترافیک)
اولین نکاتی که همیشه توسط میزبانها و خریداران مورد توجه قرار میگیرند، این دو مورد هست. در صورتیکه سایت شما اجازه آپلودی به کاربران نمیدهد، یا خودتان هم آپلود چندانی ندارید، میتوانید فضای دیسک سخت پایینتری را انتخاب کنید. مثلا اگر شما تعدادی تصویر دارید و مقدار زیادی فایل متنی و ... به نظر یک گیگ کفایت میکند و در صورتیکه بعدها دیدید این فضا رو به اتمام است، میتوانید به میزبان درخواست افزایش و ارتقاء آن را بدهید؛ اما برای بار اول یک گیگ به خوبی کفایت میکند. ولی اگر چنانچه با فایلهای حجیم سرو کله میزنید و یا تعداد فایلهایی چون تصاویر، صوت و ویدیو در آن زیاد دیده میشود، بهتر است به فکر فضایی بیشتر و حتی گاها 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 ندارند که این کار را انجام دهند و این مورد به شما محول میشود، در قرارداد ذکر شود که شما هیچ گونه مسئولیتی در قبال مشکلاتی که برای هاست و دامنه رخ میدهد ندارید و تنها میتوانید به عنوان یک واسط یا وکیل در ازای مبلغ توافق شدهای مشکل را با مسئولین هاست و دامنه در میان گذاشته و ماجرا را برای حل مشکل ایجاد شده دنبال کنید یا این کار را به عنوان هدیه ای از طرف خدمات طلایی شما به مشتریان به صورت رایگان انجام دهید.
موردی را تصور کنید که ساعت 2 شب هست و سایت شما هم که در زمینهی مهم و حساسی فعالیت میکند، یک دفعه سرویس آن قطع میشود و برای سرور مشکلی پیش میآید. در این موقع چکاری را انجام میدهید؟ صبر میکنید تا صبح شود و سرویس شما راه بیفتد و کاربران هم از سایت شما نا امید شوند؟ اگر این مشکل به دفعات رخ بدهد چه؟ اگر چند روز پشت سرهم تعطیلی باشد چه؟
همهی این موارد مربوط به پشتیبانی میشود. این پشتیبانیها عموما به صورت چت و تلفنی (بیشتر مربوط به ساعات اداری) و ارسال تیکت در سامانه پشتیبانی میشود. البته تجربهی من میگوید در ایران زیاد به متون نوشتهی روی سایت میزبان توجهی نکنید و این را هم به موضوع تحقیق خود اضافه کنید. بعضیها میگویند 24 ساعته پشتیبانی تلفنی دارند ولی هر بار زنگ میزنی کسی پاسخی نمیدهد. یا تیکت میزنید و بارها و بارها پشت سر هم تیکت "چی شد؟" را برای جویا شدن ارسال میکنید. (البته انصاف هم داشته باشید و پنج دقیقه پنج دقیقه این تیکت را نفرستید).
پشتیبانی هر نوع سرور را مطلع شوید. بعضیها واقعا پشتیبانی دارند!؟ ولی وقتی زنگ میزنید میگویند این پشتیبانی مربوط به لینوکس است و بچههای ویندوز فقط ساعات اداری هستند. خلاصه حواستان را جمع کنید که بچههای آن بخش همیشه باشند.
بنابراین مطمئن شوید که یک پشتیبانی 24/7 واقعی داشته باشند.
امکانات اضافه
در کنار خود هاست یک سری ویژگیهایی چون FTP و تعدادی دامنههای پشتیبانی شده و زیر دامنهها و تعداد دیتابیسها و ایمیل و ... هم هستند که در قدیم یادم هست محدودیتهایی در این رابطه ایجاد کرده بودند که امروزه از این نظر در اکثر هاستها آن طور که دیدم این محدودیتها رفع شده است که البته خیلی هم خوب هست و این محدودیتها بیشتر شبیه سودجویی بود تا چیز دیگر.
هزینه
با همهی حرفهای بالا به نظر میرسد که هزینه، همه این معادلات را به هم میریزد. هاستینگهای مختلف و قیمتهای مختلف، تصمیم گیرنده شما هستید که چقدر به عوامل بالا اهمیت میدهید و چگونه آنها را در راستای قیمت اولویت بندی میکنید. اگر محدودیتی ندارید سعی کنید همهی عوامل را بررسی کنید. نکته اینکه اکثر هاستها طرحی به نام ضمانت برگشت پول را در هفت روز یا گاها یک ماه، دارند و در صورتیکه از سرویس خریداری شده راضی نبودید میتوانید پول خود را پس گرفته و سرویس معلق شود.
کل مطالب گفته شده در چک لیست به طور خلاصه : اول از همه بررسی فضای ذخیره سازی و پهنای باند، بعد از آن بررسی توانایی سرویس دهی و سرعت سرورها، داشتن محیط امن و پشتیبانی مناسب بود.
هاستینگ در قرارداد
هنگام عقد قرارداد با مشتری، در قرارداد در مورد هاستینگ که خودش تهیه میکند، این نکته ذکر شود که شما در مورد مسائلی که مربوط به هاست و دامنه میشود هیچ مسئولیتی ندارید و باید مشکلات را با مسئولان آن در میان بگذارد.
همچنین این نکته هم ذکر شود در مورد مسائلی چون عدم پشتیبانی مناسب هاست، از محصول یا سرویس شما، شما هیچگونه مسئولیتی در قبال آن ندارید و یا باید این مورد توسط شما دنبال شود یا خرید ایشان با مشاوره و تایید شما از هاست مربوطه باشد.
در صورتی که مشتری نمیتواند شخصا خرید هاستینگ را انجام دهد یا در شرکت مسئولین IT ندارند که این کار را انجام دهند و این مورد به شما محول میشود، در قرارداد ذکر شود که شما هیچ گونه مسئولیتی در قبال مشکلاتی که برای هاست و دامنه رخ میدهد ندارید و تنها میتوانید به عنوان یک واسط یا وکیل در ازای مبلغ توافق شدهای مشکل را با مسئولین هاست و دامنه در میان گذاشته و ماجرا را برای حل مشکل ایجاد شده دنبال کنید یا این کار را به عنوان هدیه ای از طرف خدمات طلایی شما به مشتریان به صورت رایگان انجام دهید.
پیشنیازها:
چگونه با استفاده از لوسین مطالب را ایندکس کنیم؟
چگونه از افزونه jQuery Auto-Complete استفاده کنیم؟
نحوه استفاده صحیح از لوسین در ASP.NET
اگر به جستجوی سایت دقت کرده باشید، قابلیت ارائه پیشنهاداتی به کاربر توسط یک Auto-Complete به آن اضافه شدهاست. در مطلب جاری به بررسی این مورد به همراه دو مثال Web forms و MVC پرداخته خواهد شد.
قسمت عمده مطلب جاری با پیشنیازهای یاد شده فوق یکی است. در اینجا فقط به ذکر تفاوتها بسنده خواهد شد.
الف) دریافت لوسین
از طریق NuGet آخرین نگارش را دریافت و به پروژه خود اضافه کنید. همچنین Lucene.NET Contrib را نیز به همین نحو دریافت نمائید.
ب) ایجاد ایندکس
کدهای این قسمت با مطلب برجسته سازی قسمتهای جستجو شده، یکی است:
تنها تفاوت آن اضافه شدن titleField.Boost = 3 میباشد. توسط Boost به لوسین خواهیم گفت که اهمیت عبارات ذکر شده در عناوین مطالب، بیشتر است از اهمیت متون آنها.
ج) تهیه قسمت منبع داده Auto-Complete
توضیحات:
برای نمایش Auto-Complete نیاز به منبع داده داریم که نحوه ایجاد آنرا در کدهای فوق ملاحظه میکنید. در اینجا توسط جستجوی سریع لوسین و امکانات PrefixQuery آن، به تعدادی مشخص (maxItems)، رکوردهای یافت شده را بازگشت خواهیم داد. خروجی حاصل لیستی است از SearchResultها شامل عنوان مطلب و Id آن. عنوان را به کاربر نمایش خواهیم داد؛ از Id برای هدایت او به مطلبی مشخص استفاده خواهیم کرد.
د) نمایش Auto-Complete در ASP.NET MVC
توضیحات:
- ابتدا ارجاعاتی را به jQuery، افزونه Auto-Complete و اسکریپت سفارشی تهیه شده، در فایل layout پروژه تعریف خواهیم کرد.
در اینجا سه قسمت را مشاهده میکنید: کدهای کنترلر، View متناظر و اسکریپتی که Auto-Complete را فعال خواهد ساخت.
- قسمت مهم کدهای کنترلر، دو سطر زیر هستند:
مطابق نیاز افزونه انتخاب شده در مثال جاری، فرمت خروجی مدنظر باید شامل سطرهایی حاوی متن قابل نمایش به همراه یک Id (یا در اینجا یک آدرس مشخص) باشد. البته ذکر این Id اختیاری بوده و در اینجا جهت تکمیل بحث ارائه شده است.
return Content هم سبب بازگشت این اطلاعات به افزونه خواهد شد.
- کدهای View متناظر بسیار ساده هستند. تنها نام TextBox تعریف شده مهم میباشد که در متد جاوا اسکریپتی EnableSearchAutocomplete استفاده شده است. به علاوه، نحوه مقدار دهی آدرس دسترسی به اکشن متد ScoredTerms نیز مهم میباشد.
- در متد EnableSearchAutocomplete نحوه فراخوانی افزونه autocomplete را ملاحظه میکنید.
جهت آن، به راست به چپ تنظیم شده است. با 2 کاراکتر ورودی فعال خواهد شد با وقفهای کوتاه. نیازی نیست تا انتخاب کاربر از لیست ظاهر شده حتما با عبارت جستجو شده صد در صد یکی باشد. حداکثر 20 آیتم در لیست ظاهر خواهند شد. اسکرول بار لیست را حذف کردهایم. عرض آن به 300 تنظیم شده است و نحوه فرمت دهی نمایشی آنرا نیز ملاحظه میکنید. برای این منظور از متد formatItem استفاده شده است. آرایه row در اینجا در برگیرنده اعضای Title و Id ارسالی به افزونه است. اندیس صفر آن به عنوان دریافتی اشاره میکند.
همچنین نحوه نشان دادن عکس العمل به عنصر انتخابی را هم ملاحظه میکنید (در متد result مقدار دهی شده). window.location را به عنصر دوم آرایه row هدایت خواهیم کرد. این عنصر دوم مطابق کدهای اکشن متد تهیه شده، به آدرس یک صفحه اشاره میکند.
ه) نمایش Auto-Complete در ASP.NET WebForms
قسمت عمده مطالب فوق با وب فرمها نیز یکی است. خصوصا توضیحات مرتبط با متد EnableSearchAutocomplete ذکر شده.
در اینجا بجای Controller از یک Generic handler استفاده شده است (Search.ashx).
در آن، عنوان مطالب یافت شده به همراه یک آدرس مشخص، تهیه و در Response نوشته خواهند شد.
کدهای کامل مثال فوق را از اینجا میتوانید دریافت کنید:
همچنین باید دقت داشت که پروژه MVC آن از نوع MVC4 است (VS2010) و فرض براین میباشد که IIS Express 7.5 را نیز پیشتر نصب کردهاید.
کلمه عبور فایل: dotnettips91
چگونه با استفاده از لوسین مطالب را ایندکس کنیم؟
چگونه از افزونه jQuery Auto-Complete استفاده کنیم؟
نحوه استفاده صحیح از لوسین در ASP.NET
اگر به جستجوی سایت دقت کرده باشید، قابلیت ارائه پیشنهاداتی به کاربر توسط یک Auto-Complete به آن اضافه شدهاست. در مطلب جاری به بررسی این مورد به همراه دو مثال Web forms و MVC پرداخته خواهد شد.
قسمت عمده مطلب جاری با پیشنیازهای یاد شده فوق یکی است. در اینجا فقط به ذکر تفاوتها بسنده خواهد شد.
الف) دریافت لوسین
از طریق NuGet آخرین نگارش را دریافت و به پروژه خود اضافه کنید. همچنین Lucene.NET Contrib را نیز به همین نحو دریافت نمائید.
ب) ایجاد ایندکس
کدهای این قسمت با مطلب برجسته سازی قسمتهای جستجو شده، یکی است:
using System.Collections.Generic; using System.IO; using Lucene.Net.Analysis.Standard; using Lucene.Net.Documents; using Lucene.Net.Index; using Lucene.Net.Store; using LuceneSearch.Core.Model; using LuceneSearch.Core.Utils; namespace LuceneSearch.Core { public static class CreateIndex { static readonly Lucene.Net.Util.Version _version = Lucene.Net.Util.Version.LUCENE_30; public static Document MapPostToDocument(Post post) { var postDocument = new Document(); postDocument.Add(new Field("Id", post.Id.ToString(), Field.Store.YES, Field.Index.NOT_ANALYZED)); var titleField = new Field("Title", post.Title, Field.Store.YES, Field.Index.ANALYZED, Field.TermVector.WITH_POSITIONS_OFFSETS); titleField.Boost = 3; postDocument.Add(titleField); postDocument.Add(new Field("Body", post.Body.RemoveHtmlTags(), Field.Store.YES, Field.Index.ANALYZED, Field.TermVector.WITH_POSITIONS_OFFSETS)); return postDocument; } public static void CreateFullTextIndex(IEnumerable<Post> dataList, string path) { var directory = FSDirectory.Open(new DirectoryInfo(path)); var analyzer = new StandardAnalyzer(_version); using (var writer = new IndexWriter(directory, analyzer, create: true, mfl: IndexWriter.MaxFieldLength.UNLIMITED)) { foreach (var post in dataList) { writer.AddDocument(MapPostToDocument(post)); } writer.Optimize(); writer.Commit(); writer.Close(); directory.Close(); } } } }
ج) تهیه قسمت منبع داده Auto-Complete
namespace LuceneSearch.Core.Model { public class SearchResult { public int Id { set; get; } public string Title { set; get; } } }
using System.Collections.Generic; using System.IO; using Lucene.Net.Index; using Lucene.Net.Search; using Lucene.Net.Store; using LuceneSearch.Core.Model; using LuceneSearch.Core.Utils; namespace LuceneSearch.Core { public static class AutoComplete { private static IndexSearcher _searcher; /// <summary> /// Get terms starting with the given prefix /// </summary> /// <param name="prefix"></param> /// <param name="maxItems"></param> /// <returns></returns> public static IList<SearchResult> GetTermsScored(string indexPath, string prefix, int maxItems = 10) { if (_searcher == null) _searcher = new IndexSearcher(FSDirectory.Open(new DirectoryInfo(indexPath)), true); var resultsList = new List<SearchResult>(); if (string.IsNullOrWhiteSpace(prefix)) return resultsList; prefix = prefix.ApplyCorrectYeKe(); var results = _searcher.Search(new PrefixQuery(new Term("Title", prefix)), null, maxItems); if (results.TotalHits == 0) { results = _searcher.Search(new PrefixQuery(new Term("Body", prefix)), null, maxItems); } foreach (var doc in results.ScoreDocs) { resultsList.Add(new SearchResult { Title = _searcher.Doc(doc.Doc).Get("Title"), Id = int.Parse(_searcher.Doc(doc.Doc).Get("Id")) }); } return resultsList; } } }
برای نمایش Auto-Complete نیاز به منبع داده داریم که نحوه ایجاد آنرا در کدهای فوق ملاحظه میکنید. در اینجا توسط جستجوی سریع لوسین و امکانات PrefixQuery آن، به تعدادی مشخص (maxItems)، رکوردهای یافت شده را بازگشت خواهیم داد. خروجی حاصل لیستی است از SearchResultها شامل عنوان مطلب و Id آن. عنوان را به کاربر نمایش خواهیم داد؛ از Id برای هدایت او به مطلبی مشخص استفاده خواهیم کرد.
د) نمایش Auto-Complete در ASP.NET MVC
using System.Text; using System.Web.Mvc; using LuceneSearch.Core; using System.Web; namespace LuceneSearch.Controllers { public class HomeController : Controller { static string _indexPath = HttpRuntime.AppDomainAppPath + @"App_Data\idx"; public ActionResult Index(int? id) { if (id.HasValue) { //todo: do something } return View(); //Show the page } public virtual ActionResult ScoredTerms(string q) { if (string.IsNullOrWhiteSpace(q)) return Content(string.Empty); var result = new StringBuilder(); var items = AutoComplete.GetTermsScored(_indexPath, q); foreach (var item in items) { var postUrl = this.Url.Action(actionName: "Index", controllerName: "Home", routeValues: new { id = item.Id }, protocol: "http"); result.AppendLine(item.Title + "|" + postUrl); } return Content(result.ToString()); } } }
@{ ViewBag.Title = "جستجو"; var scoredTermsUrl = Url.Action(actionName: "ScoredTerms", controllerName: "Home"); var bulletImage = Url.Content("~/Content/Images/bullet_shape.png"); } <h2> جستجو</h2> <div align="center"> @Html.TextBox("term", "", htmlAttributes: new { dir = "ltr" }) <br /> جهت آزمایش lu را وارد نمائید </div> @section scripts { <script type="text/javascript"> EnableSearchAutocomplete('@scoredTermsUrl', '@bulletImage'); </script> }
function EnableSearchAutocomplete(url, img) { var formatItem = function (row) { if (!row) return ""; return "<img src='" + img + "' /> " + row[0]; } $(document).ready(function () { $("#term").autocomplete(url, { dir: 'rtl', minChars: 2, delay: 5, mustMatch: false, max: 20, autoFill: false, matchContains: false, scroll: false, width: 300, formatItem: formatItem }).result(function (evt, row, formatted) { if (!row) return; window.location = row[1]; }); }); }
- ابتدا ارجاعاتی را به jQuery، افزونه Auto-Complete و اسکریپت سفارشی تهیه شده، در فایل layout پروژه تعریف خواهیم کرد.
در اینجا سه قسمت را مشاهده میکنید: کدهای کنترلر، View متناظر و اسکریپتی که Auto-Complete را فعال خواهد ساخت.
- قسمت مهم کدهای کنترلر، دو سطر زیر هستند:
result.AppendLine(item.Title + "|" + postUrl); return Content(result.ToString());
return Content هم سبب بازگشت این اطلاعات به افزونه خواهد شد.
- کدهای View متناظر بسیار ساده هستند. تنها نام TextBox تعریف شده مهم میباشد که در متد جاوا اسکریپتی EnableSearchAutocomplete استفاده شده است. به علاوه، نحوه مقدار دهی آدرس دسترسی به اکشن متد ScoredTerms نیز مهم میباشد.
- در متد EnableSearchAutocomplete نحوه فراخوانی افزونه autocomplete را ملاحظه میکنید.
جهت آن، به راست به چپ تنظیم شده است. با 2 کاراکتر ورودی فعال خواهد شد با وقفهای کوتاه. نیازی نیست تا انتخاب کاربر از لیست ظاهر شده حتما با عبارت جستجو شده صد در صد یکی باشد. حداکثر 20 آیتم در لیست ظاهر خواهند شد. اسکرول بار لیست را حذف کردهایم. عرض آن به 300 تنظیم شده است و نحوه فرمت دهی نمایشی آنرا نیز ملاحظه میکنید. برای این منظور از متد formatItem استفاده شده است. آرایه row در اینجا در برگیرنده اعضای Title و Id ارسالی به افزونه است. اندیس صفر آن به عنوان دریافتی اشاره میکند.
همچنین نحوه نشان دادن عکس العمل به عنصر انتخابی را هم ملاحظه میکنید (در متد result مقدار دهی شده). window.location را به عنصر دوم آرایه row هدایت خواهیم کرد. این عنصر دوم مطابق کدهای اکشن متد تهیه شده، به آدرس یک صفحه اشاره میکند.
ه) نمایش Auto-Complete در ASP.NET WebForms
قسمت عمده مطالب فوق با وب فرمها نیز یکی است. خصوصا توضیحات مرتبط با متد EnableSearchAutocomplete ذکر شده.
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="LuceneSearch.WebForms.Default" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width" /> <title>جستجو</title> <link href="Content/Site.css" rel="stylesheet" type="text/css" /> <script src="Scripts/jquery-1.7.1.min.js" type="text/javascript"></script> <script src="Scripts/jquery.autocomplete.js" type="text/javascript"></script> <script src="Scripts/custom.js" type="text/javascript"></script> </head> <body dir="rtl"> <h2> جستجو</h2> <form id="form1" runat="server"> <div align="center"> <asp:TextBox runat="server" dir="ltr" ID="term"></asp:TextBox> <br /> جهت آزمایش lu را وارد نمائید </div> </form> <script type="text/javascript"> EnableSearchAutocomplete('Search.ashx', 'Content/Images/bullet_shape.png'); </script> </body> </html>
using System.Text; using System.Web; using LuceneSearch.Core; namespace LuceneSearch.WebForms { public class Search : IHttpHandler { static string _indexPath = HttpRuntime.AppDomainAppPath + @"App_Data\idx"; public void ProcessRequest(HttpContext context) { string q = context.Request.QueryString["q"]; if (string.IsNullOrWhiteSpace(q)) { context.Response.Write(string.Empty); context.Response.End(); } var result = new StringBuilder(); var items = AutoComplete.GetTermsScored(_indexPath, q); foreach (var item in items) { var postUrl = "Default.aspx?id=" + item.Id; result.AppendLine(item.Title + "|" + postUrl); } context.Response.ContentType = "text/plain"; context.Response.Write(result.ToString()); context.Response.End(); } public bool IsReusable { get { return false; } } } }
در اینجا بجای Controller از یک Generic handler استفاده شده است (Search.ashx).
result.AppendLine(item.Title + "|" + postUrl); context.Response.Write(result.ToString());
کدهای کامل مثال فوق را از اینجا میتوانید دریافت کنید:
همچنین باید دقت داشت که پروژه MVC آن از نوع MVC4 است (VS2010) و فرض براین میباشد که IIS Express 7.5 را نیز پیشتر نصب کردهاید.
کلمه عبور فایل: dotnettips91
سلام و ممنون از راهنماییهای خوبتان
کتابخانه اصلی Lib.AspNetCore.Mvc.JqGrid مربوط به پروژه Demo.AspNetCore.JqGrid رو با نسخه ASP.NET Core 3.1 به روز رسانی کردم و بعضی خطاهای Type Load Exception هم که در سورس فریمورک اصلی بود برطرف کردم. چون کدهای سورس اصلی فریمورک پروژه رو مجبور شدم تغییر بدم دیگه نشد که به صورت nuget Package به پروژه اضافه کنم برای همین سورس فریمورک اصلی رو در یک پوشه در کنار پروژه دمو که همه را به نسخه ASP.NET Core 3.1 به روز رسانی کردم گذاشتم. البته این نسخه با همان شیوه ای هست که در این لینک توضیح داده بودم و هم میشه با انواع بانکهای اطلاعاتی NoSQL استفاده کرد و هم با بانک اطلاعاتیهای رابطه ای از قبیل MS SQL Server.
ضمنا اون موارد خطا هم به خاطر همین exception داخلی Type Load Exception در فریمورک اصلی بود که پس از ارتقا به نسخه 3.1 برطرف شد.
ضمنا اون موارد خطا هم به خاطر همین exception داخلی Type Load Exception در فریمورک اصلی بود که پس از ارتقا به نسخه 3.1 برطرف شد.
دوستان از لینک زیر میتوانید نسخه بروز رسانی شده با ASP.NET Core 3.1 را استفاده نمایید.
Demo.JqGrid.core3.1.rar (6.25 MB)
در لینک هم همون نسخه دمو به همراه سورسهای فریمورک اصلی رو که تغییر دادم برای نویسنده اصلی فریمورک Lib.AspNetCore.Mvc.JqGrid در کامنت بارگزاری کردم تا فریمورک اصلی رو هم بروز رسانی کنند تا بعدا بشه به صورت nuget package استفاده کرد. البته توی اون نسخه کتابخانه JqGrid.Core که در نمونه مثال اینجا آپلود کردم نیست به این دلیل که نمونه مثال خودشون رو داشته باشند و باعث پیچیدگی کد برای ارتقای package نشه
سورس پروژه رو با این تغییرات در گیتهاب هم منتشر کردم
همان مثال backend قسمت 22 را با افزودن وب سرویسهایی برای قسمتهای نمایش لیست فیلمها، ژانرها و سایر صفحات اضافه شدهی به برنامهی تکمیل شدهی تا قسمت 21، توسعه میدهیم. کدهای کامل آن، به علت شباهت و یکی بودن نکات آن با مطلب 22، در اینجا تکرار نخواهند شد و میتوانید کل پروژهی آنرا از پیوست انتهای بحث دریافت کنید. سپس فایل dotnet_run.bat آنرا اجرا کنید تا در آدرس https://localhost:5001 قابل دسترسی شود.
افزودن سرویس httpService.js به برنامه
تا این قسمت، تمام اطلاعات نمایش داده شدهی در لیست فیلمها، از سرویس درون حافظهای src\services\fakeMovieService.js و لیست ژانرها از سرویس src\services\fakeGenreService.js، تامین میشوند. اکنون در ادامه میخواهیم این سرویسها را با سرویس backend یاد شده، جایگزین کنیم تا این برنامه، اطلاعات خودش را از سرور دریافت کند. به همین جهت قبل از هر کاری، سرویس عمومی src\services\httpService.js را که در قسمت قبل توسعه دادیم، به برنامهی نمایش لیست فیلمها نیز اضافه میکنیم (فایل آنرا از پروژهی قبلی کپی کرده و در اینجا paste میکنیم)، تا بتوانیم از امکانات آن در اینجا نیز استفاده کنیم. فایل httpService.js، دارای وابستگیهای خارجی react-toastify و axios است. به همین جهت برای افزودن آنها مراحل زیر را طی میکنیم:
- نصب کتابخانههای react-toastify و axios از طریق خط فرمان (با فشردن دکمههای ctrl+back-tick در VSCode):
سپس به فایل app.js مراجعه کرده و importهای لازم آنرا اضافه میکنیم:
همچنین نیاز است ToastContainer را به ابتدای متد render نیز اضافه کرد:
دریافت اطلاعات لیست نمایش ژانرها از سرویس backend
با فراخوانی آدرس https://localhost:5001/api/Genres، میتوان لیست ژانرهای سینمایی تعریف شدهی در سرویسهای backend را مشاهده کرد. اکنون قصد داریم از این اطلاعات، در برنامه استفاده کنیم. به همین جهت به فایل src\components\movies.jsx مراجعه کرده و تغییرات زیر را اعمال میکنیم:
چون نمیخواهیم تغییراتی بسیار اساسی را در اینجا اعمال کنیم، قدم به قدم عمل کرده و سرویس قبلی fakeGenreService.js را با یک سرویس جدید که اطلاعات خودش را از سرور دریافت میکند، جایگزین میکنیم. بنابراین ابتدا فایل جدید src\services\genreService.js را ایجاد میکنیم. سپس آنرا طوری تکمیل خواهیم کرد که اینترفیس آن، با اینترفیس fakeGenreService قبلی یکی باشد:
همچنین در اینجا import وابستگی config.json را نیز مشاهده میکنید که در قسمت قبل در مورد آن توضیح دادیم. به همین جهت برای تمیزتر شدن قسمتهای مختلف برنامه، فایل config.json را در مسیر src\config.json ایجاد کرده و به صورت زیر تکمیل میکنیم:
apiUrl به ریشهی URLهای ارائه شدهی توسط backend service ما، اشاره میکند.
پس از تکمیل سرویس جدید src\services\genreService.js، به فایل src\components\movies.jsx بازگشته و سطر قبلی
را با سطر جدید زیر، جایگزین میکنیم:
تا اینجا اگر برنامه را ذخیره کرده و اجرا کنید، خطای زیر را مشاهده خواهید کرد:
علت اینجا است که سرویس قبلی fakeGenreService، دارای متد export شدهای به نام getGenres بود که یک آرایهی معمولی را بازگشت میداد. اکنون این سرویس جدید نیز همان ساختار را دارد، اما اینبار یک Promise را بازگشت میدهد. به همین جهت متد componentDidMount را به صورت زیر اصلاح میکنیم:
متد getGenres باید await شود تا نتیجهی آن توسط خاصیت data شیء بازگشتی از آن، قابل دسترسی شود. با این تغییر، نیاز است این متد را نیز به صورت async معرفی کرد.
دریافت اطلاعات لیست فیلمها از سرویس backend
پس از دریافت لیست ژانرهای سینمایی از سرور، اکنون نوبت به جایگزینی src\services\fakeMovieService.js با یک نمونهی متصل به backend است. به همین جهت ابتدا فایل جدید src\services\movieService.js را ایجاد کرده و سپس آنرا به صورت زیر تکمیل میکنیم:
سپس شروع به اصلاح کامپوننت movies میکنیم.
ابتدا دو متد دریافت لیست فیلمها و حذف یک فیلم را که در این کامپوننت استفاده شدهاند، import میکنیم:
بعد متد getMovies پیشین، که یک آرایه را بازگشت میداد، توسط متد جدیدی که یک Promise را بازگشت میدهد، جایگزین میشود:
همچنین مدیریت حذف رکوردها را نیز به صورت زیر با پیاده سازی «بهروز رسانی خوشبینانه UI» که در قسمت قبل در مورد آن بیشتر بحث شد، تغییر میدهیم. در این حالت فرض بر این است که به احتمال زیاد، await deleteMovie با موفقیت به پایان میرسد. بنابراین بهتر است UI را ابتدا به روز رسانی کنیم تا کاربر حس کار کردن با یک برنامهی سریع را داشته باشد:
ابتدا ارجاعی را از state قبلی ذخیره میکنیم تا در صوت بروز خطایی در سطر await deleteMovie، بتوانیم مجددا state را به حالت اول آن بازگردانیم. به همین منظور پیاده سازی «بهروز رسانی خوشبینانه UI»، حتما نیاز به درج صریح try/catch را دارد. برای نمایش خطاهای ویژهی 404 نیز از یک toast استفاده شده که نیاز به import زیر را دارد:
سایر خطاهای رخ داده، توسط interceptor درج شدهی در سرویس http، به صورت خودکار پردازش میشوند.
اتصال فرم ثبت و ویرایش یک فیلم به backend server
تا اینجا اگر برنامه را اجرا کنیم، با کلیک بر روی لینک هر فیلم نمایش داده شدهی در صفحه، به صفحهی not-found هدایت میشویم. برای رفع این مشکل، به فایل src\components\movieForm.jsx مراجعه کرده و ابتدا
قبلی را با نمونههای جدیدی که با سرور کار میکنند، جایگزین میکنیم:
سپس ارجاعات به این سه متد import شده را با await، همراه کرده و متد اصلی را به صورت async معرفی میکنیم:
البته میتوان جهت بهبود کیفیت کدها، از متد componentDidMount، دو متد با مسئولیتهای مجزای دریافت ژانرها (populateGenres) و سپس نمایش فرم اطلاعات فیلم (populateMovie) را استخراج کرد:
در متد populateMovie، اگر movieId اشتباهی وارد شود و یا کلا عملیات دریافت اطلاعات، با شکست مواجه شود، کاربر را به صفحهی not-found هدایت میکنیم. یعنی وجود try/catch در اینجا ضروری است. چون اگر movieId اشتباهی وارد شود، اینبار دیگر خطوط بعدی اجرا نمیشوند و در همان سطر await getMovie، یک استثناء صادر شده و کار خاتمه پیدا میکند. بنابراین نیاز داریم بتوانیم این استثنای احتمالی را مدیریت کرده و کاربر را به صفحهی not-found هدایت کنیم.
پیشتر زمانیکه متد getMovie، یک شیء ساده را از fake service، بازگشت میداد، چنین مشکلی را نداشتیم؛ به همین جهت در سطر بعدی آن، هدایت کاربر در صورت نال بودن نتیجه، با یک return صورت میگرفت. اما اینجا بجای نال، یک استثناء را ممکن است دریافت کنیم.
مرحلهی آخر اصلاح این فرم، اتصال قسمت ثبت اطلاعات آن است که با قرار دادن یک await، پیش از متد saveMovie و async کردن متد آن، انجام میشود:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-25-backend.zip و sample-25-frontend.zip
افزودن سرویس httpService.js به برنامه
تا این قسمت، تمام اطلاعات نمایش داده شدهی در لیست فیلمها، از سرویس درون حافظهای src\services\fakeMovieService.js و لیست ژانرها از سرویس src\services\fakeGenreService.js، تامین میشوند. اکنون در ادامه میخواهیم این سرویسها را با سرویس backend یاد شده، جایگزین کنیم تا این برنامه، اطلاعات خودش را از سرور دریافت کند. به همین جهت قبل از هر کاری، سرویس عمومی src\services\httpService.js را که در قسمت قبل توسعه دادیم، به برنامهی نمایش لیست فیلمها نیز اضافه میکنیم (فایل آنرا از پروژهی قبلی کپی کرده و در اینجا paste میکنیم)، تا بتوانیم از امکانات آن در اینجا نیز استفاده کنیم. فایل httpService.js، دارای وابستگیهای خارجی react-toastify و axios است. به همین جهت برای افزودن آنها مراحل زیر را طی میکنیم:
- نصب کتابخانههای react-toastify و axios از طریق خط فرمان (با فشردن دکمههای ctrl+back-tick در VSCode):
> npm i axios --save > npm i react-toastify --save
import { ToastContainer } from "react-toastify"; import "react-toastify/dist/ReactToastify.css";
render() { return ( <React.Fragment> <ToastContainer />
دریافت اطلاعات لیست نمایش ژانرها از سرویس backend
با فراخوانی آدرس https://localhost:5001/api/Genres، میتوان لیست ژانرهای سینمایی تعریف شدهی در سرویسهای backend را مشاهده کرد. اکنون قصد داریم از این اطلاعات، در برنامه استفاده کنیم. به همین جهت به فایل src\components\movies.jsx مراجعه کرده و تغییرات زیر را اعمال میکنیم:
چون نمیخواهیم تغییراتی بسیار اساسی را در اینجا اعمال کنیم، قدم به قدم عمل کرده و سرویس قبلی fakeGenreService.js را با یک سرویس جدید که اطلاعات خودش را از سرور دریافت میکند، جایگزین میکنیم. بنابراین ابتدا فایل جدید src\services\genreService.js را ایجاد میکنیم. سپس آنرا طوری تکمیل خواهیم کرد که اینترفیس آن، با اینترفیس fakeGenreService قبلی یکی باشد:
import { apiUrl } from "../config.json"; import http from "./httpService"; export function getGenres() { return http.get(apiUrl + "/genres"); }
{ "apiUrl": "https://localhost:5001/api" }
پس از تکمیل سرویس جدید src\services\genreService.js، به فایل src\components\movies.jsx بازگشته و سطر قبلی
import { getGenres } from "../services/fakeGenreService";
import { getGenres } from "../services/genreService";
Uncaught TypeError: Object is not a function or its return value is not iterable
async componentDidMount() { const { data } = await getGenres(); const genres = [{ _id: "", name: "All Genres" }, ...data]; this.setState({ movies: getMovies(), genres }); }
دریافت اطلاعات لیست فیلمها از سرویس backend
پس از دریافت لیست ژانرهای سینمایی از سرور، اکنون نوبت به جایگزینی src\services\fakeMovieService.js با یک نمونهی متصل به backend است. به همین جهت ابتدا فایل جدید src\services\movieService.js را ایجاد کرده و سپس آنرا به صورت زیر تکمیل میکنیم:
import { apiUrl } from "../config.json"; import http from "./httpService"; const apiEndpoint = apiUrl + "/movies"; function movieUrl(id) { return `${apiEndpoint}/${id}`; } export function getMovies() { return http.get(apiEndpoint); } export function getMovie(movieId) { return http.get(movieUrl(movieId)); } export function saveMovie(movie) { if (movie.id) { return http.put(movieUrl(movie.id), movie); } return http.post(apiEndpoint, movie); } export function deleteMovie(movieId) { return http.delete(movieUrl(movieId)); }
ابتدا دو متد دریافت لیست فیلمها و حذف یک فیلم را که در این کامپوننت استفاده شدهاند، import میکنیم:
import { getMovies, deleteMovie } from "../services/movieService";
async componentDidMount() { const { data } = await getGenres(); const genres = [{ id: "", name: "All Genres" }, ...data]; const { data: movies } = await getMovies(); this.setState({ movies, genres }); }
handleDelete = async movie => { const originalMovies = this.state.movies; const movies = originalMovies.filter(m => m.id !== movie.id); this.setState({ movies }); try { await deleteMovie(movie.id); } catch (ex) { if (ex.response && ex.response.status === 404) { console.log(ex); toast.error("This movie has already been deleted."); } this.setState({ movies: originalMovies }); //undo changes } };
import { toast } from "react-toastify";
اتصال فرم ثبت و ویرایش یک فیلم به backend server
تا اینجا اگر برنامه را اجرا کنیم، با کلیک بر روی لینک هر فیلم نمایش داده شدهی در صفحه، به صفحهی not-found هدایت میشویم. برای رفع این مشکل، به فایل src\components\movieForm.jsx مراجعه کرده و ابتدا
import { getGenres } from "../services/fakeGenreService"; import { getMovie, saveMovie } from "../services/fakeMovieService";
import { getGenres } from "../services/genreService"; import { getMovie, saveMovie } from "../services/movieService";
async componentDidMount() { const { data: genres } = await getGenres(); this.setState({ genres }); const movieId = this.props.match.params.id; if (movieId === "new") return; const { data: movie } = await getMovie(movieId); if (!movie) return this.props.history.replace("/not-found"); this.setState({ data: this.mapToViewModel(movie) }); }
async populateGenres() { const { data: genres } = await getGenres(); this.setState({ genres }); } async populateMovie() { try { const movieId = this.props.match.params.id; if (movieId === "new") return; const { data: movie } = await getMovie(movieId); this.setState({ data: this.mapToViewModel(movie) }); } catch (ex) { if (ex.response && ex.response.status === 404) this.props.history.replace("/not-found"); } } async componentDidMount() { await this.populateGenres(); await this.populateMovie(); }
پیشتر زمانیکه متد getMovie، یک شیء ساده را از fake service، بازگشت میداد، چنین مشکلی را نداشتیم؛ به همین جهت در سطر بعدی آن، هدایت کاربر در صورت نال بودن نتیجه، با یک return صورت میگرفت. اما اینجا بجای نال، یک استثناء را ممکن است دریافت کنیم.
مرحلهی آخر اصلاح این فرم، اتصال قسمت ثبت اطلاعات آن است که با قرار دادن یک await، پیش از متد saveMovie و async کردن متد آن، انجام میشود:
doSubmit = async () => { await saveMovie(this.state.data); this.props.history.push("/movies"); };
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-25-backend.zip و sample-25-frontend.zip
درسته اگر یک مطلبی را بصورت Limited نشر داده باشین در حالت ویرایش نمیشه اونرو به Public تغییر بدین و باید اون مطلب رو دوباره بزنیم بازنشر داده بشه و اون موقع Public رو انتخاب کنیم ،
یک مشکلی هم که خیلی ها بعد از ایجاد تغییرات جدید به گودر می گیرند اینه که اگر بخوای مطلبی رو نشر بدی حتما باید اونرو +1 کنی و بعد نشر بدی درصورتی که شاید اون مطلب رو دوست نداشته باشی ،
ولی اینکار لازم نیست ، اگر در گودر در حال مطالعه مطلبی هستید وقتی در نوار سیاه رنگ بالا روی دکمه [Share...] کلیک کنید ، خودش لینک مطلبی رو که در حال مطالعه اش هستید تشخیص میده و به متن شما وصله می کنه ، برای بعضی ها کلا شاید این شیوه نشر دادن مطالب راحت تر باشه .
یک مشکلی هم که خیلی ها بعد از ایجاد تغییرات جدید به گودر می گیرند اینه که اگر بخوای مطلبی رو نشر بدی حتما باید اونرو +1 کنی و بعد نشر بدی درصورتی که شاید اون مطلب رو دوست نداشته باشی ،
ولی اینکار لازم نیست ، اگر در گودر در حال مطالعه مطلبی هستید وقتی در نوار سیاه رنگ بالا روی دکمه [Share...] کلیک کنید ، خودش لینک مطلبی رو که در حال مطالعه اش هستید تشخیص میده و به متن شما وصله می کنه ، برای بعضی ها کلا شاید این شیوه نشر دادن مطالب راحت تر باشه .
در حالت خاصی که در ادامه توضیح داده خواهد شد ممکن است بعضی از کنترلرها در لیست ظاهر نشوند، همانطور که در این کامنت به آن اشاره شده است.
خروجی نمایش داده شده در صفحه مربوطه به دسترسیها به صورت زیر میباشد که فقط یکی از این دو کنترلر در خروجی نمایش داده میشود:
با فرض اینکه اول کنترلر مربوط به Area One اجرا شود، مقدار آن در متغییر lastConrolerName قرار میگیرد، در اجرای بعدی foreach چون کنترلر بعدی به همان اسم میباشد از اجرا این شرط صرف نظر میکند.
و در دستور if هم به همین صورت عمل کردم :
ابتدا حالتی که باعث میشود بعضی از کنترلرهای شما در فرم مربوط به دسترسیهای پویا ظاهرا نشود را توضیح و سپس راه حلی که باعث حل آن میشود را در ادامه خواهید خواند.
دو Area جدید به اسمهای One , Two اضافه شدند که هر کدام شامل یک کنترلر به اسم Home هستند (داخل هر کنترلر هم یک اکشن متد به نام Index وجود دارد )
[Authorize(Policy = ConstantPolicies.DynamicPermission)] [Area("One")] [DisplayName("home")] public class HomeController : Controller { [DisplayName("ایندکس")] public IActionResult Index() { return View(); } }
و مشابه همین برای Area دوم :
[Authorize(Policy = ConstantPolicies.DynamicPermission)] [Area("Two")] [DisplayName("home2")] public class HomeController : Controller { [DisplayName("ایندکس")] public IActionResult Index() { return View(); } }
بعد از بررسی کدهای مربوط به GetAllSecuredControllerActionsWithPolicy متوجه شدم زمانی که دو کنترلر هم نام پشت سر هم قرار گرفته باشند، کنترلر دوم بخاطر شرط زیر نادیده گرفته میشود:
if (!lastControllerName.Equals(descriptor.ControllerName, StringComparison.Ordinal)) { }
برای حل این مورد، namespace هر کنترلر را برای منحصر بفرد کردن کنترلرها دخیل کردم:
lastControllerName = $"{descriptor.ControllerTypeInfo.Namespace}{descriptor.ControllerName}";
var controllerName = $"{descriptor.ControllerTypeInfo.Namespace}{descriptor.ControllerName}"; if (!lastControllerName.Equals(controllerName, StringComparison.Ordinal))
* اگر هردو کنترلرهای Home مربوط به areaهای one,two بعد از کنترلری به اسم Home باشند، در حالت عادی هیچ کدام از این کنترلرها در خروجی ظاهرا نخواهند شد، این مورد دقیقا مشکلی بود در پروژه جاری ام با آن برخورد کردم.