صحبت شما صحیح است. اما تناقضی که به آن اشاره فرمودید در ذهن کسی که قصد ارائه قیمت داره پیش نمیاد. اصولاً فرد تعداد بیشتر فرم و ... را به نوعی به صورت نیاز به زمان و زحمت بیشتر در ذهن خود تفسیر میکند. همچنین با توجه به این که نرم افزار مانند کالاهای دیگر دارای کیفیتهای گوناگونی میباشد با توجه به حضور احتمالی رقبا معمولاً گزینه سوم هم مورد بررسی قرار میگیرد تا مشخص شود نرم افزار با چه کیفیت و کمیتی را باید در نظر بگیرید و بر اساس زمان و سایر پارامترها در همان محدوده کیفی و کمی قیمت را تعیین کنید. پس به نوعی هر سه مورد میتواند موثر باشد. به شخصه اگر خود را به جای مشتری قرار بدم هیچ یک از این روشهای تعیین قیمت را دقیق و صحیح نمیدانم و اولین قدم برای کاهش مشکلاتی از این دست را تقویت تیمهای Presentation میدانم.
در قسمت قبل، Docker for Windows را بر روی ویندوز 10 نصب کردیم تا بتوانیم از هر دوی Linux Containers و Windows Containers استفاده کنیم. در این قسمت، نحوهی نصب Docker را بر روی ویندوز سرور، صرفا جهت اجرای Windows Containers، بررسی میکنیم؛ از این جهت که در دنیای واقعی، عموما Linux Containers را بر روی سرورهای لینوکسی و Windows Containers را بر روی سرورهای ویندوزی اجرا میکنند.
Docker for Windows چگونه از هر دوی کانتینرهای ویندوزی و لینوکسی پشتیبانی میکند؟
زمانیکه docker for windows را اجرا میکنیم، سرویسی را ایجاد میکند که سبب اجرای پروسهی ویژهای به نام com.docker.proxy.exe میشود:
هنگامیکه برای مثال فرمان docker run nginx را توسط Docker CLI اجرا میکنیم، Docker CLI از طریق واسط یاد شده، دستورات را به MobyLinuxVM منتقل میکند. به این صورت است که امکان اجرای Linux Containers، بر روی ویندوز میسر میشوند:
اکنون اگر به Windows Containers سوئیچ کنیم (از طریق کلیک راست بر روی آیکن Docker در قسمت Tray Icons ویندوز)، پروسهی dockerd.exe یا docker daemon شروع به کار خواهد کرد:
اینبار اگر مجددا از Docker CLI برای اجرای مثلا IIS Container استفاده کنیم، دستور ما از طریق واسطهای com.docker.proxy و dockerd، به کانتینر ویندوزی منتقل و اجرا میشود:
نگاهی به معماری Docker بر روی ویندوز سرور
داکر بر روی ویندوز سرور، تنها به همراه موتور مدیریت کنندهی Windows Containers است:
در اینجا با صدور فرمانهای Docker CLI، پیامها مستقیما به dockerd یا موتور داکر بر روی ویندوز سرور ارسال شده و سپس کار اجرا و مدیریت یک Windows Container انجام میشود.
نصب Docker بر روی ویندوز سرور
جزئیات مفصل و به روز Windows Containers را همواره میتوانید در این آدرس در سایت مستندات مجازی سازی مایکروسافت مطالعه کنید (قسمت Container Host Deployment - Windows Server آن). پیشنیاز کار با آن نیز نصب حداقل ویندوز سرور 2016 میباشد و بهتر است تمام به روز رسانیهای آنرا نیز نصب کرده باشید؛ چون تعدادی از بهبودهای کار با کانتینرهای آن، به همراه به روز رسانیها آن ارائه شدهاند.
برای شروع به نصب، نیاز است کنسول PowerShell ویندوز را با دسترسی Admin اجرا کنید.
سپس اولین دستوراتی را که نیاز است اجرا کنید، کار نصب موتور Docker و CLI آنرا به صورت خودکار بر روی ویندوز سرور انجام میدهند:
- که پس از نصب و ریاستارت سیستم، نتیجهی آنرا در پوشهی c:\Program Files\Docker میتوانید ملاحظه کنید.
- به علاوه اگر دستور *get-service *docker را در کنسول PowerShell صادر کنید، مشاهده خواهید کرد که سرویس جدیدی را به نام Docker نیز نصب و راه اندازی کردهاست که به dockerd.exe اشاره میکند.
- و یا اگر در کنسول PowerShell دستور docker را صادر کنید، ملاحظه خواهید کرد که CLI آن، فعال و قابل استفادهاست. برای مثال، دستور docker version را صادر کنید تا بتوانید نگارش docker نصب شده را ملاحظه نمائید.
اجرای Image مخصوص NET Core. بر روی ویندوز سرور
تگهای مختلف Image مخصوص NET Core. را در اینجا ملاحظه میکنید. در ادامه قصد داریم tag مرتبط با nanoserver آنرا نصب کنیم (با حجم 802MB):
زمانیکه این دستور را اجرا میکنیم، پس از اجرای آن، ابتدا یک \:C را نمایش میدهد و بعد خاتمه یافته و به command prompt بازگشت داده میشویم. برای مشاهدهی علت آن، اگر دستور docker ps -a را اجرا کنیم، در ستون command آن، قسمتی از دستوری را که اجرا کردهاست، میتوان مشاهده کرد. برای مشاهدهی کامل این دستور، نیاز است دستور docker ps -a --no-trunc را اجرا کنیم. در اینجا سوئیچ no-trunc به معنای no truncate است یا عدم حذف قسمت انتهایی یک دستور طولانی. در این حالت مشاهده خواهیم کرد که این دستور، کار اجرای cmd.exe واقع در پوشهی ویندوز را انجام میدهد (یا همان command prompt معمولی ویندوز). چون دستور docker run فوق به آن متصل نشدهاست، این پروسه ابتدا \:c را نمایش میدهد و سپس خاتمه پیدا میکند. برای رفع این مشکل، از interactive command که در قسمت قبل توضیح دادیم، استفاده خواهیم کرد:
اینبار اگر این دستور را اجرا کنیم، به command prompt آغاز شدهی توسط آن، متصل خواهیم شد. اکنون اگر در همینجا (داخل container در حال اجرا) دستور dotnet --info را صادر کنید، میتوان مشخصات NET Core SDK. نصب شده را مشاهده کرد. برای خروج از آن نیز دستور exit را صادر کنید.
چرا حجم Image مخصوص NET Core. نگارش nanoserver آن حدود 800 مگابایت است؟
در مثال قبلی، دسترسی به command prompt مجزایی نسبت به command prompt اصلی سیستم، در داخل یک container، شاید اندکی غیر منتظره بود و اکنون این سؤال مطرح میشود که یک image، شامل چه چیزهایی است؟
یک image شاید در ابتدای کار صرفا شامل فایلهای اجرایی یک برنامهی خاص به نظر برسد؛ اما زمانیکه قرار است تبدیل به یک container قابل اجرا شود، شامل بسیاری از فایلهای دیگر نیز خواهد شد. برای درک این موضوع نیاز است لایههای نرم افزاری که یک سیستم را تشکیل میدهند، بررسی کنیم:
در این تصویر از پایینترین لایهای را که با سخت افزار ارتباط برقرار میکند تا بالاترین لایهی موجود نرم افزاری را مشاهده میکنید. دراینجا هر چیزی را که در ناحیهی کرنل قرار نمیگیرد، User Space مینامند. برنامههای قرار گرفتهی در User Space برای کار با سخت افزار نیاز است با کرنل ارتباط برقرار کنند و برای این منظور از System Calls استفاده میکنند که عموما کتابخانههایی هستند که جزئی از سیستم عامل میباشند؛ مانند API ویندوز. برای مثال MongoDB توسط Win32 API و System Calls، فرامینی را به کرنل منتقل میکند.
در روش متداول توزیع و نصب نرم افزار، ما عموما همان بالاترین سطح را توزیع و نصب میکنیم؛ برای مثال خود MongoDB را. در اینجا نصاب MongoDB فرض میکند که در سیستم جاری، تمام لایههای دیگر، موجود و آمادهی استفاده هستند و اگر اینگونه نباشد، به مشکل برخواهد خورد و اجرا نمیشود. برای اجتناب از یک چنین مشکلاتی مانند عدم حضور وابستگیهایی که یک برنامه برای اجرا نیاز دارد، imageهای docker، نحوهی توزیع نرم افزارها را تغییر دادهاند. اینبار یک image بجای توزیع فقط MongoDB، شامل تمام قسمتهای مورد نیاز User Space نیز هست:
به این ترتیب دیگر مشکلاتی مانند عدم وجود یک وابستگی یا حتی وجود یک وابستگی غیرسازگار با نرم افزار مدنظر، وجود نخواهند داشت. حتی میتوان تصویر فوق را به صورت زیر نیز خلاصه کرد:
به همین جهت بود که برای مثال در قسمت قبل موفق شدیم IIS مخصوص ویندوز سرور با تگ nanoserver را بر روی ویندوز 10 که بسیاری از وابستگیهای مرتبط را به همراه ندارد، با موفقیت اجرا کنیم.
به علاوه چون یک container صرفا به معنای یک running process از یک image است، هر فایل اجرایی داخل آن image را نیز میتوان به صورت یک container اجرا کرد؛ مانند cmd.exe داخل image مرتبط با NET Core. که آنرا بررسی کردیم.
کارآیی Docker Containers نسبت به ماشینهای مجازی بسیار بیشتر است
مزیت دیگر یک چنین توزیعی این است که اگر چندین container در حال اجرا را داشته باشیم:
در نهایت تمام آنها فقط با یک لایهی کرنل کار میکنند و آن هم کرنل اصلی سیستم جاری است. به همین جهت کارآیی docker containers نسبت به ماشینهای مجازی بیشتر است؛ چون هر ماشین مجازی، کرنل مجازی خاص خودش را نسبت به یک ماشین مجازی در حال اجرای دیگر دارد. در اینجا برای ایجاد یک لایه ایزولهی اجرای برنامهها، تنها کافی است یک container جدید را اجرا کنیم و در این حالت وارد فاز بوت شدن یک سیستم عامل کامل، مانند ماشینهای مجازی نمیشویم.
شاید مطابق تصویر فوق اینطور به نظر برسد که هرچند تمام این containers از یک کرنل استفاده میکنند، اما اگر قرار باشد هر کدام OS Apps & Libs خاص خودشان را در حافظه بارگذاری کنند، با کمبود شدید منابع روبرو شویم. دقیقا مانند حالتیکه چند ماشین مجازی را اجرا کردهایم و دیگر سیستم اصلی قادر به پاسخگویی به درخواستهای رسیده به علت کمبود منابع نیست. اما در واقعیت، یک image داکر، از لایههای مختلفی تشکیل میشود که فقط خواندنی هستند و غیرقابل تغییر و زمانیکه docker یک لایهی فقط خواندنی را در حافظه بارگذاری کرد، اگر container دیگری، از همان لایهی تعریف شده، در image خود نیز استفاده میکند، لایهی بارگذاری شدهی فقط خواندنی در حال اجرای موجود را با آن به اشتراک میگذارد (مانند تصویر زیر). به این ترتیب میزان مصرف منابع docker containers نسبت به ماشینهای مجازی بسیار کمتر است:
روش کنترل پروسهای که درون یک کانتینر اجرا میشود
با اجرای دستور docker run -it microsoft/dotnet:nanoserver ابتدا به command prompt داخلی و مخصوص این container منتقل میشویم و سپس میتوان برای مثال با NET Core CLI. کار کرد. اما امکان اجرای این CLI به صورت زیر نیز وجود دارد:
این دستور، مشخصات SDK نصب شده را نمایش میدهد و سپس مجددا به command prompt سیستم اصلی (که به آن میزبان، host و یا container host نیز گفته میشود) بازگشت داده خواهیم شد؛ چون کار NET Core CLI. خاتمه یافتهاست، پروسهی متعلق به آن نیز خاتمه مییابد.
بدیهی است در این حالت تمام فایلهای اجرایی داخل این container را نیز میتوان اجرا کرد. برای مثال میتوان کنسول پاورشل داخل این container را اجرا کرد:
زمانیکه به این کنسول دسترسی پیدا کردید، برای مثال دستور get-process را اجرا کنید. به این ترتیب میتوانید لیست تمام پروسههایی ر که هم اکنون داخل این container در حال اجرا هستند، مشاهده کنید.
هر کانتینر دارای یک File System ایزولهی خاص خود است
تا اینجا دریافتیم که هر image، به همراه فایلهای user space مورد نیاز خود نیز میباشد. به عبارتی هر image یک file system را نیز ارائه میدهد که تنها درون همان container قابل دسترسی میباشد و از مابقی سیستم جاری ایزوله شدهاست.
برای آزمایش آن، کنسول پاورشل را در سیستم میزبان (سیستم عامل اصلی که docker را اجرا میکند)، باز کرده و دستور \:ls c را صادر کنید. به این ترتیب میتوانید لیست پوشهها و فایلهای موجود در درایو C میزبان را مشاهده نمائید. سپس دستور docker run -it microsoft/dotnet:nanoserver powershell را اجرا کنید تا به powershell داخل کانتینر NET Core. دسترسی پیدا کنیم. اکنون دستور \:ls c را مجددا اجرا کنید. خروجی آن کاملا متفاوت است نسبت به گزارشی که پیشتر بر روی سیستم میزبان تهیه کردیم؛ دقیقا مانند اینکه هارد درایو یک container متفاوت است با هارد درایو سیستم میزبان.
این تصویر زمانی تهیه شدهاست که دستور docker run یاد شده را صادر کردهایم و درون powershell آن قرار داریم. همانطور که مشاهده میکنید یک Disk جدید، به ازای این Container در حال اجرا، به سیستم میزبان اضافه شدهاست. این Disk زمانیکه در powershell داخل container، دستور exit را صادر کنیم، بلافاصله محو میشود. چون پروسهی container، به این ترتیب خاتمه یافتهاست.
اگر دستور docker run یاد شده را دو بار اجرا کنیم، دو Disk جدید ظاهر خواهند شد:
یک نکته: اگر بر روی این درایوهای مجازی کلیک راست کرده، گزینهی change drive letter or path را انتخاب نموده و یک drive letter را به آنها نسبت دهید، میتوانید محتویات داخل آنها را توسط Windows Explorer ویندوز میزبان نیز به صورت یک درایو جدید، مشاهده کنید.
خلاصهای از ایزوله سازیهای کانتینرها تا به اینجا
تا اینجا یک چنین ایزوله سازیهایی را بررسی کردیم:
- ایزوله سازی File System و وجود یک disk مجازی مجزا به ازای هر کانتینر در حال اجرا.
- پروسههای کانتینرها از پروسههای میزبان ایزوله هستند. برای مثال اگر دستور get-process را داخل یک container اجرا کنید، خروجی آن با خروجی اجرای این دستور بر روی سیستم میزبان یکی نیست. یعنی نمیتوان از داخل کانتینرها، به پروسههای میزبان دسترسی داشت و دخل و تصرفی را در آنها انجام داد که از لحاظ امنیتی بسیار مفید است. هر چند اگر به task manager ویندوز میزبان مراجعه کنید، میتوان پروسههای داخل یک container را توسط Job Object ID یکسان آنها تشخیص دهید (مثال آخر قسمت قبل)، اما یک container، قابلیت شمارش پروسههای خارج از مرز خود را ندارد.
- ایزوله سازی شبکه مانند کارت شبکهی مجازی کانتینر IIS که در قسمت قبل بررسی کردیم. برای آزمایش آن دستور ipconfig را در داخل container و سپس در سیستم میزبان اجرا کنید. نتیجهای را که مشاهده خواهید کرد، کاملا متفاوت است. یعنی network stack این دو کاملا از هم مجزا است. شبیه به اینکه به یک سیستم، چندین کارت شبکه را متصل کرده باشید. اینکار در اینجا با تعریف virtual network adaptors انجام میشود و لیست آنها را در قسمت «All Control Panel Items\Network Connections» سیستم میزبان میتوانید مشاهده کنید. یکی از مهمترین مزایای آن این است که اگر در یک container، وب سروری را بر روی پورت 80 آن اجرا کنید، مهم نیست که در سیستم میزبان، یک IIS در حال سرویس دهی بر روی پورت 80 هم اکنون موجود است. این دو پورت با هم تداخل نمیکنند.
- در حالت کار با Windows Containers، رجیستری کانتینر نیز از میزبان آن مجزا است و یا متغیرهای محیطی اینها یکی نیست. برای مثال دستور \:ls env را در کانتینر و سیستم میزبان اجرا کنید تا environment variables را گزارش گیری کنید. خروجی این دو کاملا متفاوت است. برای مثال حداقل computer name، user nameهای قابل مشاهدهی در این گزارشها، متفاوت است و یا دستور \:ls hkcu را در هر دو اجرا کنید تا خروجی رجیستری متعلق به کاربر جاری هر کدام را مشاهده کنید که در هر دو متفاوت است.
- در حالت کار با Linux Containers هر چیزی که ذیل عنوان namespace مطرح میشود مانند شبکه، PID، User، UTS، Mount و غیره شامل ایزوله سازی میشوند.
دو نوع Windows Containers وجود دارند
در ویندوز، Windows Server Containers و Hyper-V Containers وجود دارند. در این قسمت تمام کارهایی را که بر روی ویندوز سرور انجام دادیم، در حقیقت بر روی Windows Server Containers انجام شدند و تمام Containerهای ویندوزی را که در قسمت قبل بر روی ویندوز 10 ایجاد کردیم، از نوع Hyper-V Containers بودند.
تفاوت مهم اینها در مورد نحوهی پیاده سازی ایزوله سازی آنها است. در حالت Windows Server Containers، کار ایزوله سازی پروسهها توسط کرنل اشتراکی بین کانتینرها صورت میگیرد اما در Hyper-V Containers، این ایزوله سازی توسط hypervisor آن انجام میشود؛ هرچند نسبت به ماشینهای مجازی متداول بسیار سریعتر است، اما بحث به اشتراک گذاری کرنل هاست را که پیشتر در این قسمت بررسی کردیم، در این حالت شاهد نخواهیم بود. ویندوز سرور 2016 میتواند هر دوی این ایزوله سازیها را پشتیبانی کند، اما ویندوز 10، فقط نوع Hyper-V را پشتیبانی میکند.
روش اجرای Hyper-V Containers بر روی ویندوز سرور
در صورت نیاز برای کار با Hyper-V Containers، نیاز است مانند قسمت قبل، ابتدا Hyper-V را بر روی ویندوز سرور، فعالسازی کرد:
اکنون برای اجرای دستور docker run ای که توسط Hyper-V مدیریت میشود، میتوان به صورت زیر، از سوئیچ isolation استفاده کرد:
در این حالت اگر به disk management سیستم میزبان مراجعه کنید، دیگر حالت اضافه شدن disk مجازی را مشاهده نمیکنید. همچنین اگر به task manager ویندوز میزبان مراجعه کنید، دیگر لیست پروسههای داخل container را نیز در اینجا نمیبینید. علت آن روش ایزوله سازی متفاوت آن با Windows Server Containers است و بیشتر شبیه به ماشینهای مجازی عمل میکند. در کل اگر نیاز به حداکثر و شدیدترین حالت ایزوله سازی را دارید، از این روش استفاده کنید.
Docker for Windows چگونه از هر دوی کانتینرهای ویندوزی و لینوکسی پشتیبانی میکند؟
زمانیکه docker for windows را اجرا میکنیم، سرویسی را ایجاد میکند که سبب اجرای پروسهی ویژهای به نام com.docker.proxy.exe میشود:
هنگامیکه برای مثال فرمان docker run nginx را توسط Docker CLI اجرا میکنیم، Docker CLI از طریق واسط یاد شده، دستورات را به MobyLinuxVM منتقل میکند. به این صورت است که امکان اجرای Linux Containers، بر روی ویندوز میسر میشوند:
اکنون اگر به Windows Containers سوئیچ کنیم (از طریق کلیک راست بر روی آیکن Docker در قسمت Tray Icons ویندوز)، پروسهی dockerd.exe یا docker daemon شروع به کار خواهد کرد:
اینبار اگر مجددا از Docker CLI برای اجرای مثلا IIS Container استفاده کنیم، دستور ما از طریق واسطهای com.docker.proxy و dockerd، به کانتینر ویندوزی منتقل و اجرا میشود:
نگاهی به معماری Docker بر روی ویندوز سرور
داکر بر روی ویندوز سرور، تنها به همراه موتور مدیریت کنندهی Windows Containers است:
در اینجا با صدور فرمانهای Docker CLI، پیامها مستقیما به dockerd یا موتور داکر بر روی ویندوز سرور ارسال شده و سپس کار اجرا و مدیریت یک Windows Container انجام میشود.
نصب Docker بر روی ویندوز سرور
جزئیات مفصل و به روز Windows Containers را همواره میتوانید در این آدرس در سایت مستندات مجازی سازی مایکروسافت مطالعه کنید (قسمت Container Host Deployment - Windows Server آن). پیشنیاز کار با آن نیز نصب حداقل ویندوز سرور 2016 میباشد و بهتر است تمام به روز رسانیهای آنرا نیز نصب کرده باشید؛ چون تعدادی از بهبودهای کار با کانتینرهای آن، به همراه به روز رسانیها آن ارائه شدهاند.
برای شروع به نصب، نیاز است کنسول PowerShell ویندوز را با دسترسی Admin اجرا کنید.
سپس اولین دستوراتی را که نیاز است اجرا کنید، کار نصب موتور Docker و CLI آنرا به صورت خودکار بر روی ویندوز سرور انجام میدهند:
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force Install-Package -Name docker -ProviderName DockerMsftProvider Restart-Computer -Force
- به علاوه اگر دستور *get-service *docker را در کنسول PowerShell صادر کنید، مشاهده خواهید کرد که سرویس جدیدی را به نام Docker نیز نصب و راه اندازی کردهاست که به dockerd.exe اشاره میکند.
- و یا اگر در کنسول PowerShell دستور docker را صادر کنید، ملاحظه خواهید کرد که CLI آن، فعال و قابل استفادهاست. برای مثال، دستور docker version را صادر کنید تا بتوانید نگارش docker نصب شده را ملاحظه نمائید.
اجرای Image مخصوص NET Core. بر روی ویندوز سرور
تگهای مختلف Image مخصوص NET Core. را در اینجا ملاحظه میکنید. در ادامه قصد داریم tag مرتبط با nanoserver آنرا نصب کنیم (با حجم 802MB):
docker run microsoft/dotnet:nanoserver
docker run -it microsoft/dotnet:nanoserver
چرا حجم Image مخصوص NET Core. نگارش nanoserver آن حدود 800 مگابایت است؟
در مثال قبلی، دسترسی به command prompt مجزایی نسبت به command prompt اصلی سیستم، در داخل یک container، شاید اندکی غیر منتظره بود و اکنون این سؤال مطرح میشود که یک image، شامل چه چیزهایی است؟
یک image شاید در ابتدای کار صرفا شامل فایلهای اجرایی یک برنامهی خاص به نظر برسد؛ اما زمانیکه قرار است تبدیل به یک container قابل اجرا شود، شامل بسیاری از فایلهای دیگر نیز خواهد شد. برای درک این موضوع نیاز است لایههای نرم افزاری که یک سیستم را تشکیل میدهند، بررسی کنیم:
در این تصویر از پایینترین لایهای را که با سخت افزار ارتباط برقرار میکند تا بالاترین لایهی موجود نرم افزاری را مشاهده میکنید. دراینجا هر چیزی را که در ناحیهی کرنل قرار نمیگیرد، User Space مینامند. برنامههای قرار گرفتهی در User Space برای کار با سخت افزار نیاز است با کرنل ارتباط برقرار کنند و برای این منظور از System Calls استفاده میکنند که عموما کتابخانههایی هستند که جزئی از سیستم عامل میباشند؛ مانند API ویندوز. برای مثال MongoDB توسط Win32 API و System Calls، فرامینی را به کرنل منتقل میکند.
در روش متداول توزیع و نصب نرم افزار، ما عموما همان بالاترین سطح را توزیع و نصب میکنیم؛ برای مثال خود MongoDB را. در اینجا نصاب MongoDB فرض میکند که در سیستم جاری، تمام لایههای دیگر، موجود و آمادهی استفاده هستند و اگر اینگونه نباشد، به مشکل برخواهد خورد و اجرا نمیشود. برای اجتناب از یک چنین مشکلاتی مانند عدم حضور وابستگیهایی که یک برنامه برای اجرا نیاز دارد، imageهای docker، نحوهی توزیع نرم افزارها را تغییر دادهاند. اینبار یک image بجای توزیع فقط MongoDB، شامل تمام قسمتهای مورد نیاز User Space نیز هست:
به این ترتیب دیگر مشکلاتی مانند عدم وجود یک وابستگی یا حتی وجود یک وابستگی غیرسازگار با نرم افزار مدنظر، وجود نخواهند داشت. حتی میتوان تصویر فوق را به صورت زیر نیز خلاصه کرد:
به همین جهت بود که برای مثال در قسمت قبل موفق شدیم IIS مخصوص ویندوز سرور با تگ nanoserver را بر روی ویندوز 10 که بسیاری از وابستگیهای مرتبط را به همراه ندارد، با موفقیت اجرا کنیم.
به علاوه چون یک container صرفا به معنای یک running process از یک image است، هر فایل اجرایی داخل آن image را نیز میتوان به صورت یک container اجرا کرد؛ مانند cmd.exe داخل image مرتبط با NET Core. که آنرا بررسی کردیم.
کارآیی Docker Containers نسبت به ماشینهای مجازی بسیار بیشتر است
مزیت دیگر یک چنین توزیعی این است که اگر چندین container در حال اجرا را داشته باشیم:
در نهایت تمام آنها فقط با یک لایهی کرنل کار میکنند و آن هم کرنل اصلی سیستم جاری است. به همین جهت کارآیی docker containers نسبت به ماشینهای مجازی بیشتر است؛ چون هر ماشین مجازی، کرنل مجازی خاص خودش را نسبت به یک ماشین مجازی در حال اجرای دیگر دارد. در اینجا برای ایجاد یک لایه ایزولهی اجرای برنامهها، تنها کافی است یک container جدید را اجرا کنیم و در این حالت وارد فاز بوت شدن یک سیستم عامل کامل، مانند ماشینهای مجازی نمیشویم.
شاید مطابق تصویر فوق اینطور به نظر برسد که هرچند تمام این containers از یک کرنل استفاده میکنند، اما اگر قرار باشد هر کدام OS Apps & Libs خاص خودشان را در حافظه بارگذاری کنند، با کمبود شدید منابع روبرو شویم. دقیقا مانند حالتیکه چند ماشین مجازی را اجرا کردهایم و دیگر سیستم اصلی قادر به پاسخگویی به درخواستهای رسیده به علت کمبود منابع نیست. اما در واقعیت، یک image داکر، از لایههای مختلفی تشکیل میشود که فقط خواندنی هستند و غیرقابل تغییر و زمانیکه docker یک لایهی فقط خواندنی را در حافظه بارگذاری کرد، اگر container دیگری، از همان لایهی تعریف شده، در image خود نیز استفاده میکند، لایهی بارگذاری شدهی فقط خواندنی در حال اجرای موجود را با آن به اشتراک میگذارد (مانند تصویر زیر). به این ترتیب میزان مصرف منابع docker containers نسبت به ماشینهای مجازی بسیار کمتر است:
روش کنترل پروسهای که درون یک کانتینر اجرا میشود
با اجرای دستور docker run -it microsoft/dotnet:nanoserver ابتدا به command prompt داخلی و مخصوص این container منتقل میشویم و سپس میتوان برای مثال با NET Core CLI. کار کرد. اما امکان اجرای این CLI به صورت زیر نیز وجود دارد:
docker run -it microsoft/dotnet:nanoserver dotnet --info
بدیهی است در این حالت تمام فایلهای اجرایی داخل این container را نیز میتوان اجرا کرد. برای مثال میتوان کنسول پاورشل داخل این container را اجرا کرد:
docker run -it microsoft/dotnet:nanoserver powershell
هر کانتینر دارای یک File System ایزولهی خاص خود است
تا اینجا دریافتیم که هر image، به همراه فایلهای user space مورد نیاز خود نیز میباشد. به عبارتی هر image یک file system را نیز ارائه میدهد که تنها درون همان container قابل دسترسی میباشد و از مابقی سیستم جاری ایزوله شدهاست.
برای آزمایش آن، کنسول پاورشل را در سیستم میزبان (سیستم عامل اصلی که docker را اجرا میکند)، باز کرده و دستور \:ls c را صادر کنید. به این ترتیب میتوانید لیست پوشهها و فایلهای موجود در درایو C میزبان را مشاهده نمائید. سپس دستور docker run -it microsoft/dotnet:nanoserver powershell را اجرا کنید تا به powershell داخل کانتینر NET Core. دسترسی پیدا کنیم. اکنون دستور \:ls c را مجددا اجرا کنید. خروجی آن کاملا متفاوت است نسبت به گزارشی که پیشتر بر روی سیستم میزبان تهیه کردیم؛ دقیقا مانند اینکه هارد درایو یک container متفاوت است با هارد درایو سیستم میزبان.
این تصویر زمانی تهیه شدهاست که دستور docker run یاد شده را صادر کردهایم و درون powershell آن قرار داریم. همانطور که مشاهده میکنید یک Disk جدید، به ازای این Container در حال اجرا، به سیستم میزبان اضافه شدهاست. این Disk زمانیکه در powershell داخل container، دستور exit را صادر کنیم، بلافاصله محو میشود. چون پروسهی container، به این ترتیب خاتمه یافتهاست.
اگر دستور docker run یاد شده را دو بار اجرا کنیم، دو Disk جدید ظاهر خواهند شد:
یک نکته: اگر بر روی این درایوهای مجازی کلیک راست کرده، گزینهی change drive letter or path را انتخاب نموده و یک drive letter را به آنها نسبت دهید، میتوانید محتویات داخل آنها را توسط Windows Explorer ویندوز میزبان نیز به صورت یک درایو جدید، مشاهده کنید.
خلاصهای از ایزوله سازیهای کانتینرها تا به اینجا
تا اینجا یک چنین ایزوله سازیهایی را بررسی کردیم:
- ایزوله سازی File System و وجود یک disk مجازی مجزا به ازای هر کانتینر در حال اجرا.
- پروسههای کانتینرها از پروسههای میزبان ایزوله هستند. برای مثال اگر دستور get-process را داخل یک container اجرا کنید، خروجی آن با خروجی اجرای این دستور بر روی سیستم میزبان یکی نیست. یعنی نمیتوان از داخل کانتینرها، به پروسههای میزبان دسترسی داشت و دخل و تصرفی را در آنها انجام داد که از لحاظ امنیتی بسیار مفید است. هر چند اگر به task manager ویندوز میزبان مراجعه کنید، میتوان پروسههای داخل یک container را توسط Job Object ID یکسان آنها تشخیص دهید (مثال آخر قسمت قبل)، اما یک container، قابلیت شمارش پروسههای خارج از مرز خود را ندارد.
- ایزوله سازی شبکه مانند کارت شبکهی مجازی کانتینر IIS که در قسمت قبل بررسی کردیم. برای آزمایش آن دستور ipconfig را در داخل container و سپس در سیستم میزبان اجرا کنید. نتیجهای را که مشاهده خواهید کرد، کاملا متفاوت است. یعنی network stack این دو کاملا از هم مجزا است. شبیه به اینکه به یک سیستم، چندین کارت شبکه را متصل کرده باشید. اینکار در اینجا با تعریف virtual network adaptors انجام میشود و لیست آنها را در قسمت «All Control Panel Items\Network Connections» سیستم میزبان میتوانید مشاهده کنید. یکی از مهمترین مزایای آن این است که اگر در یک container، وب سروری را بر روی پورت 80 آن اجرا کنید، مهم نیست که در سیستم میزبان، یک IIS در حال سرویس دهی بر روی پورت 80 هم اکنون موجود است. این دو پورت با هم تداخل نمیکنند.
- در حالت کار با Windows Containers، رجیستری کانتینر نیز از میزبان آن مجزا است و یا متغیرهای محیطی اینها یکی نیست. برای مثال دستور \:ls env را در کانتینر و سیستم میزبان اجرا کنید تا environment variables را گزارش گیری کنید. خروجی این دو کاملا متفاوت است. برای مثال حداقل computer name، user nameهای قابل مشاهدهی در این گزارشها، متفاوت است و یا دستور \:ls hkcu را در هر دو اجرا کنید تا خروجی رجیستری متعلق به کاربر جاری هر کدام را مشاهده کنید که در هر دو متفاوت است.
- در حالت کار با Linux Containers هر چیزی که ذیل عنوان namespace مطرح میشود مانند شبکه، PID، User، UTS، Mount و غیره شامل ایزوله سازی میشوند.
دو نوع Windows Containers وجود دارند
در ویندوز، Windows Server Containers و Hyper-V Containers وجود دارند. در این قسمت تمام کارهایی را که بر روی ویندوز سرور انجام دادیم، در حقیقت بر روی Windows Server Containers انجام شدند و تمام Containerهای ویندوزی را که در قسمت قبل بر روی ویندوز 10 ایجاد کردیم، از نوع Hyper-V Containers بودند.
تفاوت مهم اینها در مورد نحوهی پیاده سازی ایزوله سازی آنها است. در حالت Windows Server Containers، کار ایزوله سازی پروسهها توسط کرنل اشتراکی بین کانتینرها صورت میگیرد اما در Hyper-V Containers، این ایزوله سازی توسط hypervisor آن انجام میشود؛ هرچند نسبت به ماشینهای مجازی متداول بسیار سریعتر است، اما بحث به اشتراک گذاری کرنل هاست را که پیشتر در این قسمت بررسی کردیم، در این حالت شاهد نخواهیم بود. ویندوز سرور 2016 میتواند هر دوی این ایزوله سازیها را پشتیبانی کند، اما ویندوز 10، فقط نوع Hyper-V را پشتیبانی میکند.
روش اجرای Hyper-V Containers بر روی ویندوز سرور
در صورت نیاز برای کار با Hyper-V Containers، نیاز است مانند قسمت قبل، ابتدا Hyper-V را بر روی ویندوز سرور، فعالسازی کرد:
Install-WindowsFeature hyper-v Restart-Computer -Force
docker run -it --isolation=hyperv microsoft/dotnet:nanoserver powershell
نظرات مطالب
خلاصهای کوتاه در مورد WinRT
- بحث وب که سرجای خودش همانند سابق هست و هیچ فرقی نمیکند. برنامههای ASP.NET روی سرور اجرا میشوند و عموما روی سرور بجز یک سری سرویسهای ویندوز NT ، هیچ نرم افزار دیگری نصب نخواهد شد. مثلا IIS یا مثلا SQL Server و در همین حد. حتی عموما سرورها حتی مونیتور هم ندارند و با ریموت دسکتاپ یک سری کارهای مدیریتی آنها را انجام میدهند و این کارها هم طوری نیست که هر روز تغییر کند. یکبار سرور تنظیم میشود که حداقل یکسال یا بیشتر کار کند. این مورد اصلا تغییری نخواهد داشت. بحث سمت سرور است. بنابراین سرمایه گذاری روی ASP.NET خوب است و شامل این بحث ویندوز 8 یا ویندوزهای بعدی نمیشود؛ چون اینها (WinRT) سمت کاربر محسوب میشوند.
- از این جهت که رابطهای کاربری مبتنی بر WinRT ، یا بر پایه XAML است یا HTML/CSS ، یادگیری WPF و یا سیلورلایت (که قسمتی از WPF را به ارث برده) مفید خواهند بود؛ از این لحاظ که پایه رابط کاربری هر دوی اینها هم XAML است و اساسا طراحی XAML از اینجا به WinRT منتقل شده.
کلا برای برنامه نویسهای دات نت WinRT مثل یک سری اسمبلی جدید است که اضافه شده و یک سری اسمبلی از آنها گرفته شده. هیچ تفاوت دیگری از لحاظ اصول برنامه نویسی نمیکند. یک سری فضای نام جدید و کلاس جدید دارید. یک سری از کلاسهای پیشین به دلیل محدودیتهای امنیتی، دیگر در WinRT قابل استفاده نیست. مثلا همینطوری دیگه نمیتونید هر جایی فایل جدید درست کنید، یک سری آداب و اصول خاص خودش را دارد.
ضمنا این رو هم در نظر داشته باشید که WinRT یک سیستم همه منظوره نیست و ... بین خودمان باشد بیشتر در سطح دسکتاپ برای کارهای شیک و چشم نواز و برنامههای فانتزی طراحی شده. اصل کارهای برنامههای تجاری باز هم بر اساس همان سیستمهای وب و یا دسکتاپ سابق خواهد بود.
- یادگیری سی++ همیشه مفید است. حتی در کره مریخ هم تاجایی که اطلاع دارم (!) یک کامپایلر سی++ وجود دارد و میشود با آن برنامهی Hello world را کامپایل کرد. اگر باور ندارید از این لینوکسیها بپرسید!
- از این جهت که رابطهای کاربری مبتنی بر WinRT ، یا بر پایه XAML است یا HTML/CSS ، یادگیری WPF و یا سیلورلایت (که قسمتی از WPF را به ارث برده) مفید خواهند بود؛ از این لحاظ که پایه رابط کاربری هر دوی اینها هم XAML است و اساسا طراحی XAML از اینجا به WinRT منتقل شده.
کلا برای برنامه نویسهای دات نت WinRT مثل یک سری اسمبلی جدید است که اضافه شده و یک سری اسمبلی از آنها گرفته شده. هیچ تفاوت دیگری از لحاظ اصول برنامه نویسی نمیکند. یک سری فضای نام جدید و کلاس جدید دارید. یک سری از کلاسهای پیشین به دلیل محدودیتهای امنیتی، دیگر در WinRT قابل استفاده نیست. مثلا همینطوری دیگه نمیتونید هر جایی فایل جدید درست کنید، یک سری آداب و اصول خاص خودش را دارد.
ضمنا این رو هم در نظر داشته باشید که WinRT یک سیستم همه منظوره نیست و ... بین خودمان باشد بیشتر در سطح دسکتاپ برای کارهای شیک و چشم نواز و برنامههای فانتزی طراحی شده. اصل کارهای برنامههای تجاری باز هم بر اساس همان سیستمهای وب و یا دسکتاپ سابق خواهد بود.
- یادگیری سی++ همیشه مفید است. حتی در کره مریخ هم تاجایی که اطلاع دارم (!) یک کامپایلر سی++ وجود دارد و میشود با آن برنامهی Hello world را کامپایل کرد. اگر باور ندارید از این لینوکسیها بپرسید!
ما در شرکت برای Source Control از SVN استفاده میکنیم، مزایای سورس کنترل آنقدر واضح است که دیگه من اینجا چیزی ازش نمیگم
اما برای استفاده از سورس کنترل یک مشکلی وجود دارد، اگر شما تعدادی پروژه را به کاربران خاصی بدین و تعدادی رو ندین، اون کاربر وقتی پروژهها را میگیره با مشکل ارجاعات پروژهها مواجه است. چرا که برخی از پروژههای ارجاعی، روی کامپیوتر برنامه نویس 1 وجود نداره. برعکس ش هم همین طوره، چون اون کاربر، پروژههای ارجاعی رو نداره، باید به جاش به اسمبلی نهایی اون پروژه ارجاع بده. بنابراین وقتی مدیر پروژهها رو میگیره، باز ارجاعات اشتباه هستند!
ما اینجا برای رفع این مشکل ابزاری درست کردیم، به اسم SolutionExplorer.
این ابزار فایل solution رو به همراه پوشه حاوی فایلهای اسمبلی میگیره. اگر پروژه ای به اسمبلی ای ارجاع داده باشه که پروژه اش توی solution باشه، ارجاع به اسمبلی رو تبدیل میکنه به ارجاع به پروژه و برعکسش، اگر پروژه ای به پروژه دیگه ای ارجاع داده باشه که توی solution وجود نداشته باشه، توی پوشه اسمبلی ها، دنبال اسمبلی ای میگرده که اسمش شبیه اسم پروژه ارجاعی باشه و اگر پیدا کنه، ارجاع رو عوض میکنه
البته برای جلوگیری از به هم ریختگی، نرم افزار از فایلهای پروژه ای که دستکاری میکنه، پشتیبان میگیره
توجه:
* این برنامه از تمامی جهات تست نشده است، با ریسک خودتون ازش استفاده کنید (ما تو شرکت دیگه ریسکی نداریم :) )
* سیستم نامگذاری اسمبلیها و پروژههای ما ممکنه فرق کنه
* اگر به مشکلی برخوردید، لطفا زیر همین مطلب برام بنویسید
* انتخاب پوشه اسمبلی ها، الزامی نیست
همان طور که قبلا اشاره کردیم، این پلاگین میتواند از یک زبان برنامه
نویسی سمت سرور دادههای مورد نیاز خودش را دریافت کند. میتوانید دادهها را با
استفاده از AJAX و به صورت JSON از سرور دریافت کرده و با استفاده از
DataTables آنها را در جدول تزریق کنید. در این قسمت سعی خواهیم کرد تا با استفاده از jQuery DataTables یک گرید را در MVC ایجاد کنیم. البته برای حذف جزئیات دادهها به جای
این که از یک بانک اطلاعاتی دریافت شوند، در حافظه ساخته میشوند. در هر
صورت اساس کار یکی است.
قصد داریم تا مانند مثال قسمت قبل، مجموعه ای از اطلاعات مربوط به مرورگرهای مختلف را در یک جدول نشان دهیم، اما این بار منبع داده ما فرق میکند. منبع داده از طرف سرور فراهم میشود. هر مرورگر - همان طور که در قسمت قبل مشاهده نمودید - شامل اطلاعات زیر خواهد بود:
استفاده از روش server side processing برای دریافت دادهها از سرور
این روش، یکی از امکانات jQuery DataTables است که با استفاده از آن، کلاینت تنها یک مصرف کننده صرف خواهد بود و وظیفه پردازش اطلاعات - یعنی تعداد رکوردهایی که برگشت داده میشود، صفحه بندی، مرتب سازی، جستجو، و غیره - به عهده سرور خواهد بود.
برای به کار گیری این روش، اولین کار این است که ویژگی bServerSide را true کنیم، مثلا بدین صورت:
همچنین ویژگی sAjaxSource را به Url ی که باید دادهها از آن دریافت شوند مقداردهی میکنیم.
به صورت پیش فرض مقدار ویژگی bServerSide مقدار false است؛ که یعنی منبع داده این پلاگین از سمت سرور خوانده نشود. اگر true باشد منبع داده و خیلی اطلاعات دیگر مربوط به دادههای درون جدول باید از سرور به مرورگر کاربر پس فرستاده شوند. با true کردن مقدار bServerSide، آنگاه DataTables اطلاعاتی را راجع به شماره صفحه جاری، اندازه هر صفحه، شروط فیلتر کردن داده ها، مرتب سازی ستون ها، و غیره را به سرور میفرستد. همجنین انتظار میرود تا سرور در پاسخ به این درخواست، دادههای مناسبی را به فرمت JSON به مرورگر پس بفرستد. در حالتی که bServerSide مقدار true به خود بگیرد، پلاگین فقط رابطه متقابل بین کاربر و سرور را مدیریت میکند و هیچ پردازشی را انجام نمیدهد.
در این درخواست XHR یا Ajax ی پارامترهایی که به سرور ارسال میشوند اینها هستند:
iDisplayStart عدد صحیح
نقظه شروع مجموعه داده جاری
iDisplayLength عدد صحیح
تعداد رکوردهایی که جدول میتواند نمایش دهد. تعداد رکوردهایی که از طرف سرور برگشت داده میشود باید با این عدد یکسان باشند.
iColumns عدد صحیح
تعداد ستونهایی که باید نمایش داده شوند.
sSearch رشته
فیلد جستجوی عمومی
bRegex بولین
اگر true باشد معنی آن این است که میتوان از عبارات باقاعده برای جستجوی عبارتی خاص در کل ستونهای جدول استفاده کرد. مثلا در کادر جستجو نوشت :
که یعنی 1 و 5 همه عددهای بین 1و 5.
sSearch_(int) رشته
فیلتر مخصوص هر ستون. اگر از ویژگی multi column filtering پلاگین استفاده شود به صورت sSearch0 ، sSearch1 ، sSeach2 و ... به طرف سرور ارسال میشوند. شماره انتهای هر کدام از پارامترها بیانگر شماره ستون جدول است.
bRegex_(int) بولین
اگر true باشد، بیان میکند که میتوان از عبارت با قاعده در ستون شماره int جهت جستجو استفاده کرد.
bSortable_(int) بولین
مشخص میکند که آیا یک ستون در سمت کلاینت، قابلیت مرتب شدن بر اساس آن وجود دارد یا نه. (در اینجا int اندیس ستون را مشخص میکند)
iSortingCols عدد صحیح
تعداد ستون هایی که باید مرتب سازی بر اساس آنها صورت پذیرد. در صورتی که از امکان multi column sorting استفاده کنید این مقدار میتواند بیش از یکی باشد.
iSortCol_(int) عدد صحیح
شماره ستونی که باید بر اساس آن عملیات مرتب سازی صورت پذیرد.
sSortDir_(int) رشته
نحوه مرتب سازی ؛ شامل صعودی (asc) یا نزولی (desc)
mDataProp_(int) رشته
اسم ستونهای درون جدول را مشخص میکند.
sEcho رشته
اطلاعاتی که datatables از آن برای رندر کردن جدول استفاده میکند.
شکل زیر نشان میدهد که چه پارامترهایی به سرور ارسال میشوند.
بعضی از این پارامترها بسته به تعداد ستونها قابل تغییر هستند. (آن پارامترهایی که آخرشان یک عدد هست که نشان دهنده شماره ستون مورد نظر میباشد)
در پاسخ به هر درخواست XHR که datatables به سرور میفرستد، انتظار دارد تا سرور نیز یک شیء json را با فرمت مخصوص که شامل پارامترهای زیر میشود به او پس بفرستد:
iTotalRecords عدد صحیح
تعداد کل رکوردها (قبل از عملیات جستجو) یا به عبارت دیگر تعداد کل رکوردهای درون آن جدول از دیتابیس که دادهها باید از آن دریافت شوند. تعداد کل رکوردهایی که در طرف سرور وجود دارند. این مقدار فقط برای نمایش به کاربر برگشت داده میشود و نیز از آن برای صفحه بندی هم استفاده میشود.
iTotalDisplayRecords عدد صحیح
تعداد کل رکوردها (بعد از عملیات جستجو) یا به عبارت دیگر تعداد کل رکوردهایی که بعد از عملیات جستجو پیدا میشوند نه فقط آن تعداد رکوردی که به کاربر پس فرستاده میشوند. تعداد کل رکوردهایی که با شرط جستجو مطابقت دارند. اگر کاربر چیزی را جستجو نکرده باشد مقدار این پارامتر با پارامتر iTotalRecords یکسان خواهد بود.
sEcho عدد صحیح
یک عدد صحیح است که در قالب رشته در تعامل بین سرور و کلاینت جا به جا میشود. این مقدار به ازاء هر درخواست تغییر میکند. همان مقداری که مرورگر به سرور میدهد را سرور هم باید به مرورگر تحویل بدهد. برای جلوگیری از حملات XSS باید آن را تبدیل به عدد صحیح کرد. پلاگین DataTables مقدار این پارامتر را برای هماهنگ کردن و منطبق کردن درخواست ارسال شده و جواب این درخواست استفاده میکند. همان مقداری که مروگر به سرور میدهد را باید سرور تحویل به مرورگر بدهد.
sColumns رشته
اسم ستونها که با استفاده از کاما از هم جدا شده اند. استفاده از آن اختیاری است و البته منسوخ هم شده است و در نسخههای جدید jQuery DataTables از آن پشتیبانی نمیشود.
aaData آرایه
همان طور که قبلا هم گفتیم، مقادیر سلول هایی را که باید در جدول نشان داده شوند را در خود نگهداری میکند. یعنی در واقع دادههای جدول در آن ریخته میشوند. هر وقت که DataTables دادههای مورد نیازش را دریافت میکند، سلولهای جدول html مربوطه اش را از روی آرایه aaData ایجاد میکند. تعداد ستونها در این آرایه دو بعدی، باید با تعداد ستونهای جدول html مربوطه به آن یکسان باشد
شکل زیر پارامترها دریافتی از سرور را نشان میدهند:
همان طور که گفتیم، کلاینت به سرور یک سری پارامترها را ارسال میکند و آن پارامترها را هم شرح دادیم. برای دریافت این پارامترها طرف سرور، احتیاج به یک مدل هست. این مدل به صورت زیر پیاده سازی خواهد شد:
مدل بایندر mvc وظیفه مقداردهی به خصوصیات درون این کلاس را بر عهده دارد، بقیه پارامترهایی که به سرور ارسال میشوند و در این کلاس نیامده اند، از طریق شیء Request در دسترس خواهند بود.
اکشن متدی که مدل بالا را دریافت میکند، میتواند به صورت زیر پیاده سازی شود. این اکشن متد وظیفه پاسخ دادن به درخواست DataTables بر اساس پارامترهای ارسال شده در مدل DataTablesParam را دارد. خروجی این اکشن متد شامل پارارمترهای مورد نیاز پلاگین DataTables برای تشکیل جدول است که آنها را هم شرح دادیم.
تشریح اکشن متد GetBrowsers :
این اکشن متد از مدل jQueryDataTableParamModel به عنوان پارامتر ورودی خود استفاده میکند. این مدل همان طور هم که گفتیم، شامل یک سری خصوصیت است که توسط پلاگین jQuery DataTables مقداردهی میشوند و همچنین مدل بایندر mvc وظیفه بایند کردن این مقادیر به خصوصیات درون این کلاس را بر عهده خواهد داشت. درون بدنه اکشن متد GetBrowsers دادهها بعد از اعمال عملیات فیلترینگ، مرتب سازی، و صفحه بندی به فرمت مناسبی درآمده و به طرف مرورگر فرستاده خواهند شد.
برای پیاده سازی کدهای طرف کلاینت نیز، درون یک View کدهای زیر قرار خواهند گرفت:
تشریح کدها:
fnServerData :
این متد، در واقع نحوه تعامل سرور و کلاینت را با استفاده از درخواستهای XHR مشخص خواهد کرد.
oLanguage :
برای فعال سازی زبان فارسی، فیلدهای مورد نیاز ترجمه شده و در یک فایل متنی قرار داده شده اند. کافی است آدرس این فایل متنی به ویژگی oLanguage اختصاص داده شوند.
مثال این قسمت را از لینک زیر دریافت کنید:
DataTablesTutorial04.zip
لازم به ذکر است پوشه bin، obj، و packages جهت کاهش حجم این مثال از solution حذف شده اند. برای اجرای این مثال از اینجا کمک بگیرید.
مطالعه بیشتر
برای مطالعه بیشتر در مورد این پلاگین و نیز پیاده سازی آن در MVC میتوانید به لینک زیر نیز مراجعه بفرمائید که بعضی از قسمتهای این مطلب هم از مقاله زیر استفاده کرده است:
jQuery DataTables and ASP.NET MVC Integration - Part I
قصد داریم تا مانند مثال قسمت قبل، مجموعه ای از اطلاعات مربوط به مرورگرهای مختلف را در یک جدول نشان دهیم، اما این بار منبع داده ما فرق میکند. منبع داده از طرف سرور فراهم میشود. هر مرورگر - همان طور که در قسمت قبل مشاهده نمودید - شامل اطلاعات زیر خواهد بود:
- موتور رندرگیری (Engine)
- نام مرورگر (Name)
- پلتفرم (Platform)
- نسخه موتور (Version)
- نمره سی اس اس (Grade)
به همین دلیل در سمت سرور، کلاسی خواهیم ساخت که نمایانگر یک مرورگر باشد. بدین صورت:
public class Browser { public int Id { get; set; } public string Engine { get; set; } public string Name { get; set; } public string Platform { get; set; } public float Version { get; set; } public string Grade { get; set; } }
این روش، یکی از امکانات jQuery DataTables است که با استفاده از آن، کلاینت تنها یک مصرف کننده صرف خواهد بود و وظیفه پردازش اطلاعات - یعنی تعداد رکوردهایی که برگشت داده میشود، صفحه بندی، مرتب سازی، جستجو، و غیره - به عهده سرور خواهد بود.
برای به کار گیری این روش، اولین کار این است که ویژگی bServerSide را true کنیم، مثلا بدین صورت:
var $table = $('#browsers-grid'); $table.dataTable({ "bServerSide": true, "sAjaxSource": "/Home/GetBrowsers" });
همچنین ویژگی sAjaxSource را به Url ی که باید دادهها از آن دریافت شوند مقداردهی میکنیم.
به صورت پیش فرض مقدار ویژگی bServerSide مقدار false است؛ که یعنی منبع داده این پلاگین از سمت سرور خوانده نشود. اگر true باشد منبع داده و خیلی اطلاعات دیگر مربوط به دادههای درون جدول باید از سرور به مرورگر کاربر پس فرستاده شوند. با true کردن مقدار bServerSide، آنگاه DataTables اطلاعاتی را راجع به شماره صفحه جاری، اندازه هر صفحه، شروط فیلتر کردن داده ها، مرتب سازی ستون ها، و غیره را به سرور میفرستد. همجنین انتظار میرود تا سرور در پاسخ به این درخواست، دادههای مناسبی را به فرمت JSON به مرورگر پس بفرستد. در حالتی که bServerSide مقدار true به خود بگیرد، پلاگین فقط رابطه متقابل بین کاربر و سرور را مدیریت میکند و هیچ پردازشی را انجام نمیدهد.
در این درخواست XHR یا Ajax ی پارامترهایی که به سرور ارسال میشوند اینها هستند:
iDisplayStart عدد صحیح
نقظه شروع مجموعه داده جاری
iDisplayLength عدد صحیح
تعداد رکوردهایی که جدول میتواند نمایش دهد. تعداد رکوردهایی که از طرف سرور برگشت داده میشود باید با این عدد یکسان باشند.
iColumns عدد صحیح
تعداد ستونهایی که باید نمایش داده شوند.
sSearch رشته
فیلد جستجوی عمومی
bRegex بولین
اگر true باشد معنی آن این است که میتوان از عبارات باقاعده برای جستجوی عبارتی خاص در کل ستونهای جدول استفاده کرد. مثلا در کادر جستجو نوشت :
^[1-5]$
bSearchable_(int) بولین
نمایش میدهد که یک ستون در طرف کاربر قابلیت searchable آن true هست یا نه.sSearch_(int) رشته
فیلتر مخصوص هر ستون. اگر از ویژگی multi column filtering پلاگین استفاده شود به صورت sSearch0 ، sSearch1 ، sSeach2 و ... به طرف سرور ارسال میشوند. شماره انتهای هر کدام از پارامترها بیانگر شماره ستون جدول است.
bRegex_(int) بولین
اگر true باشد، بیان میکند که میتوان از عبارت با قاعده در ستون شماره int جهت جستجو استفاده کرد.
bSortable_(int) بولین
مشخص میکند که آیا یک ستون در سمت کلاینت، قابلیت مرتب شدن بر اساس آن وجود دارد یا نه. (در اینجا int اندیس ستون را مشخص میکند)
iSortingCols عدد صحیح
تعداد ستون هایی که باید مرتب سازی بر اساس آنها صورت پذیرد. در صورتی که از امکان multi column sorting استفاده کنید این مقدار میتواند بیش از یکی باشد.
iSortCol_(int) عدد صحیح
شماره ستونی که باید بر اساس آن عملیات مرتب سازی صورت پذیرد.
sSortDir_(int) رشته
نحوه مرتب سازی ؛ شامل صعودی (asc) یا نزولی (desc)
mDataProp_(int) رشته
اسم ستونهای درون جدول را مشخص میکند.
sEcho رشته
اطلاعاتی که datatables از آن برای رندر کردن جدول استفاده میکند.
شکل زیر نشان میدهد که چه پارامترهایی به سرور ارسال میشوند.
شکل ب ) پارامترهای ارسالی به سرور به صورت json
بعضی از این پارامترها بسته به تعداد ستونها قابل تغییر هستند. (آن پارامترهایی که آخرشان یک عدد هست که نشان دهنده شماره ستون مورد نظر میباشد)
در پاسخ به هر درخواست XHR که datatables به سرور میفرستد، انتظار دارد تا سرور نیز یک شیء json را با فرمت مخصوص که شامل پارامترهای زیر میشود به او پس بفرستد:
iTotalRecords عدد صحیح
تعداد کل رکوردها (قبل از عملیات جستجو) یا به عبارت دیگر تعداد کل رکوردهای درون آن جدول از دیتابیس که دادهها باید از آن دریافت شوند. تعداد کل رکوردهایی که در طرف سرور وجود دارند. این مقدار فقط برای نمایش به کاربر برگشت داده میشود و نیز از آن برای صفحه بندی هم استفاده میشود.
iTotalDisplayRecords عدد صحیح
تعداد کل رکوردها (بعد از عملیات جستجو) یا به عبارت دیگر تعداد کل رکوردهایی که بعد از عملیات جستجو پیدا میشوند نه فقط آن تعداد رکوردی که به کاربر پس فرستاده میشوند. تعداد کل رکوردهایی که با شرط جستجو مطابقت دارند. اگر کاربر چیزی را جستجو نکرده باشد مقدار این پارامتر با پارامتر iTotalRecords یکسان خواهد بود.
sEcho عدد صحیح
یک عدد صحیح است که در قالب رشته در تعامل بین سرور و کلاینت جا به جا میشود. این مقدار به ازاء هر درخواست تغییر میکند. همان مقداری که مرورگر به سرور میدهد را سرور هم باید به مرورگر تحویل بدهد. برای جلوگیری از حملات XSS باید آن را تبدیل به عدد صحیح کرد. پلاگین DataTables مقدار این پارامتر را برای هماهنگ کردن و منطبق کردن درخواست ارسال شده و جواب این درخواست استفاده میکند. همان مقداری که مروگر به سرور میدهد را باید سرور تحویل به مرورگر بدهد.
sColumns رشته
اسم ستونها که با استفاده از کاما از هم جدا شده اند. استفاده از آن اختیاری است و البته منسوخ هم شده است و در نسخههای جدید jQuery DataTables از آن پشتیبانی نمیشود.
aaData آرایه
همان طور که قبلا هم گفتیم، مقادیر سلول هایی را که باید در جدول نشان داده شوند را در خود نگهداری میکند. یعنی در واقع دادههای جدول در آن ریخته میشوند. هر وقت که DataTables دادههای مورد نیازش را دریافت میکند، سلولهای جدول html مربوطه اش را از روی آرایه aaData ایجاد میکند. تعداد ستونها در این آرایه دو بعدی، باید با تعداد ستونهای جدول html مربوطه به آن یکسان باشد
شکل زیر پارامترها دریافتی از سرور را نشان میدهند:
شکل ب ) پارامترهای دریافتی از سرور به صورت json
استفاده از روش server side processing در mvcهمان طور که گفتیم، کلاینت به سرور یک سری پارامترها را ارسال میکند و آن پارامترها را هم شرح دادیم. برای دریافت این پارامترها طرف سرور، احتیاج به یک مدل هست. این مدل به صورت زیر پیاده سازی خواهد شد:
/// <summary> /// Class that encapsulates most common parameters sent by DataTables plugin /// </summary> public class jQueryDataTableParamModel { /// <summary> /// Request sequence number sent by DataTable, /// same value must be returned in response /// </summary> public string sEcho { get; set; } /// <summary> /// Text used for filtering /// </summary> public string sSearch { get; set; } /// <summary> /// Number of records that should be shown in table /// </summary> public int iDisplayLength { get; set; } /// <summary> /// First record that should be shown(used for paging) /// </summary> public int iDisplayStart { get; set; } /// <summary> /// Number of columns in table /// </summary> public int iColumns { get; set; } /// <summary> /// Number of columns that are used in sorting /// /// </summary> public int iSortingCols { get; set; } /// <summary> /// Comma separated list of column names /// </summary> public string sColumns { get; set; } }
مدل بایندر mvc وظیفه مقداردهی به خصوصیات درون این کلاس را بر عهده دارد، بقیه پارامترهایی که به سرور ارسال میشوند و در این کلاس نیامده اند، از طریق شیء Request در دسترس خواهند بود.
اکشن متدی که مدل بالا را دریافت میکند، میتواند به صورت زیر پیاده سازی شود. این اکشن متد وظیفه پاسخ دادن به درخواست DataTables بر اساس پارامترهای ارسال شده در مدل DataTablesParam را دارد. خروجی این اکشن متد شامل پارارمترهای مورد نیاز پلاگین DataTables برای تشکیل جدول است که آنها را هم شرح دادیم.
public JsonResult GetBrowsers(jQueryDataTableParamModel param) { IQueryable<Browser> allBrowsers = new Browsers().CreateInMemoryDataSource().AsQueryable(); IEnumerable<Browser> filteredBrowsers; // Apply Filtering if (!string.IsNullOrEmpty(param.sSearch)) { filteredBrowsers = new Browsers().CreateInMemoryDataSource() .Where(x => x.Engine.Contains(param.sSearch) || x.Grade.Contains(param.sSearch) || x.Name.Contains(param.sSearch) || x.Platform.Contains(param.sSearch) ).ToList(); float f; if (float.TryParse(param.sSearch, out f)) { filteredBrowsers = filteredBrowsers.Where(x => x.Version.Equals(f)); } } else { filteredBrowsers = allBrowsers; } // Apply Sorting var sortColumnIndex = Convert.ToInt32(Request["iSortCol_0"]); Func<Browser, string> orderingFunction = (x => sortColumnIndex == 0 ? x.Engine : sortColumnIndex == 1 ? x.Name : sortColumnIndex == 2 ? x.Platform : sortColumnIndex == 3 ? x.Version.ToString() : sortColumnIndex == 4 ? x.Grade : x.Name); var sortDirection = Request["sSortDir_0"]; // asc or desc filteredBrowsers = sortDirection == "asc" ? filteredBrowsers.OrderBy(orderingFunction) : filteredBrowsers.OrderByDescending(orderingFunction); // Apply Paging var enumerable = filteredBrowsers.ToArray(); IEnumerable<Browser> displayedBrowsers = enumerable.Skip(param.iDisplayStart). Take(param.iDisplayLength).ToList(); return Json(new { sEcho = param.sEcho, iTotalRecords = allBrowsers.Count(), iTotalDisplayRecords = enumerable.Count(), aaData = displayedBrowsers }, JsonRequestBehavior.AllowGet); }
تشریح اکشن متد GetBrowsers :
این اکشن متد از مدل jQueryDataTableParamModel به عنوان پارامتر ورودی خود استفاده میکند. این مدل همان طور هم که گفتیم، شامل یک سری خصوصیت است که توسط پلاگین jQuery DataTables مقداردهی میشوند و همچنین مدل بایندر mvc وظیفه بایند کردن این مقادیر به خصوصیات درون این کلاس را بر عهده خواهد داشت. درون بدنه اکشن متد GetBrowsers دادهها بعد از اعمال عملیات فیلترینگ، مرتب سازی، و صفحه بندی به فرمت مناسبی درآمده و به طرف مرورگر فرستاده خواهند شد.
برای پیاده سازی کدهای طرف کلاینت نیز، درون یک View کدهای زیر قرار خواهند گرفت:
$(function () { var $table = $('#browsers-grid'); $table.dataTable({ "bProcessing": true, "bStateSave": true, "bServerSide": true, "bFilter": true, "sDom": 'T<"clear">lftipr', "aLengthMenu": [[5, 10, 25, 50, -1], [5, 10, 25, 50, "All"]], "bAutoWidth": false, "sAjaxSource": "/Home/GetBrowsers", "fnServerData": function (sSource, aoData, fnCallback) { $.ajax({ "dataType": 'json', "type": "POST", "url": sSource, "data": aoData, "success": fnCallback }); }, "aoColumns": [ { "mDataProp": "Engine" }, { "mDataProp": "Name" }, { "mDataProp": "Platform" }, { "mDataProp": "Version" }, { "mDataProp": "Grade" } ], "oLanguage": { "sUrl": "/Content/dataTables.persian.txt" } }); });
تشریح کدها:
fnServerData :
این متد، در واقع نحوه تعامل سرور و کلاینت را با استفاده از درخواستهای XHR مشخص خواهد کرد.
oLanguage :
برای فعال سازی زبان فارسی، فیلدهای مورد نیاز ترجمه شده و در یک فایل متنی قرار داده شده اند. کافی است آدرس این فایل متنی به ویژگی oLanguage اختصاص داده شوند.
مثال این قسمت را از لینک زیر دریافت کنید:
DataTablesTutorial04.zip
لازم به ذکر است پوشه bin، obj، و packages جهت کاهش حجم این مثال از solution حذف شده اند. برای اجرای این مثال از اینجا کمک بگیرید.
مطالعه بیشتر
برای مطالعه بیشتر در مورد این پلاگین و نیز پیاده سازی آن در MVC میتوانید به لینک زیر نیز مراجعه بفرمائید که بعضی از قسمتهای این مطلب هم از مقاله زیر استفاده کرده است:
jQuery DataTables and ASP.NET MVC Integration - Part I
با عرض سلام و خسته نباشید و تبریک سال نو :
من با نرم افزار StimulSoft کار میکنم ولی مشکلی در نمایش فونت گزارشات تحت وب دارم به طوری که وقتی مثلاً برای اطلاعات فونت Lotus را تنظیم میکنم در خروجی گزارش تحت وب به فرمت Pdf یا Excel فونت مذکور به یکی از فونتهای پیش فرض تبدیل میشه، البته در دوحالت هم تست کردم حالتی که سرور هاستینک دردسترس خودم بود و فونتها نیز نصب شد و حالتی که بررروی هاستهای خریداری شده که در هر دوحالت مثلا فونت arial نمایش میدهد، ناگفته نماند در سیستمهای تحت ویندوز این مشکل وجود ندارد و همچنین همین گزارش را از طریق ویژوال استدیو سیستم خودم که صدا میزنم مشکلی در فونت ندارد.
ممنون میشم اگر کمک بفرمایید.
نظرات مطالب
مفاهیم برنامه نویسی ـ آشنایی با سازندهها
تشکر از نظر شما.
اگر مورد خاصی مد نظر دارید بفرمایید تا توضیح بدم یا در صورت لزوم در متن اصلاح کنم. در نظر داشته باشید این سری مطالب با مطالب دیگر موجود در سایت متفاوت است و هدف خاصی را دنبال میکند که در بخش اول توضیح داده شد. بنابراین نمیتوان در این سری مطالب نگران کاربر مبتدیتر نبود چراکه جامعه هدف این بحثها هستند. به دلیل همین جامعه هدف مورد نظر، نوشتن این گونه مطالب دشوارتر از بیان مفاهیم پیچیدهتر برای کاربران حرفهایتر است. و همین امر به علاوه وقت محدود بنده سبب تأخیر در ارسال مطالب است. ضمناً صرف بیان انبوهی از اطلاعات تأثیر لازم را در خواننده نمیگذارد. در بسیاری مواقع بیان برخی مفاهیم مهندسی نرم افزار یا ویژگیهای جدید زبان (مانند var) به صورت مقایسه ای با روش پیشین سبب تثبیت بهتر مطالب در ذهن خواننده میشود. اما در شیوه کد نویسی تا حد ممکن سعی شده اصول رعایت شود و بیهوده خواننده با روش ناصحیح آشنا نشود. اگر نکته خاصی یافتید بفرمایید اصلاح کنیم.
اگر مورد خاصی مد نظر دارید بفرمایید تا توضیح بدم یا در صورت لزوم در متن اصلاح کنم. در نظر داشته باشید این سری مطالب با مطالب دیگر موجود در سایت متفاوت است و هدف خاصی را دنبال میکند که در بخش اول توضیح داده شد. بنابراین نمیتوان در این سری مطالب نگران کاربر مبتدیتر نبود چراکه جامعه هدف این بحثها هستند. به دلیل همین جامعه هدف مورد نظر، نوشتن این گونه مطالب دشوارتر از بیان مفاهیم پیچیدهتر برای کاربران حرفهایتر است. و همین امر به علاوه وقت محدود بنده سبب تأخیر در ارسال مطالب است. ضمناً صرف بیان انبوهی از اطلاعات تأثیر لازم را در خواننده نمیگذارد. در بسیاری مواقع بیان برخی مفاهیم مهندسی نرم افزار یا ویژگیهای جدید زبان (مانند var) به صورت مقایسه ای با روش پیشین سبب تثبیت بهتر مطالب در ذهن خواننده میشود. اما در شیوه کد نویسی تا حد ممکن سعی شده اصول رعایت شود و بیهوده خواننده با روش ناصحیح آشنا نشود. اگر نکته خاصی یافتید بفرمایید اصلاح کنیم.
جلسه دوم :
در جلسه پیش در مورد اینکه چرا یک بسته نرم افزاری را باید به عنوان یک سیستم در نظر بگیریم صحبت کردیم در این جلسه به بررسی سیستمهای اطلاعاتی میپردازیم.
قبل از اینکه به بررسی سیستم های اطلاعاتی بپردازیم به چند مفهوم میپردازیم که برای تعریف سیستمهای اطلاعاتی به آنها نیازمندیم.
· داده – Data : داده خام پردازش نشده ای که از نظر سیستم مفهومی ندارد.
· اطلاعات - Information : دادههای پردازش شده ای که از نظر سیستم دارای مفهوم خاصی میباشند.
· Knowledge : مانند Information دارای مفهوم خاصی هستند اما کمی ساخت یافتهتر گشته و دارای معنی بیشتری هستند و اغلب در سیستمهای خبره به کار میروند.
تعریف سیستمهای اطلاعاتی (Information Service)
سیستم هایی هستند که ورودی آنها اطلاعات خام پردازش نشده (Data) و خروجی آنها Information میباشد ؛ عمل اصلی این سیستمها پردازش اطلاعات است .
انواع سیستمهای اطلاعاتی :
1. TPS (Transaction Processing Systems)
عملکرد اصلی TPS ها پردازش اطلاعات است.
2. MIS (Management Information Services)
اطلاعات را برای مدیران سطح بالا پردازش میکنند و آ نها را در تصمیم گیریها یاری میدهند.
در ادامه به بررسی مشکلات سیستمهای اطلاعاتی یا همان بستههای نرم افزاری خواهیم پرداخت و راهکاری را که IT برای فایق آمدن به این مشکلات بیان کرده اند را شرح خواهم داد.
برخی مشکلات توسعه سیستمهای اطلاعاتی (IS) :
1. قیمت پیشنهادی از سوی کارفرما
2. زمان تحویل سیستم غیر معقول باشد
3. هزینه استقرار سیستم بالا باشد
4. تغییر نیازمندی ها
5. کمبود تجربه و تخصص نیروی فنی
6. غیر ممکن بودن پیاده سازی یک سیستم از لحاظ تکنیکی
7. اندازه گیری میزان حرکت پروژه در راستای هدف خود
8. پروژه تا چه اندازه نیازمندیهای کاربران را پاسخ میدهد
9. سختی کار با سیستم
10. سیستم از ورود اطلاعات نامعتبر جلوگیری نکند
11. پیغامهای خطای نامناسب
12. Help نامناسب
13. غیر قابل اعتماد بودن عملیاتهای سیستم
14. زمان پاسخ گویی نامناسب
15. ...
قبل از اینکه به بیان راهکار IT در این رابطه بپردازیم به تعریفی کوتاه از آن توجه کنید.
IT چیست:
IT راهکاری برای مقابله با مشکلات تولید و توسعه نرم افزار میباشد. نیاز به پیاده سازی سیستمهای اطلاعاتی منجر به پیدایش مفهوم IT شد. پاسخ IT برای فایق آمدن بر مشکلات تولید و توسعه نرم افزار استفاده از متدولوژی است.
در ادامه به بررسی متدولوژی خواهیم پرداخت.
در جلسه پیش در مورد اینکه چرا یک بسته نرم افزاری را باید به عنوان یک سیستم در نظر بگیریم صحبت کردیم در این جلسه به بررسی سیستمهای اطلاعاتی میپردازیم.
قبل از اینکه به بررسی سیستم های اطلاعاتی بپردازیم به چند مفهوم میپردازیم که برای تعریف سیستمهای اطلاعاتی به آنها نیازمندیم.
· داده – Data : داده خام پردازش نشده ای که از نظر سیستم مفهومی ندارد.
· اطلاعات - Information : دادههای پردازش شده ای که از نظر سیستم دارای مفهوم خاصی میباشند.
· Knowledge : مانند Information دارای مفهوم خاصی هستند اما کمی ساخت یافتهتر گشته و دارای معنی بیشتری هستند و اغلب در سیستمهای خبره به کار میروند.
تعریف سیستمهای اطلاعاتی (Information Service)
سیستم هایی هستند که ورودی آنها اطلاعات خام پردازش نشده (Data) و خروجی آنها Information میباشد ؛ عمل اصلی این سیستمها پردازش اطلاعات است .
انواع سیستمهای اطلاعاتی :
1. TPS (Transaction Processing Systems)
عملکرد اصلی TPS ها پردازش اطلاعات است.
2. MIS (Management Information Services)
اطلاعات را برای مدیران سطح بالا پردازش میکنند و آ نها را در تصمیم گیریها یاری میدهند.
در ادامه به بررسی مشکلات سیستمهای اطلاعاتی یا همان بستههای نرم افزاری خواهیم پرداخت و راهکاری را که IT برای فایق آمدن به این مشکلات بیان کرده اند را شرح خواهم داد.
برخی مشکلات توسعه سیستمهای اطلاعاتی (IS) :
1. قیمت پیشنهادی از سوی کارفرما
2. زمان تحویل سیستم غیر معقول باشد
3. هزینه استقرار سیستم بالا باشد
4. تغییر نیازمندی ها
5. کمبود تجربه و تخصص نیروی فنی
6. غیر ممکن بودن پیاده سازی یک سیستم از لحاظ تکنیکی
7. اندازه گیری میزان حرکت پروژه در راستای هدف خود
8. پروژه تا چه اندازه نیازمندیهای کاربران را پاسخ میدهد
9. سختی کار با سیستم
10. سیستم از ورود اطلاعات نامعتبر جلوگیری نکند
11. پیغامهای خطای نامناسب
12. Help نامناسب
13. غیر قابل اعتماد بودن عملیاتهای سیستم
14. زمان پاسخ گویی نامناسب
15. ...
قبل از اینکه به بیان راهکار IT در این رابطه بپردازیم به تعریفی کوتاه از آن توجه کنید.
IT چیست:
IT راهکاری برای مقابله با مشکلات تولید و توسعه نرم افزار میباشد. نیاز به پیاده سازی سیستمهای اطلاعاتی منجر به پیدایش مفهوم IT شد. پاسخ IT برای فایق آمدن بر مشکلات تولید و توسعه نرم افزار استفاده از متدولوژی است.
در ادامه به بررسی متدولوژی خواهیم پرداخت.
عموما برنامههای بزرگ NET.، به چندین زیر پروژه شکسته میشوند تا مدیریت آنها سادهتر شود. مهمترین مشکلی که در این حالت پس از مدتی بروز میکند، هماهنگ نگه داشتن شماره نگارشهای ارجاعات NuGet این پروژهها است و همچنین به روز رسانی مکرر و هر بارهی تمام این فایلهای csproj. به همین جهت ایدهی مدیریت مرکزی شماره نگارشهای ارجاعات پروژههای NuGet قرار است به نگارش بعدی آن اضافه شود که البته هم اکنون نیز قسمتی از آن در NET Core SDK 3.1.300. به بعد، قابل استفادهاست که جزئیات آنرا در ادامه مرور میکنیم.
ایجاد فایل جدید Directory.Packages.props
زمانیکه قرار است شماره نگارشهای بستههای NuGet مختلف مورد استفادهی در برنامه، به صورت مرکزی مدیریت شوند، نیاز به یک مخزن ثبت آنها نیز میباشد. به همین جهت یک فایل جدید را به نام Directory.Packages.props در کنار فایل sln پروژهی خود ایجاد کنید (در ریشهی اصلی پروژه)؛ با این محتوای فرضی:
برای تشکیل این فایل، فایلهای csproj مختلف موجود در solution جاری را یافته و سپس PackageReferenceهای آنها را به فایل props فوق کپی کنید؛ با یک تفاوت مهم: بجای PackageReference اینبار از نام PackageVersion استفاده میشود.
تغییرات مورد نیاز در فایلهای پروژههای موجود
در ادامه مجددا به تمام فایلهای csproj خود مراجعه کرده و ویژگی Version را از آنها حذف کنید؛ مانند:
از این پس دیگر هیچکدام از فایلهای پروژهی شما نباید به همراه قید صریح شماره نگارش بستههای مورد استفاده باشند؛ در غیر اینصورت در حین Build پروژه، خطای زیر را دریافت خواهید کرد:
همچنین اگر دقت کرده باشید، ویژگی جدید ManagePackageVersionsCentrally نیز به این فایل پروژه و سایر فایلهای پروژه نیز باید اضافه شود. حالت پیشفرض آن false است.
یک نکته: میتوان ویژگی ManagePackageVersionsCentrally را نیز به صورت سراسری به فایل Directory.Packages.props اضافه کرد تا به صورت خودکار به تمام فایلهای csproj موجود، اعمال شود:
نحوهی افزودن بستههای جدید
قابلیتی که تا اینجا معرفی شد، در NET Core SDK 3.1.300. به بعد قابل دسترسی و استفادهاست (و پس از این تغییرات، برنامه بدون مشکل کامپایل میشود)؛ اما هنوز NET Core CLI. برای افزودن خودکار بستههای جدید NuGet به این سیستم، به روز رسانی نشدهاست. یعنی فعلا اگر خواستید بستهی جدیدی را اضافه کنید باید ابتدا به صورت دستی PackageVersion آنرا در فایل Directory.Packages.props ثبت کنید و سپس PackageReference بدون شمارهی نگارش را نیز به پروژهی مدنظر خود به صورت دستی اضافه کنید.
برای مطالعه بیشتر
مستندات رسمی آن
وضعیت پیاده سازی آن
ایجاد فایل جدید Directory.Packages.props
زمانیکه قرار است شماره نگارشهای بستههای NuGet مختلف مورد استفادهی در برنامه، به صورت مرکزی مدیریت شوند، نیاز به یک مخزن ثبت آنها نیز میباشد. به همین جهت یک فایل جدید را به نام Directory.Packages.props در کنار فایل sln پروژهی خود ایجاد کنید (در ریشهی اصلی پروژه)؛ با این محتوای فرضی:
<Project> <ItemGroup> <PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" /> <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" /> </ItemGroup> </Project>
تغییرات مورد نیاز در فایلهای پروژههای موجود
در ادامه مجددا به تمام فایلهای csproj خود مراجعه کرده و ویژگی Version را از آنها حذف کنید؛ مانند:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.Extensions.Localization.Abstractions" /> <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" /> </ItemGroup> </Project>
error NU1008: Projects that use central package version management should not define the version on the PackageReference items
همچنین اگر دقت کرده باشید، ویژگی جدید ManagePackageVersionsCentrally نیز به این فایل پروژه و سایر فایلهای پروژه نیز باید اضافه شود. حالت پیشفرض آن false است.
یک نکته: میتوان ویژگی ManagePackageVersionsCentrally را نیز به صورت سراسری به فایل Directory.Packages.props اضافه کرد تا به صورت خودکار به تمام فایلهای csproj موجود، اعمال شود:
<Project> <PropertyGroup> <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally> </PropertyGroup> <ItemGroup> <PackageVersion Include="Microsoft.Extensions.Localization.Abstractions" Version="3.1.8" /> <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="3.1.8" /> </ItemGroup> </Project>
نحوهی افزودن بستههای جدید
قابلیتی که تا اینجا معرفی شد، در NET Core SDK 3.1.300. به بعد قابل دسترسی و استفادهاست (و پس از این تغییرات، برنامه بدون مشکل کامپایل میشود)؛ اما هنوز NET Core CLI. برای افزودن خودکار بستههای جدید NuGet به این سیستم، به روز رسانی نشدهاست. یعنی فعلا اگر خواستید بستهی جدیدی را اضافه کنید باید ابتدا به صورت دستی PackageVersion آنرا در فایل Directory.Packages.props ثبت کنید و سپس PackageReference بدون شمارهی نگارش را نیز به پروژهی مدنظر خود به صورت دستی اضافه کنید.
برای مطالعه بیشتر
مستندات رسمی آن
وضعیت پیاده سازی آن
- تجاربی از LibreOffice | blog.afsharm.com
- بدست آوردن عدد بعدی تولید شده برای ستون ID در SQL | محمد | mds-soft.persianblog.ir
- پسرفت ایران در خدمات اینترنتی « وب شهر» | webshahr.org
- دنیس ریچی، خالق C درگذشت | آرش | azadrah.net
- دنیس ریچی، خالق زبان برنامه نویسی C و یونیکس درگذشت | X3RO | potatozone.com
- ضبط برنامه های رادیویی و تلویزیونی شبکه های صدا و سیما از طریق اینترنت دانلود منیجر | mohammaddesign | mohammaddesign.wordpress.com
- متوسط سالانه حقوق مهندسان نرم افزار آمریکا، ۱۰۹ هزار دلار در سال ۲۰۱۰ | mKeshavarzi | www.barsam.ir
- HTML5 و نمایش زیرنویس | blogs.msdn.com
- امکان دیباگ بهتر کدهای حالت Release در VS.NET 11 | blogs.microsoft.co.il
- بررسی تازههای TFS 11 | geekswithblogs.net
- خالق زبان C درگذشت | hadihariri.com