با تغییرات اخیر Google Analytics، تعداد بار مراجعه کاربران «sessions» و کاربران منحصربفرد مراجعه کننده به سایت «users» نام گرفته‌اند. 
Docker به صورت ساده، پلتفرمی است که به سادگی قابلیت ساخت، انتقال و اجرا کردن Imageها را در اختیار دارد و همچنین به صورت native درون سرور‌های لینوکسی و ویندوزی اجرا میشود؛ به علاوه اینکه در محیط محلی، برای تست نیز بر روی ماشین‌های ویندوزی و مک از طریق virtual machine قابل اجراست.
دو مفهوم اساسی در محیط Docker وجود دارند که دانستن آنها ضروری است: Image و Container
image عملا چیزی است که از آن برای Build یک Container استفاده میشود. image دارای یک سری فایل‌های لازم و اساسی است که باعث میشود بر روی یک Operation System اجرا شود؛ مثل Ubuntu یا Windows. بنابراین شما Application Framework خود را خواهید داشت و همچنین Databaseی که با آن کار میکند. بنابراین قابلیت استفاده از زبان‌ها و فریم ورک‌های مختلف چون Asp.net Core, Nodejs, Python و غیره را خواهد داشت. یک image به خودی خود غیر قابل استفاده است تا زمانیکه بر روی یک Container توزیع شده باشد، تا قابلیت اجرا پیدا کند. بنابراین نقطه‌ی شروع اصلی اجرایی یک برنامه با Container مربوط به آن میباشد.
به صورت خلاصه Image یک template از نوع Readonly است که ترکیبی از لایه‌های File System میباشد، به همراه فایل‌های share شده‌ی دیگر (از قبیل فریم ورک‌ها و ...) که میتوانند یک Docker Container Instance را تولید نمایند.
Container یک محیط امن و ایزوله است که به وسیله‌ی image ساخته شده است و میتواند اجرا، متوقف، منتقل و یا حذف شود (بطور قابل ملاحظه‌ای اجرا کردن و متوقف کردن آن سریع میباشد).
تفاوت Docker Containers و Virtual Machines
Virtual Machines همیشه بر روی Host Operation System اجرا میشوند (که میتواند بر روی ویندوز یا لینوکس باشد) و بعد از آن اجرای Guest OS بر روی سطحی به نام Hypervisor. پس میتوان گفت یک کپی کامل از سیستم عامل است که که بر روی hypervisor اجرا میشود و خودش نیز بر روی سخت افزار اجرا میشود. بنابراین میتوان مثل شکل زیر، یک App داشت که عملا یک سری باینری و کتابخانه است و اگر قرار باشد بر روی سیستم عامل‌های مختلفی کار کند، احتیاج به کپی کردن کل آن میباشد و بطور واضحی زمان و هزینه‌ی بیشتری برای بالا آوردن آن لازم است.
اما بر خلاف آن، داکر با استفاده از ابزاری به نام Docker Engine کار میکند که میتواند Containerهای مختلفی از OSهای مختلف را اجرا نماید و نیازی به کپی گرفتن از کل سیستم عامل برای اجرای هر container نخواهد بود.
بنابراین با استفاده از ابزارهای مجازی سازی چون Vmware، نسخه‌ی کاملی را از سیستم عامل مطبوع خود میتوان نصب و اجرا نمود؛ اما برخلاف آن با استفاده از داکر، یک نسخه‌ی کوچک از سیستم عامل، بدون وابستگی‌ها و پیچیدگی‌های نسخه‌ی اصلی در اختیار خواهد بود.
با این وجود، بوسیله داکر به راحتی میتوان تعداد زیادی از Containerها را به راحتی و با سرعت بالا اجرا نموده و مورد تست و ارزیابی قرار داد.
چطور Docker میتواند سریعتر از Virtual Machineها عمل کند ؟
داکر از چیزی به نام Copy On Write استفاده میکند؛ به معنای کپی کردن همزمان با نوشتن. همانطور که گفته شد هر Container از یک Image ساخته میشود و عملا Imageها همان FileSystemهای از قبل تولید شده هستند و هر کدام از لایه‌ای از کتابخانه‌ها استفاده میکنند که برای اجرای برنامه‌های کاربردی مورد استفاده قرار می‌گیرند. سرور آپاچی را در نظر بگیرید، به عنوان یک فایل image که FileSystem بر روی آن ذخیره شده‌است. با نصب Php یک لایه بر روی لایه دیگر ایجاد شده و فقط تغییرات جدید به آن اضافه خواهند شد و حال اگر بخواهید تغییری را بر روی source code خود بدهید، عملا فقط آن تغییر به Image و FileSystem اضافه خواهد شد. این معماری لایه لایه باعث تولید یک FileSystem بصورت read-only میشود که شامل لایه‌های متفاوتی است و سبب کم حجم شدن آن، بالا رفتن سرعت آن میشود و همچنین با استفاده از Caching، قدرت زیادی را بدان میبخشد.
پس همانطور که در شکل فوق مشاهده میکنید، هر image از لایه‌های مختلفی تشکیل شده است و توانایی به اشتراک گذاشتن این لایه‌های متمایز از یکدیگر در Containerها وجود دارد.
بنابراین طبق شکل فوق، بحث را اینگونه خلاصه میکنیم که هر Image از ترکیبی از لایه‌هایی از نوع read-only تشکیل شده است و با اضافه شدن Container، عملا یک لایه‌ی دیگری که قابلیت read/write را دارد بر روی آن اضافه میشود و درون آن source code میتواند قرار گیرد و اینکه بر مبنای شکل زیر میبینید که قابلیت به اشتراک گذاری Image layerها به Containerهای مختلف تعبیه شده است که باعث میشود لایه‌ی نصب شده بر روی سیستم، بصورت اشتراکی قابل استفاده‌ی مجدد باشد و فضای دیسک کمتری، به علاوه سرعت اجرای بالاتری را داشته باشد. هر لایه یک مقدار هش شده‌ی یکتایی را در اختیار دارد تا از لایه‌های دیگر تمیز داده شود و قابل شناسایی باشد.
داکر در شبکه چگونه کار میکند؟
ضمنا نکته‌ی قابل توجه که در مقاله‌های بعدی به صورت عملی به آن میپردازیم این است که با استفاده از داکر میتوانیم وب سرورهایی را بر روی Containerهای مختلفی داشته باشیم که همگی بر روی پورت بطور مثال 80 هستند؛ طوری که درون هر Container بدلیل ایزوله بودن پروسس‌های مخصوص Container مربوط به خود، به پورت‌های باز داخل آن شبکه دسترسی دارند و میتوانند پورت در نظر گرفته شده‌ی درون Container را با پورت دیگری بیرون Container به اصطلاح Expose نمایند.
ضمن اینکه نکته‌ی دیگری که وجود دارد، ارتباط Containerها با یکدیگر است. برای مثال یک Container برای Database و دیگری برای WebApp میباشد که باید به همدیگر link شده تا قابل استفاده گردند و عملا نیازی به نوشتن ip یکدیگر در این حالت وجود ندارد. البته راه‌های دیگری از قبیل Compose کردن نیز وجود دارد که در ادامه بیشتر با آنها آشنا خواهیم شد.
Docker Volume چیست؟
بحث دیگری که وجود دارد، Volumeها هستند که قسمتی از FileSystemها میباشند و بصورت ساده، مثال کاربردی‌اش میتواند قسمتی از یک سیستم و دایرکتوری خاصی را بر روی Container خاصی Map کردن باشد و عملا داخل آن دایرکتوری میتواند source code بوده باشد (یکی از راه‌های ممکن برای map کردن source code به container) و بر روی Container ایجاد شود.
فوایدی که با استفاده از Volumeها میتوان به آن رسید از قبیل موارد زیر میباشند:
قابلیت به اشتراک گذاری یک Volume بین Containerهای مختلف که به شدت میتواند قابل استفاده باشد.
Data Volumeها ماندگار هستند. یعنی حتی بعد از اینکه Container مربوطه را حذف نمایید، volume مربوط به آن بطور اتوماتیک حذف نمیشود (مگر اینکه خودتان دستور حذف کردن آن را وارد نمایید). پس عملا قابلیت استفاده‌ی مجدد را نیز خواهد داشت.
DockerFile و ساخت imageها چگونه است؟
روش دیگر برای اجرای source code در داکر، ساخت یک image اختصاصی از آن و اجرا کردن آن بر روی یک container مجزا است. با استفاده از DockerFile میتوانید imageهای خود را build کرده که عملا هر image در آخر باید به یک سیستم عامل برسد و همانطور که گفته شد به صورت لایه‌ای کار میکنند و مراتب اجرای آن از قبیل working directory و expose کردن بر روی پورتی خاص، همچنین استفاده از Environment Variableها میباشد و همچنین با استفاده از DockerHub (که نسخه‌ی enterprise نیز دارد) میتوان imageهای ساخته شده را بر روی cloud نگه داشت و همه‌ی اعضای تیم از یک image بخصوص استفاده کنند؛ برای مثال همه‌ی اعضای تیم از یک نسخه‌ی Nodejs استفاده کنند و اشتباها بر روی ماشین‌های توسعه‌ی مختلف برنامه نویسان، از نسخه‌های مختلفی استفاده نشود و همچنین روند به‌روز رسانی به سادگی انجام گیرد.
مزایای Docker برای برنامه نویسان
فرض کنید که یک App Service از Azure تهیه کرده باشید. تست‌های unit, integration, acceptance را انجام داده و با خیال راحت Container خود را از طریق برای مثال Visual studio team service بر روی App service به صورت انتشار از طریق مدل Continuous Integration و Continuous Deployment داشته باشید. پس عملا داکر به Devops بودن محیط و چابک بودن تیم توسعه کمک شایانی کرده و فرآیند‌های سخت و زمانبر انتقال Codeها از محیط توسعه به محیط انتشار را تسریع میبخشد.
بنابراین از داکر به راحتی میتوان در محیط Production نیز استفاده کرد و مزایای فوق العاده ای را برای برنامه نویسان ارائه کرده است. بطور مثال فرض کنید در تولید نرم‌افزار یک Web server ، تعدادی Database و یک Caching server که کانفیگ کردن، اجرا و ... به صورت عادی بسیار صعب و مشکل ساز بوده را به راحتی میتوان اجرا نمود. ضمن اینکه ممکن است هر کدام از ابزارهایی که استفاده شده، فقط مخصوص سیستم عاملی خاص باشد که قاعدتا احتیاج به بالا آوردن Virtual Machine خواهید بود و در سناریو‌های خاصی مثل سیستم هایی با معماری Microservice که هر کدام از این ریز سرویس‌ها ممکن است زبان، فریم ورک، دیتابیس و ... مخصوص به خود را داشته باشند، عملا کار بسیار سخت و پر هزینه خواهد بود (ضمن اینکه استفاده‌ی همزمان از چند Virtual Machine در کنار هم در محیط توسعه، حجم زیادی از memory و disk سیستم شما را خواهد گرفت و شما را مجبور به ارتقای سیستم خود خواهد کرد!).
مشکل دیگری که Docker آن را حل کرده، Conflictهای ورژن‌های مختلف ابزارهای مورد استفاده است. به راحتی میتوان Containerی از Imageها را به صورت ایزوله با ورژن‌های مختلفی ایجاد کرد تا بطور کامل برنامه نویسان را از مشکل همیشگی به‌روزرسانی‌ها و Role-back کردن‌ها آسوده خاطر نماید.
از آنجایی که داکر قابلیت اجرای در محیط production را نیز دارد، عملا محیط Development با محیط Production تفاوتی ندارد و این جمله‌ی معروف که «در سیستم من کار میکند اما در نسخه‌ی انتشار داده شده خیر» دیگر اتفاق نخواهد افتاد.
به راحتی میتوانید از یک Image خاص، Containerهای ایزوله‌ی متفاوتی را ساخته و همگی آنها را در کنار هم اجرا نمود و مورد تست و ارزیابی قرار داد.
Dokcer hub
مخرنی است از هزاران Image آماده از قبیل سیستم عامل، فریم ورک و... که قابلیت استفاده‌ی مجدد خواهد داشت. همچنین شما میتوانید Imageهای خود را نیز بدان اضافه نموده تا دیگران از آن استفاده نمایند. استفاده از مخزن‌های public آن رایگان میباشد. از آنجایی که Docker یک محصول متن باز و رایگان است، یک بخش از درآمد‌های آن از فروش اختصاصی مخزن‌ها در DokcerHub میباشد (چیزی شبیه به Private Repository در Github).
بیشتر از این به مفاهیم نمیپردازیم. برای مطالعه‌ی بیشتر، کتاب فوق العاده‌ی Mastering Docker را پیشنهاد میکنم.
شروع به کار با Docker
بعد از نصب کردن نسخه‌ی رسمی Docker و باز کردن ترمینال مربوطه، اولین دستوراتی را که باید با آن آشنا باشیم، شامل موارد زیر میباشد:
لیست Imageهای کش شده‌ی بر روی سیستم:
لیست containerهای در حال اجرای بر روی ماشین محلی:
بعد از تست کردن دو دستور فوق مشاهده میکنید که هیچ image و containerی بر روی سیستم شما وجود ندارد.
برای آزمایش کردن و نصب اولین image، دستور زیر را وارد میکنیم (میتوانید اطلاعات بیشتری از imageها را در dockerHub پیدا کنید). من در اینجا kitematic/hello-world-nginx را به عنوان image از مخزن dokcerhub، بر روی سیستم خود pull کرده‌ام (این یک نسخه‌ی بسیار سبک از کانتینر nginx میباشد).
بعد از اجرای دوباره‌ی دستور docker images مشاهده میکنید که image مربوطه بر روی سیستم شما نصب شده است.
حال وقت اجرای این image و توزیع آن بر روی container میباشد که با استفاده از دستور زیر است:
پرچم p- برای مقدار دهی پورت خارجی و داخلی میباشد و بعد از آن هم که نام image مربوطه برای اجرای container میباشد (فلگ‌های خیلی بیشتر و تخصصی‌تری در رابطه با اجرا وجود دارند که در ادامه بیشتر مورد بحث قرار می‌گیرند) .
بعد از اجرای این دستور میتوانید با وارد کردن ip مربوط به virtual machine ساخته شده بر روی سیستم خود (اگر از مک یا ویندوز استفاده میکنید احتمالا 192.168.99.100 خواهد بود) که البته با دستور docker-machine ip میتوانید آن را پیدا کنید و وارد کردن آن بر روی مرورگر خود، تصویری مثل زیر را مشاهده کنید:
دو مفهوم اساسی در محیط Docker وجود دارند که دانستن آنها ضروری است: Image و Container
image عملا چیزی است که از آن برای Build یک Container استفاده میشود. image دارای یک سری فایل‌های لازم و اساسی است که باعث میشود بر روی یک Operation System اجرا شود؛ مثل Ubuntu یا Windows. بنابراین شما Application Framework خود را خواهید داشت و همچنین Databaseی که با آن کار میکند. بنابراین قابلیت استفاده از زبان‌ها و فریم ورک‌های مختلف چون Asp.net Core, Nodejs, Python و غیره را خواهد داشت. یک image به خودی خود غیر قابل استفاده است تا زمانیکه بر روی یک Container توزیع شده باشد، تا قابلیت اجرا پیدا کند. بنابراین نقطه‌ی شروع اصلی اجرایی یک برنامه با Container مربوط به آن میباشد.
به صورت خلاصه Image یک template از نوع Readonly است که ترکیبی از لایه‌های File System میباشد، به همراه فایل‌های share شده‌ی دیگر (از قبیل فریم ورک‌ها و ...) که میتوانند یک Docker Container Instance را تولید نمایند.
Container یک محیط امن و ایزوله است که به وسیله‌ی image ساخته شده است و میتواند اجرا، متوقف، منتقل و یا حذف شود (بطور قابل ملاحظه‌ای اجرا کردن و متوقف کردن آن سریع میباشد).
تفاوت Docker Containers و Virtual Machines
Virtual Machines همیشه بر روی Host Operation System اجرا میشوند (که میتواند بر روی ویندوز یا لینوکس باشد) و بعد از آن اجرای Guest OS بر روی سطحی به نام Hypervisor. پس میتوان گفت یک کپی کامل از سیستم عامل است که که بر روی hypervisor اجرا میشود و خودش نیز بر روی سخت افزار اجرا میشود. بنابراین میتوان مثل شکل زیر، یک App داشت که عملا یک سری باینری و کتابخانه است و اگر قرار باشد بر روی سیستم عامل‌های مختلفی کار کند، احتیاج به کپی کردن کل آن میباشد و بطور واضحی زمان و هزینه‌ی بیشتری برای بالا آوردن آن لازم است.
اما بر خلاف آن، داکر با استفاده از ابزاری به نام Docker Engine کار میکند که میتواند Containerهای مختلفی از OSهای مختلف را اجرا نماید و نیازی به کپی گرفتن از کل سیستم عامل برای اجرای هر container نخواهد بود.
بنابراین با استفاده از ابزارهای مجازی سازی چون Vmware، نسخه‌ی کاملی را از سیستم عامل مطبوع خود میتوان نصب و اجرا نمود؛ اما برخلاف آن با استفاده از داکر، یک نسخه‌ی کوچک از سیستم عامل، بدون وابستگی‌ها و پیچیدگی‌های نسخه‌ی اصلی در اختیار خواهد بود.
با این وجود، بوسیله داکر به راحتی میتوان تعداد زیادی از Containerها را به راحتی و با سرعت بالا اجرا نموده و مورد تست و ارزیابی قرار داد.
چطور Docker میتواند سریعتر از Virtual Machineها عمل کند ؟
داکر از چیزی به نام Copy On Write استفاده میکند؛ به معنای کپی کردن همزمان با نوشتن. همانطور که گفته شد هر Container از یک Image ساخته میشود و عملا Imageها همان FileSystemهای از قبل تولید شده هستند و هر کدام از لایه‌ای از کتابخانه‌ها استفاده میکنند که برای اجرای برنامه‌های کاربردی مورد استفاده قرار می‌گیرند. سرور آپاچی را در نظر بگیرید، به عنوان یک فایل image که FileSystem بر روی آن ذخیره شده‌است. با نصب Php یک لایه بر روی لایه دیگر ایجاد شده و فقط تغییرات جدید به آن اضافه خواهند شد و حال اگر بخواهید تغییری را بر روی source code خود بدهید، عملا فقط آن تغییر به Image و FileSystem اضافه خواهد شد. این معماری لایه لایه باعث تولید یک FileSystem بصورت read-only میشود که شامل لایه‌های متفاوتی است و سبب کم حجم شدن آن، بالا رفتن سرعت آن میشود و همچنین با استفاده از Caching، قدرت زیادی را بدان میبخشد.
پس همانطور که در شکل فوق مشاهده میکنید، هر image از لایه‌های مختلفی تشکیل شده است و توانایی به اشتراک گذاشتن این لایه‌های متمایز از یکدیگر در Containerها وجود دارد.
بنابراین طبق شکل فوق، بحث را اینگونه خلاصه میکنیم که هر Image از ترکیبی از لایه‌هایی از نوع read-only تشکیل شده است و با اضافه شدن Container، عملا یک لایه‌ی دیگری که قابلیت read/write را دارد بر روی آن اضافه میشود و درون آن source code میتواند قرار گیرد و اینکه بر مبنای شکل زیر میبینید که قابلیت به اشتراک گذاری Image layerها به Containerهای مختلف تعبیه شده است که باعث میشود لایه‌ی نصب شده بر روی سیستم، بصورت اشتراکی قابل استفاده‌ی مجدد باشد و فضای دیسک کمتری، به علاوه سرعت اجرای بالاتری را داشته باشد. هر لایه یک مقدار هش شده‌ی یکتایی را در اختیار دارد تا از لایه‌های دیگر تمیز داده شود و قابل شناسایی باشد.
داکر در شبکه چگونه کار میکند؟
ضمنا نکته‌ی قابل توجه که در مقاله‌های بعدی به صورت عملی به آن میپردازیم این است که با استفاده از داکر میتوانیم وب سرورهایی را بر روی Containerهای مختلفی داشته باشیم که همگی بر روی پورت بطور مثال 80 هستند؛ طوری که درون هر Container بدلیل ایزوله بودن پروسس‌های مخصوص Container مربوط به خود، به پورت‌های باز داخل آن شبکه دسترسی دارند و میتوانند پورت در نظر گرفته شده‌ی درون Container را با پورت دیگری بیرون Container به اصطلاح Expose نمایند.
ضمن اینکه نکته‌ی دیگری که وجود دارد، ارتباط Containerها با یکدیگر است. برای مثال یک Container برای Database و دیگری برای WebApp میباشد که باید به همدیگر link شده تا قابل استفاده گردند و عملا نیازی به نوشتن ip یکدیگر در این حالت وجود ندارد. البته راه‌های دیگری از قبیل Compose کردن نیز وجود دارد که در ادامه بیشتر با آنها آشنا خواهیم شد.
Docker Volume چیست؟
بحث دیگری که وجود دارد، Volumeها هستند که قسمتی از FileSystemها میباشند و بصورت ساده، مثال کاربردی‌اش میتواند قسمتی از یک سیستم و دایرکتوری خاصی را بر روی Container خاصی Map کردن باشد و عملا داخل آن دایرکتوری میتواند source code بوده باشد (یکی از راه‌های ممکن برای map کردن source code به container) و بر روی Container ایجاد شود.
فوایدی که با استفاده از Volumeها میتوان به آن رسید از قبیل موارد زیر میباشند:
قابلیت به اشتراک گذاری یک Volume بین Containerهای مختلف که به شدت میتواند قابل استفاده باشد.
Data Volumeها ماندگار هستند. یعنی حتی بعد از اینکه Container مربوطه را حذف نمایید، volume مربوط به آن بطور اتوماتیک حذف نمیشود (مگر اینکه خودتان دستور حذف کردن آن را وارد نمایید). پس عملا قابلیت استفاده‌ی مجدد را نیز خواهد داشت.
DockerFile و ساخت imageها چگونه است؟
روش دیگر برای اجرای source code در داکر، ساخت یک image اختصاصی از آن و اجرا کردن آن بر روی یک container مجزا است. با استفاده از DockerFile میتوانید imageهای خود را build کرده که عملا هر image در آخر باید به یک سیستم عامل برسد و همانطور که گفته شد به صورت لایه‌ای کار میکنند و مراتب اجرای آن از قبیل working directory و expose کردن بر روی پورتی خاص، همچنین استفاده از Environment Variableها میباشد و همچنین با استفاده از DockerHub (که نسخه‌ی enterprise نیز دارد) میتوان imageهای ساخته شده را بر روی cloud نگه داشت و همه‌ی اعضای تیم از یک image بخصوص استفاده کنند؛ برای مثال همه‌ی اعضای تیم از یک نسخه‌ی Nodejs استفاده کنند و اشتباها بر روی ماشین‌های توسعه‌ی مختلف برنامه نویسان، از نسخه‌های مختلفی استفاده نشود و همچنین روند به‌روز رسانی به سادگی انجام گیرد.
مزایای Docker برای برنامه نویسان
فرض کنید که یک App Service از Azure تهیه کرده باشید. تست‌های unit, integration, acceptance را انجام داده و با خیال راحت Container خود را از طریق برای مثال Visual studio team service بر روی App service به صورت انتشار از طریق مدل Continuous Integration و Continuous Deployment داشته باشید. پس عملا داکر به Devops بودن محیط و چابک بودن تیم توسعه کمک شایانی کرده و فرآیند‌های سخت و زمانبر انتقال Codeها از محیط توسعه به محیط انتشار را تسریع میبخشد.
بنابراین از داکر به راحتی میتوان در محیط Production نیز استفاده کرد و مزایای فوق العاده ای را برای برنامه نویسان ارائه کرده است. بطور مثال فرض کنید در تولید نرم‌افزار یک Web server ، تعدادی Database و یک Caching server که کانفیگ کردن، اجرا و ... به صورت عادی بسیار صعب و مشکل ساز بوده را به راحتی میتوان اجرا نمود. ضمن اینکه ممکن است هر کدام از ابزارهایی که استفاده شده، فقط مخصوص سیستم عاملی خاص باشد که قاعدتا احتیاج به بالا آوردن Virtual Machine خواهید بود و در سناریو‌های خاصی مثل سیستم هایی با معماری Microservice که هر کدام از این ریز سرویس‌ها ممکن است زبان، فریم ورک، دیتابیس و ... مخصوص به خود را داشته باشند، عملا کار بسیار سخت و پر هزینه خواهد بود (ضمن اینکه استفاده‌ی همزمان از چند Virtual Machine در کنار هم در محیط توسعه، حجم زیادی از memory و disk سیستم شما را خواهد گرفت و شما را مجبور به ارتقای سیستم خود خواهد کرد!).
مشکل دیگری که Docker آن را حل کرده، Conflictهای ورژن‌های مختلف ابزارهای مورد استفاده است. به راحتی میتوان Containerی از Imageها را به صورت ایزوله با ورژن‌های مختلفی ایجاد کرد تا بطور کامل برنامه نویسان را از مشکل همیشگی به‌روزرسانی‌ها و Role-back کردن‌ها آسوده خاطر نماید.
از آنجایی که داکر قابلیت اجرای در محیط production را نیز دارد، عملا محیط Development با محیط Production تفاوتی ندارد و این جمله‌ی معروف که «در سیستم من کار میکند اما در نسخه‌ی انتشار داده شده خیر» دیگر اتفاق نخواهد افتاد.
به راحتی میتوانید از یک Image خاص، Containerهای ایزوله‌ی متفاوتی را ساخته و همگی آنها را در کنار هم اجرا نمود و مورد تست و ارزیابی قرار داد.
Dokcer hub
مخرنی است از هزاران Image آماده از قبیل سیستم عامل، فریم ورک و... که قابلیت استفاده‌ی مجدد خواهد داشت. همچنین شما میتوانید Imageهای خود را نیز بدان اضافه نموده تا دیگران از آن استفاده نمایند. استفاده از مخزن‌های public آن رایگان میباشد. از آنجایی که Docker یک محصول متن باز و رایگان است، یک بخش از درآمد‌های آن از فروش اختصاصی مخزن‌ها در DokcerHub میباشد (چیزی شبیه به Private Repository در Github).
بیشتر از این به مفاهیم نمیپردازیم. برای مطالعه‌ی بیشتر، کتاب فوق العاده‌ی Mastering Docker را پیشنهاد میکنم.
شروع به کار با Docker
بعد از نصب کردن نسخه‌ی رسمی Docker و باز کردن ترمینال مربوطه، اولین دستوراتی را که باید با آن آشنا باشیم، شامل موارد زیر میباشد:
لیست Imageهای کش شده‌ی بر روی سیستم:
docker images
docker ps
برای آزمایش کردن و نصب اولین image، دستور زیر را وارد میکنیم (میتوانید اطلاعات بیشتری از imageها را در dockerHub پیدا کنید). من در اینجا kitematic/hello-world-nginx را به عنوان image از مخزن dokcerhub، بر روی سیستم خود pull کرده‌ام (این یک نسخه‌ی بسیار سبک از کانتینر nginx میباشد).
docker pull kitematic/hello-world-nginx
حال وقت اجرای این image و توزیع آن بر روی container میباشد که با استفاده از دستور زیر است:
docker run -p 80:80 kitematic/hello-world-nginx
بعد از اجرای این دستور میتوانید با وارد کردن ip مربوط به virtual machine ساخته شده بر روی سیستم خود (اگر از مک یا ویندوز استفاده میکنید احتمالا 192.168.99.100 خواهد بود) که البته با دستور docker-machine ip میتوانید آن را پیدا کنید و وارد کردن آن بر روی مرورگر خود، تصویری مثل زیر را مشاهده کنید:
در یک نگاه کلی، ASP.NET Web API OData بر روی ASP.NET Web API سوار شده است و مزیت‌های پایه آن را به صورت کامل دارد، شامل Routing، داشتن Action Filterها، احراز هویت و ... همچنین استاندارد OData بر روی استاندارد Rest سوار شده است و مزیت‌های پایه ای آن را دارا میباشد. اما در کنار اینها OData ویژگی هایی دارد، مانند batch request که در پست‌های بعدی توضیح خواهم داد. و همچنین با داشتن Metadata و استفاده از یک OData Client که در JavaScript | C# | Objective-C و ... کتاب خانه‌های مختلفی برای آنها وجود دارد، شما میتوانید به سادگی Proxy سمت کلاینت رو Generate کرده و متدها را فراخوانی کنید. همچنین سازگاری استاندارد دیتا گرید ها، کمبو باکس‌ها و کنترل‌های گوناگون از فریم ورک‌های مختلف از دیگر ویژگی‌های OData است. بخاطر مبتنی بر Rest بودن Web API OData امکان فراخوانی آن با jQuery نیز وجود دارد؛ اما استفاده از OData Clientها میتواند سادگی کار را به شدت بالا ببرد. سازگاری با Owin و امکان اجرای آن بر روی ASP.NET Core نیز از دیگر موارد مهمی است که باید به آن اشاره کنم. در ضمن این استاندارد محدود به مایکروسافت نبوده و در سایر زبان‌ها و پلتفرم‌ها نیز شناخته شده میباشد. برای مثال امکان نوشتن یک OData Server در جاوا یا جاوا اسکریپت نیز وجود دارد.
سلام
کاری که اکسس در اینجا کرده یا SQLite ایی که مثال زدم، مرتب سازی بر اساس کدهای یونیکد این حروف است و کار صحیحی (در بدو امر حداقل) انجام شده: (+)
کد یونیکد "ک" عربی = 1603
کد یونیکد "ی" عربی = 1610
کد یونیکد "ک" فارسی = 1705
کد یونیکد "ی" فارسی = 1740
یعنی این مرتب سازی بر اساس منطق ریاضی صحیح است؛ اما بر اساس فرهنگ ایران خیر. به همین جهت توسعه دهنده‌های بانک‌های اطلاعاتی مجبور شده‌اند تا مفهومی به نام Collation را ارائه بدهند که در بالا در مورد آن بحث شد. این Collation دیگر صرفا بر اساس منطق ریاضی کدهای یونیکد حروف، مرتب سازی را انجام نمی‌دهد، بلکه بر اساس ادبیات و فرهنگ زبان‌های مختلف کار مرتب سازی را انجام خواهد داد. SQL Server در این زمینه حداقل برای فارسی زبان‌ها یک Collation مخصوص را در نگارش 2008 خودش ارائه داده تا مرتب سازی صورت گرفته روی رشته‌ها دقیقا مطابق فرهنگ و ادبیات ایرانی باشد (برای سایر کشورها هم این نوع Collation ها پیش بینی شده).
در اکسس که مد نظر شما است این Collation به نام General Sort order مهیا است (در اکسس‌های جدید در قسمت فایل، options و سپس برگه‌ی general قسمتی هست به نام new database sort order که همین collation است) (+)
و اگر در این مورد خاص درست کار نمی‌کند باید با مایکروسافت مکاتبه کرد و این مسایل را توضیح داد.
کاری که اکسس در اینجا کرده یا SQLite ایی که مثال زدم، مرتب سازی بر اساس کدهای یونیکد این حروف است و کار صحیحی (در بدو امر حداقل) انجام شده: (+)
کد یونیکد "ک" عربی = 1603
کد یونیکد "ی" عربی = 1610
کد یونیکد "ک" فارسی = 1705
کد یونیکد "ی" فارسی = 1740
یعنی این مرتب سازی بر اساس منطق ریاضی صحیح است؛ اما بر اساس فرهنگ ایران خیر. به همین جهت توسعه دهنده‌های بانک‌های اطلاعاتی مجبور شده‌اند تا مفهومی به نام Collation را ارائه بدهند که در بالا در مورد آن بحث شد. این Collation دیگر صرفا بر اساس منطق ریاضی کدهای یونیکد حروف، مرتب سازی را انجام نمی‌دهد، بلکه بر اساس ادبیات و فرهنگ زبان‌های مختلف کار مرتب سازی را انجام خواهد داد. SQL Server در این زمینه حداقل برای فارسی زبان‌ها یک Collation مخصوص را در نگارش 2008 خودش ارائه داده تا مرتب سازی صورت گرفته روی رشته‌ها دقیقا مطابق فرهنگ و ادبیات ایرانی باشد (برای سایر کشورها هم این نوع Collation ها پیش بینی شده).
در اکسس که مد نظر شما است این Collation به نام General Sort order مهیا است (در اکسس‌های جدید در قسمت فایل، options و سپس برگه‌ی general قسمتی هست به نام new database sort order که همین collation است) (+)
و اگر در این مورد خاص درست کار نمی‌کند باید با مایکروسافت مکاتبه کرد و این مسایل را توضیح داد.
مایکروسافت مورد مشابهی در مورد الف و همزه برای عربی زبان‌ها دارد که مشابه اون رو می‌شه برای ی/ی ک/ک ما هم می‌شه درخواست داد.
در سیستم‌های مدیریت محتوای (غالبن متن‌باز ِ) با پشتیبانی فارسی مقل جوملا و سایر خلنواده‌هاش تبدیل خودکار حروف عربی به فارسی معمولن ساپورت می‌شه و از جمله مثلن یکی از پلاگین‌های پیش‌فرض وردپرس تبدیل خودکار ی/ک به ی/ک هستش.
+ یه موردی که بارها خواسته بودم ازتون سوال کنم و بحثش پیش نیومده بود اینه که شما خودتون از kbdfa عربی پورت شده از روی ویندوز98 هنوز استفاده میکنید که "ک" و "ی" عربیه.
چرا از برنامه‌های زیادی که برای این کار است استفاده نمی‌کنید یا خودتون dll مذکور رو جوری تعییر نمی‌دید که ک و ی هاتون فارسی باشه؟
یادمه چند سال پیش در جایی صحبت شد و توجیه‌تون این بود که مطالب با ی عربی ایندکس شده توی گوگل بیشتره و این استاندارد رایج وب فارسی هستش. برای اون موقع شاید این مطلب درستی بود ولی الان هر کلمه‌ای که خواستید رو سرچ کنید میبینید نتایج جستجوی فارسی‌ش برای "ی/ک" بیشتر از "ی/ک" هستش.
در سیستم‌های مدیریت محتوای (غالبن متن‌باز ِ) با پشتیبانی فارسی مقل جوملا و سایر خلنواده‌هاش تبدیل خودکار حروف عربی به فارسی معمولن ساپورت می‌شه و از جمله مثلن یکی از پلاگین‌های پیش‌فرض وردپرس تبدیل خودکار ی/ک به ی/ک هستش.
+ یه موردی که بارها خواسته بودم ازتون سوال کنم و بحثش پیش نیومده بود اینه که شما خودتون از kbdfa عربی پورت شده از روی ویندوز98 هنوز استفاده میکنید که "ک" و "ی" عربیه.
چرا از برنامه‌های زیادی که برای این کار است استفاده نمی‌کنید یا خودتون dll مذکور رو جوری تعییر نمی‌دید که ک و ی هاتون فارسی باشه؟
یادمه چند سال پیش در جایی صحبت شد و توجیه‌تون این بود که مطالب با ی عربی ایندکس شده توی گوگل بیشتره و این استاندارد رایج وب فارسی هستش. برای اون موقع شاید این مطلب درستی بود ولی الان هر کلمه‌ای که خواستید رو سرچ کنید میبینید نتایج جستجوی فارسی‌ش برای "ی/ک" بیشتر از "ی/ک" هستش.
Nullable<T>.GetValueOrDefault Method
با استفاده از متد GetValueOrDefault مقدار فعلی یک شیء Nullable و یا مقدار پیش فرض آن را میتوان بدست آورد. این متد از عملگر ?? سریعتر است.
float? yourSingle = -1.0f; Console.WriteLine( yourSingle.GetValueOrDefault() ); yourSingle = null; Console.WriteLine( yourSingle.GetValueOrDefault() ); // assign different default value Console.WriteLine( yourSingle.GetValueOrDefault( -2.4f ) ); // returns the same result as the above statement Console.WriteLine( yourSingle ?? -2.4f );
در صورتیکه مقداری را به عنوان پیش فرض، به پارامتر این متد ارسال نکنید، مقدار پیش فرض آن از نوع استفاده شده بدست می‌آید.
شما میتوانید برای دیکشنری نیز یک متد Get امن ایجاد کنید (در صورت عدم وجود کلید، بجای پرتاب استثناء، مقدار پیش فرض بازگشت داده شود).
public static class DictionaryExtensions
{
public static TValue GetValueOrDefault< TKey, TValue >( this Dictionary< TKey, TValue > dic,
TKey key )
{
TValue result;
return dic.TryGetValue( key,
out result )
? result
: default(TValue);
}
} و روش استفاده
var names = new Dictionary< int, string >
{
{ 0, "Vahid" }
};
Console.WriteLine( names.GetValueOrDefault( 1 ) );
ZipFile in .NET
با استفاده از کلاس ZipFile ( رفرنس به اسمبلی System.IO.Compression.FileSystem ) میتوان عملیات بازکردن، ایجاد و استخراج فایل‌های Zip را انجام داد.
var startPath = Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.Desktop ), "Start" ); var resultPath = Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.Desktop ), "Result" ); var extractPath = Path.Combine( Environment.GetFolderPath( Environment.SpecialFolder.Desktop ), "Extract" ); Directory.CreateDirectory( startPath ); Directory.CreateDirectory( resultPath ); Directory.CreateDirectory( extractPath ); var zipPath = Path.Combine( resultPath, Guid.NewGuid() + ".zip" ); ZipFile.CreateFromDirectory( startPath, zipPath ); ZipFile.ExtractToDirectory( zipPath, extractPath );
C# Preprocessor Directives
با استفاده از warning# می توان یک هشدار را در یک قسمت خاص از کد تولید کرد.
#if DEBUG #warning DEBUG is defined #endif
با استفاده از error# می توان یک خطا را در یک جای خاصی از کد تولید کرد.
#if DEBUG #error DEBUG is defined #endif
با استفاده از line# می توانید شماره خط کامپایلر و نام فایل خروجی (اختیاری) را برای خطاها و هشدارها تغییر دهید.
در مثال زیر، در صورتیکه در خط اول break point قرار دهید و با کلید F10 برنامه را اجرا کنید، مشاهده میکنید که دیباگر، خطی را که بعد از دستور line hidden# نوشته شده است، در نظر نمی‌گیرد (برای دیباگ) اما اجرا میشود و دیباگر بر روی دستور بعد از line default# قرار می‌گیرد.
Console.WriteLine("Normal line #1."); // Set break point here.
#line hidden
Console.WriteLine("Hidden line.");
#line default
Console.WriteLine("Normal line #2.");
Stackalloc
کلمه کلیدی stackalloc برای اختصاص یک بلاک از حافظه در stack، در زمینه کد غیرامن (unsafe code) استفاده میشود.
مثال زیر 20 عدد اول دنباله فیبوناچی را تولید میکند. هر عدد از مجموع دو عدد قبلی به دست می‌آید. در این مثال، یک بلاک از حافظه به اندازه 20 عدد از نوع int را در stack (نه heap) اختصاص میدهد. (تفاوت stack با heap)
static unsafe void Fibonacci()
{
const int arraySize = 20;
int* fib = stackalloc int[arraySize];
var p = fib;
*p++ = *p++ = 1;
for ( var i = 2; i < arraySize; ++i, ++p )
{
*p = p[-1] + p[-2];
}
for ( var i = 0; i < arraySize; ++i )
{
System.Console.WriteLine( fib[i] );
}
} آدرس بلاک حافظه در اشاره گر fib ذخیره میشود. این متغیر توسط GC جمع آوری نمیشود و طول عمر آن محدود به متدی است که در آن تعریف شده است و شما نمی‌توانید قبل از بازگشت متد، حافظه را آزاد کنید.
تنها دلیل استفاده از stackalloc، عملکرد بهتر آن است (برای محاسبات و یا ردوبدل اطلاعات). با استفاده از stackalloc به جای اختصاص دادن آرایه (heap)، فشار کمتری را بر GC وارد میکنید (نیاز کمتری به اجرای GC وجود دارد). در نتیجه سرعت اجرای بالاتری خواهید داشت.
توجه: برای اجرای مثال بالا باید پنجره خصوصیات پروژه را باز کنید و در بخش Build، گزینه Allow unsafe code را تیک بزنید.
در قسمت‌های قبل، با پیش زمینه‌ی ذهنی طراحی مدل‌های RavenDB به همراه اصول مقدماتی کوئری نویسی آن آشنا شدیم. در این قسمت قصد داریم معادل‌های روابط موجود در بانک‌های اطلاعاتی رابطه‌ای را در RavenDB و مطابق ذهنیت غیر رابطه‌ای آن، مدلسازی کنیم و مثال‌های بیشتری را بررسی نمائیم.
مدیریت روابط در RavenDB
یکی از اصول طراحی مدل‌ها در RavenDB، مستقل بودن اسناد یا documents است. به این ترتیب کلیه اطلاعاتی که یک سند نیاز دارد، داخل همان سند ذخیره میشوند (به این نوع شیء، Root Aggregate هم گفته میشود). اما این اصل سبب نخواهد شد تا نتوان یا نباید ارتباطی را بین اسناد تعریف کرد. بنابراین سؤال مهم اینجا است که چه اطلاعات مرتبطی باید داخل یک سند ذخیره شوند و چه اطلاعاتی باید به سند دیگری ارجاع داده شوند. برای پاسخ به این سؤال سه روش ذیل را باید مدنظر داشت:
الف) Denormalized references
فرض کنید در دنیای رابطه‌ای دو جدول سفارش و مشتری را دارید. در این حالت، جدول سفارش تنها شماره آی دی اطلاعات مشتری را از جدول مشتری یا کاربران سیستم، در خود ذخیره خواهد کرد. به این ترتیب از تکرار اطلاعات مشتری در جدول سفارشات جلوگیری می‌گردد. اما اگر اطلاعات پرکاربرد مشتری را در داخل جدول سفارش قرار دهیم به آن denormalized reference گفته میشود.
ایجاد denormalized reference یکی از روش‌های مرسوم در دنیای NoSQL و RavenDB است؛ خصوصا جهت سهولت نمایش اطلاعات. به این ترتیب ارجاع به سندهای دیگر کمتر شده و ترافیک شبکه نیز کاهش می‌یابد. برای مثال در اینجا نام و آدرس مشتری را داخل سند ثبت شده قرار میدهیم و از سایر اطلاعات او (که اهمیت نمایشی ندارند) مانند کلمه عبور و امثال آن صرفنظر خواهیم کرد.
اینجا است که یک سری از سؤالات مطرح خواهند شد مانند : «اگر آدرس مشتری تغییر کرد، چطور؟»
بنابراین بهترین حالت استفاده از روش denormalized references محدود خواهد شد به موارد ذیل:
الف) قید اطلاعاتی که به ندرت تغییر میکنند. برای مثال نام یک شخص یا نام یک کشور، استان یا شهر.
ب) ثبت اطلاعات تکراری که در طول زمان تغییر میکنند، اما باید تاریخچه‌ی آنها حفظ شوند. برای مثال اگر آدرس مشتری تغییر کرده است، واقعا اجناس سندهای قبلی او، صرفنظر از آدرس جدیدی که اعلام کرده است، به آدرس قبلی او ارسال شده‌اند و این تاریخچه باید در سیستم حفظ شوند.
ج) اطلاعاتی که ممکن است بعدها حذف شوند؛ اما نیاز است سابقه اسناد قبلی تخریب نشوند. برای مثال کارخانه‌ای را درنظر بگیرید که امسال یک سری چینی خاص را تولید میکند و می‌فروشد. سال بعد خط تولید خود را عوض کرده و سری اجناس دیگری را شروع به تولید و فروش خواهد کرد. در بانک‌های اطلاعاتی رابطه‌ای نمی‌توان اجناسی را که در جداول دیگر ارجاع دارند، به این سادگی‌ها حذف کرد. در اینجا باید از روش‌هایی مانند تعریف فیلد بیتی IsDeleted برای مخفی کردن ظاهری رکوردهای موجود کمک گرفت. اما در دنیای رابطه‌ای، اطلاعات مهم محصول را در سند اصلی ثبت کنید. بعد هر زمانیکه نیازی به محصول نبود، کلا تعریف آن‌را حذف نمائید.
ب) Includes
Includes در RavenDB برای پوشش مشکلات denormalization ارائه شده است. در اینجا بجای اینکه یک شیء کپی اطلاعات پرکاربرد شیء‌ایی دیگر را در خود ذخیره کند، تنها ارجاعی (یک Id رشته‌ای) از آن شیء را در سند مرتبط ذخیره خواهد کرد.
برای نمونه در کلاس Order شاهد یک Id رشته‌ای ارجاع دهنده به کلاس Customer هستیم. هرگاه که نیاز به بارگذاری اطلاعات شیء Order به همراه کل اطلاعات مشتری او تنها در یک رفت و برگشت به بانک اطلاعاتی باشد، میتوان از متد الحاقی Include مختص RavenDB استفاده کرد:
همانطور که مشاهده میکنید، با ذکر متد Include، اعلام کرده‌ایم که مایل هستیم تا اطلاعات سند مشتری متناظر را نیز داشته باشیم. در این حالت در Load بعدی که بر اساس Id مشتری انجام شده، دیگر رفت و برگشتی به سرور انجام نشده و اطلاعات مشتری از کش سشن جاری که پیشتر با فراخوانی Include مقدار دهی شده است، دریافت می‌گردد.
حتی میتوان چند سند مرتبط را با هم بارگذاری کرد؛ با حداقل رفت و برگشت به سرور:
همچنین امکان استفاده از متد Include در LINQ API نیز پیش بینی شده است. برای این منظور باید از متد Customize استفاده کرد:
Includeهای یک به چند
اکنون فرض کنید به کلاس سفارش، آرایه تامین کننده‌ها نیز افزوده شده است (رابطه یک به چند):
بارگذاری یکباره روابط یک به چند نیز با Include میسر است:
Includeهای چند سطحی
در اینجا کلاس سفارشی را در نظر بگیرید که دارای خاصیت ارجاع دهنده نیز هست. این خاصیت به شکل یک کلاس تعریف شده است و نه به شکل یک آی دی رشته‌ای:
متد Include امکان ارجاع به خواص تو در تو را نیز دارد:
همچنین این متد با مجموعه‌ها نیز کار میکند. برای مثال اگر تعریف متد LineItem به صورت زیر باشد:
برای بارگذاری یکباره اسناد مرتبط میتوان به روش ذیل عمل کرد:
و به صورت خلاصه برای باگذاری اسناد مرتبط، دیگر از دو کوئری پشت سر هم ذیل استفاده نکنید:
این دو کوئری یعنی دوبار رفت و برگشت به سرور. با استفاده از Include میتوان تعداد رفت و برگشت‌ها و همچنین ترافیک شبکه را کاهش داد. به علاوه سرعت کار نیز افزایش خواهد یافت.
ج) تفاوت بین Reference و Relationship
برای درک اینکه آیا اطلاعات یک شیء مرتبط را بهتر است داخل شیء اصلی (Aggregate rooe) ذخیره کرد یا خیر، باید مفاهیم ارجاع و ارتباط را بررسی کنیم.
اگر به مثال سفارش و مشتری دقت کنیم، یک سفارش را بدون مشتری نیز میتوان تکمیل کرد. برای مثال بسیاری از فروشگاه‌ها به همین نحو عمل میکنند و اگر شماره Id مشتری را به سندی اضافه میکنیم، صرفا جهت این است که بدانیم این سند متعلق به شخص دیگری نیست. بنابراین «ارجاعی» به کاربر در جدول سفارش میتواند وجود داشته باشد.
اکنون اقلام سفارش را درنظر بگیرید. هر آیتم سفارش تنها با بودن آن سفارش خاص است که معنا پیدا میکنند و نه بدون آن. این آیتم میتواند ارجاعی به محصول مرتبط داشته باشد. اینجا است که می‌گوییم اقلام سند با سفارش «در ارتباط» هستند؛ اما یک سند ارجاعی دارد به مشتری.
از این دو مفهوم برای تشخیص تشکیل Root Aggregate استفاده میشود. به این ترتیب تشخیص داده‌ایم اقلام سند، Root Aggregate را تشکیل می‌دهند؛ بنابراین ذخیره سازی تمام آنها داخل یک سند RavenDB معنا پیدا میکند.
چند مثال برای درک بهتر نحوه طراحی اسناد در RavenDB
الف) Stackoverflow
صفحه نمایش یک سؤال و پاسخ‌های آن و همچنین رای‌های هر آیتم را درنظر بگیرید. در اینجا کاربران همزمانی ممکن است به یک سؤال رای بدهند، پاسخ‌هایی را ارائه دهند و یا کاربر اصلی، سؤال خویش را ویرایش کند. به این ترتیب با قرار دادن کلیه آیتم‌های این سند داخل آن، به مشکلات همزمانی برخواهیم خورد. برای مثال واقعا نمی‌خواهیم که به علت افزوده شدن یک پاسخ، کل سند قفل شود.
بنابراین ذخیره سازی سؤال در یک سند و ذخیره سازی لیست پاسخ‌ها در سندی دیگر، طراحی بهتری خواهد بود.
ب) سبد خرید و آیتم‌های آن
زمانیکه کاربری مشغول به خرید آنلاین از سایتی میشود، لیست اقلام انتخابی او یک سفارش را تشکیل داده و به تنهایی معنا پیدا نمی‌کنند. به همین جهت ذخیره سازی اقلام سفارش به صورت یک Root aggregate در اینجا مفهوم داشته و متداول است.
ج) یک بلاگ و کامنت‌های آن
در اینجا نیز کاربران، مجزای از مطلب اصلی ارسال شده ممکن است نظرات خود را ویرایش کنند یا اینکه بخواهیم نظرات را جداگانه لیست کنیم. بنابراین این دو (مطالب و نظرات) موضوعاتی جداگانه بوده و نیازی نیست به صورت یک Root aggregate تعریف شوند.
بنابراین در حین طراحی اسناد NoSQL باید به اعمال و «محدوده‌های تراکنشی» انجام شده دقت داشت تا اینکه صرفا عنوان شود این یک رابطه یک به چند یا چند به چند است.
مدیریت روابط در RavenDB
یکی از اصول طراحی مدل‌ها در RavenDB، مستقل بودن اسناد یا documents است. به این ترتیب کلیه اطلاعاتی که یک سند نیاز دارد، داخل همان سند ذخیره میشوند (به این نوع شیء، Root Aggregate هم گفته میشود). اما این اصل سبب نخواهد شد تا نتوان یا نباید ارتباطی را بین اسناد تعریف کرد. بنابراین سؤال مهم اینجا است که چه اطلاعات مرتبطی باید داخل یک سند ذخیره شوند و چه اطلاعاتی باید به سند دیگری ارجاع داده شوند. برای پاسخ به این سؤال سه روش ذیل را باید مدنظر داشت:
الف) Denormalized references
فرض کنید در دنیای رابطه‌ای دو جدول سفارش و مشتری را دارید. در این حالت، جدول سفارش تنها شماره آی دی اطلاعات مشتری را از جدول مشتری یا کاربران سیستم، در خود ذخیره خواهد کرد. به این ترتیب از تکرار اطلاعات مشتری در جدول سفارشات جلوگیری می‌گردد. اما اگر اطلاعات پرکاربرد مشتری را در داخل جدول سفارش قرار دهیم به آن denormalized reference گفته میشود.
ایجاد denormalized reference یکی از روش‌های مرسوم در دنیای NoSQL و RavenDB است؛ خصوصا جهت سهولت نمایش اطلاعات. به این ترتیب ارجاع به سندهای دیگر کمتر شده و ترافیک شبکه نیز کاهش می‌یابد. برای مثال در اینجا نام و آدرس مشتری را داخل سند ثبت شده قرار میدهیم و از سایر اطلاعات او (که اهمیت نمایشی ندارند) مانند کلمه عبور و امثال آن صرفنظر خواهیم کرد.
اینجا است که یک سری از سؤالات مطرح خواهند شد مانند : «اگر آدرس مشتری تغییر کرد، چطور؟»
بنابراین بهترین حالت استفاده از روش denormalized references محدود خواهد شد به موارد ذیل:
الف) قید اطلاعاتی که به ندرت تغییر میکنند. برای مثال نام یک شخص یا نام یک کشور، استان یا شهر.
ب) ثبت اطلاعات تکراری که در طول زمان تغییر میکنند، اما باید تاریخچه‌ی آنها حفظ شوند. برای مثال اگر آدرس مشتری تغییر کرده است، واقعا اجناس سندهای قبلی او، صرفنظر از آدرس جدیدی که اعلام کرده است، به آدرس قبلی او ارسال شده‌اند و این تاریخچه باید در سیستم حفظ شوند.
ج) اطلاعاتی که ممکن است بعدها حذف شوند؛ اما نیاز است سابقه اسناد قبلی تخریب نشوند. برای مثال کارخانه‌ای را درنظر بگیرید که امسال یک سری چینی خاص را تولید میکند و می‌فروشد. سال بعد خط تولید خود را عوض کرده و سری اجناس دیگری را شروع به تولید و فروش خواهد کرد. در بانک‌های اطلاعاتی رابطه‌ای نمی‌توان اجناسی را که در جداول دیگر ارجاع دارند، به این سادگی‌ها حذف کرد. در اینجا باید از روش‌هایی مانند تعریف فیلد بیتی IsDeleted برای مخفی کردن ظاهری رکوردهای موجود کمک گرفت. اما در دنیای رابطه‌ای، اطلاعات مهم محصول را در سند اصلی ثبت کنید. بعد هر زمانیکه نیازی به محصول نبود، کلا تعریف آن‌را حذف نمائید.
ب) Includes
Includes در RavenDB برای پوشش مشکلات denormalization ارائه شده است. در اینجا بجای اینکه یک شیء کپی اطلاعات پرکاربرد شیء‌ایی دیگر را در خود ذخیره کند، تنها ارجاعی (یک Id رشته‌ای) از آن شیء را در سند مرتبط ذخیره خواهد کرد.
public class Order
{
public string CustomerId { get; set; }
public LineItem[] LineItems { get; set; }
public double TotalPrice { get; set; }
}
public class Customer
{
public string Name { get; set; }
public string Address { get; set; }
public short Age { get; set; }
public string HashedPassword { get; set; }
} var order = session.Include<Order>(x => x.CustomerId)
.Load("orders/1234");
// این کوئری از کش سشن خوانده میشود و کاری به سرور ندارد
var cust = session.Load<Customer>(order.CustomerId); حتی میتوان چند سند مرتبط را با هم بارگذاری کرد؛ با حداقل رفت و برگشت به سرور:
var orders = session.Include<Order>(x => x.CustomerId)
.Load("orders/1234", "orders/4321");
foreach (var order in orders)
{
// این کوئری‌ها سمت کلاینت هستند و به سرور ارسال نمی‌شوند
var cust = session.Load<Customer>(order.CustomerId);
} var orders = session.Query<Order>()
.Customize(x => x.Include<Order>(o => o.CustomerId))
.Where(x => x.TotalPrice > 100)
.ToList();
foreach (var order in orders)
{
// این کوئری‌ها سمت کلاینت اجرا میشوند
var cust = session.Load<Customer>(order.CustomerId);
} Includeهای یک به چند
اکنون فرض کنید به کلاس سفارش، آرایه تامین کننده‌ها نیز افزوده شده است (رابطه یک به چند):
public class Order
{
public string CustomerId { get; set; }
public string[] SupplierIds { get; set; }
public LineItem[] LineItems { get; set; }
public double TotalPrice { get; set; }
} var orders = session.Include<Order>(x => x.SupplierIds)
.Load("orders/1234", "orders/4321");
foreach (var order in orders)
{
foreach (var supplierId in order.SupplierIds)
{
// از کش سشن خوانده میشود
var supp = session.Load<Supplier>(supplierId);
}
} Includeهای چند سطحی
در اینجا کلاس سفارشی را در نظر بگیرید که دارای خاصیت ارجاع دهنده نیز هست. این خاصیت به شکل یک کلاس تعریف شده است و نه به شکل یک آی دی رشته‌ای:
public class Order
{
public string CustomerId { get; set; }
public string[] SupplierIds { get; set; }
public Referral Refferal { get; set; }
public LineItem[] LineItems { get; set; }
public double TotalPrice { get; set; }
}
public class Referral
{
public string CustomerId { get; set; }
public double CommissionPercentage { get; set; }
} var order = session.Include<Order>(x => x.Refferal.CustomerId)
.Load("orders/1234");
// از کش سشن خوانده میشود
var referrer = session.Load<Customer>(order.Refferal.CustomerId); public class LineItem
{
public string ProductId { get; set; }
public string Name { get; set; }
public int Quantity { get; set; }
public double Price { get; set; }
} var order = session.Include<Order>(x => x.LineItems.Select(li => li.ProductId))
.Load("orders/1234");
foreach (var lineItem in order.LineItems)
{
// از کش سمت کلاینت خوانده میشود
var product = session.Load<Product>(lineItem.ProductId);
} و به صورت خلاصه برای باگذاری اسناد مرتبط، دیگر از دو کوئری پشت سر هم ذیل استفاده نکنید:
var order = session.Load<Order>("orders/1");
var customer = session.Load<Customer>(order.CustomerId); ج) تفاوت بین Reference و Relationship
برای درک اینکه آیا اطلاعات یک شیء مرتبط را بهتر است داخل شیء اصلی (Aggregate rooe) ذخیره کرد یا خیر، باید مفاهیم ارجاع و ارتباط را بررسی کنیم.
اگر به مثال سفارش و مشتری دقت کنیم، یک سفارش را بدون مشتری نیز میتوان تکمیل کرد. برای مثال بسیاری از فروشگاه‌ها به همین نحو عمل میکنند و اگر شماره Id مشتری را به سندی اضافه میکنیم، صرفا جهت این است که بدانیم این سند متعلق به شخص دیگری نیست. بنابراین «ارجاعی» به کاربر در جدول سفارش میتواند وجود داشته باشد.
اکنون اقلام سفارش را درنظر بگیرید. هر آیتم سفارش تنها با بودن آن سفارش خاص است که معنا پیدا میکنند و نه بدون آن. این آیتم میتواند ارجاعی به محصول مرتبط داشته باشد. اینجا است که می‌گوییم اقلام سند با سفارش «در ارتباط» هستند؛ اما یک سند ارجاعی دارد به مشتری.
از این دو مفهوم برای تشخیص تشکیل Root Aggregate استفاده میشود. به این ترتیب تشخیص داده‌ایم اقلام سند، Root Aggregate را تشکیل می‌دهند؛ بنابراین ذخیره سازی تمام آنها داخل یک سند RavenDB معنا پیدا میکند.
چند مثال برای درک بهتر نحوه طراحی اسناد در RavenDB
الف) Stackoverflow
صفحه نمایش یک سؤال و پاسخ‌های آن و همچنین رای‌های هر آیتم را درنظر بگیرید. در اینجا کاربران همزمانی ممکن است به یک سؤال رای بدهند، پاسخ‌هایی را ارائه دهند و یا کاربر اصلی، سؤال خویش را ویرایش کند. به این ترتیب با قرار دادن کلیه آیتم‌های این سند داخل آن، به مشکلات همزمانی برخواهیم خورد. برای مثال واقعا نمی‌خواهیم که به علت افزوده شدن یک پاسخ، کل سند قفل شود.
بنابراین ذخیره سازی سؤال در یک سند و ذخیره سازی لیست پاسخ‌ها در سندی دیگر، طراحی بهتری خواهد بود.
ب) سبد خرید و آیتم‌های آن
زمانیکه کاربری مشغول به خرید آنلاین از سایتی میشود، لیست اقلام انتخابی او یک سفارش را تشکیل داده و به تنهایی معنا پیدا نمی‌کنند. به همین جهت ذخیره سازی اقلام سفارش به صورت یک Root aggregate در اینجا مفهوم داشته و متداول است.
ج) یک بلاگ و کامنت‌های آن
در اینجا نیز کاربران، مجزای از مطلب اصلی ارسال شده ممکن است نظرات خود را ویرایش کنند یا اینکه بخواهیم نظرات را جداگانه لیست کنیم. بنابراین این دو (مطالب و نظرات) موضوعاتی جداگانه بوده و نیازی نیست به صورت یک Root aggregate تعریف شوند.
بنابراین در حین طراحی اسناد NoSQL باید به اعمال و «محدوده‌های تراکنشی» انجام شده دقت داشت تا اینکه صرفا عنوان شود این یک رابطه یک به چند یا چند به چند است.
در این قسمت بیشتر یک سری از ماژول‌ها را به شما در قالب جداول گروه بندی شده معرفی خواهیم کرد :
همانطور که در قسمت‌های قبلی گفتیم سرور IIS آماده خصوصی سازی و کار بر اساس علائق شماست؛ ولی توجه داشته باشید حذف تمامی ماژول‌ها ممکن است اثرات جانبی هم داشته باشد. در اینجا ما ماژول هایی را به شما معرفی میکنیم که بدانید کار هر ماژول چیست تا مثلا با حذف ماژولی، امنیت وب سایت خود را به خطر نیندازید :
ماژول‌های سودمند یا utility
| نام ماژول: | UriCacheModule |
| توضیح: | این ماژول نوعی کش برای URLها به شمار می‌رود. موقعی که url درخواست میشود، اطلاعات در اولین درخواست خوانده شده و کش میشود و اگر دوباره همان url درخواست شود، بدون خواندن تنظیمات و بر اساس تنظیمات قبلی، کار url مربوطه را انجام میدهد تا اطلاعات پیکربندی تغییر کند و بر اساس اطلاعات جدید، خود را به روز کند. |
| تگ قابل پیکربندی: | لازم ندارد |
| وابستگی: | ندارد |
| اثرات حذف آن: | کارایی سیستم کاهش می‌یابد و سیستم مجبور است برای هر درخواست فایل پیکربندی را بخواند. |
| نام ماژول : | FileCacheModule |
| توضیح : | فایل هندلِ فایل‌هایی که قبلا در سرور باز شده‌اند را کش میکند تا در صورت نیاز در دفعات بعدی سریعتر عمل کند. |
| تگ قابل پیکربندی : | لازم ندارد . |
| وابستگی : | ندارد. |
| اثرات حذف آن : | کارایی سیستم کاهش می‌یابد. سیستم در هر اجرای دستور مربوط به فایل‌ها باید فایل هندل را به دست آورد. |
| نام ماژول : | TokenCacheModule |
| توضیح : | توکن‌های امنیتی ویندوز که پسوردهایی بر اساس authentication schemes هستند را کش میکند (anonymous authentication, basic authentication, IIS client certificate authentication ) |
| تگ قابل پیکربندی : | لازم ندارد |
| وابستگی : | ندارد |
| اثرات حذف آن : | کارایی سیستم به شدت پایین می‌آید. کاربر باید با هر درخواستی لاگین کند. یکی از اصلی‌ترین ضربه‌ها با حذف این ماژول این است که اگر مثلا یک پسورد از یک فایل html محافظت میکند و این صفحه به 50 تصویر ارجاع دارد، 51 بار باید درخواست لاگین اجرا گردد یا شاید هم بدتر |
MANAGED ENGINE: ASP.NET INTEGRATION
| نام ماژول : | ManagedEngine |
| توضیح : | مدیریت ماژول‌های native و مدیریت شده |
| تگ قابل پیکربندی : | |
| وابستگی : | ندارد |
| اثرات حذف آن : | مشخصا غیرفعال شدن asp.net integrated و غیر فعال شدن تمامی ماژول‌ها و هندلر‌های تگ وب کانفیگ یا داخل فایل کانفیگ IIS که در مقالات قبلی به تفصیل بیان کرده‌ایم. |
IIS 7 NATIVE MODULES
| نام ماژول : | HttpCacheModule |
| توضیح : | مدیریت کش خروجی در htttp.sys بر اساس پیکربندی مثل تعریف سایز کش و ... |
| تگ قابل پیکربندی : | System.webServer/caching |
| وابستگی : | ندارد. |
| اثرات حذف آن : | محتوا دیگر به صورت کرنل مد، کش نمیشود و کش پروفایل هم ندید گرفته میشود و احتمالا بر کارآیی و استفاده از منابع هم اثر می‌گذارد. |
| نام ماژول : | DynamicCompressionModule |
| توضیح : | پیاده سازی in-memory compression در محتوای پویا |
| تگ قابل پیکربندی : | system.webServer/httpCompression and system.webServer/urlCompression. |
| وابستگی : | وابستگی ندارد چرا که به طور پیش فرض غیرفعال است. |
| نام ماژول : | StaticCompressionModule |
| توضیح : | پیادسازی فشرده سازی در محتوای ایستا و برای فایل‌های سیستمی از نوع in memory |
| تگ قابل پیکربندی : | system.webServer/httpCompression and system.webServer/urlCompression |
| وابستگی : | ندارد. |
| اثرات حذف آن : | در صورت عدم فشرده سازی بر مصرف ترافیک تاثیر گذار است. |
| نام ماژول : | DefaultDocumentModule |
| توضیح : | پیاده سازی یک لیست سند پیش فرض. درخواست‌ها مدام پشت سر هم می‌آیند و این درخواست‌های پشت سرهم، به سند پیش فرض هدایت میشوند. همان پنجره ای که شما به ترتیب فایل‌های index.htm,index.asp,default.aspx و... را تعیین میکنید. |
| تگ قابل پیکربندی : | system.webServer/defaultDocument |
| وابستگی : | ندارد. |
| اثرات حذف آن : | درخواست را به ریشه هدایت میکند. مثلا برای localhost صفحه 404 باز میگرداند و اگر directoryBrowsing فعال باشد لیستی از دایرکتوری ریشه را باز میگرداند. |
| نام ماژول : | DirectoryListingModule |
| توضیح : | پیادی سازی لیستی از محتویات یک دایرکتوری |
| تگ قابل پیکربندی : | system.webServer/directoryBrowse |
| وابستگی : | ندارد. |
| اثرات حذف آن : | اگر این ماژول و ماژول قبلی غیرفعال باشند response نهایی خالی است. |
| نام ماژول : | ProtocolSupportModule |
| توضیح : | پیاده سازی اختصاصی از response header پیاده سازی تنظیمات trace و HTTP verbs. پیاده سازی تنظیمات مربوطه به keep-alive بر اساس پیکربندی |
| تگ قابل پیکربندی : | system.webServer/httpProtocol |
| وابستگی : | ندارد. |
| اثرات حذف آن : | بازگرداندن پیام خطای "405 Method not allowed". |
| نام ماژول : | HttpRedirectionModule |
| توضیح : | پیاده سازی عملیات انتقال یا redirect |
| تگ قابل پیکربندی : | system.webServer/httpRedirect |
| وابستگی : | ندارد. |
| اثرات حذف آن : | خطر امنیتی: اگر منابعی با redirect کردن محافظت میشوند، از این پس در دسترسند. |
| نام ماژول : | ServerSideIncludeModule |
| توضیح : | حمایت از فایل shtm یا shtml و ... |
| تگ قابل پیکربندی : | system.webServer/serverSideInclude |
| وابستگی : | ندارد. |
| اثرات حذف آن : | این فایل‌ها به صورت متنی نمایش داده میشوند |
| نام ماژول : | StaticFileModule |
| توضیح : | فایل‌های ایستا را به همراه پسوند ارسال میکند. مثل jpg,html و نوع محتوا را بر اساس staticContent/mimeMap پیکربندی میکند. |
| تگ قابل پیکربندی : | system.webServer/staticContent |
| وابستگی : | ندارد. |
| اثرات حذف آن : | فایل‌های ایستا دیگر ارائه نشده و به جای آن خطای 404 بازگشت داده میشود. |
| نام ماژول : | AnonymousAuthenticationModule |
| توضیح : | پیاده سازی سیستم شناسایی افراد ناشناس. همانطور که میدانید در یک وب سایت حداقل محتوایی برای افرادی بدون داشتن اکانت هم وجود دارد. برای اینکار یک شیء httpuser ایجاد میکند. |
| تگ قابل پیکربندی : | system.webServer/security/authentication/anonymousAuthentication |
| وابستگی : | ندارد. |
| اثرات حذف آن : | حداقل باید یک سیستم امنیتی برای شناسایی یا authenticate وجود داشته باشد. httpuser یک ساختار داده ای در IIS میباشد و در صورت نبودن هیچ سیستم شناسایی وجود نداشته و در نبود شیء httpuser سیستم خطای 401.2 را تولید میکند. |
| نام ماژول : | CertificateMappingAuthenticationModule |
| توضیح : | مجوز SSL را به Active Directory نگاشت میکند. |
| تگ قابل پیکربندی : | system.webServer/security/authentication/clientCertificateMappingAuthentication |
| وابستگی : | برای اینکه این ماژول وظیفه خود را انجام دهد باید تنظیمات SSL انجام شود و همچنین سیستم IIS جزئی از دامنه Active directory باشد |
| اثرات حذف آن : | درخواست‌ها، نرمال رسیدگی میشوند انگار SSL وجود ندارد. |
| نام ماژول : | BasicAuthenticationModule |
| توضیح : | پیاده سازی پایه‌ای و روتین شناسایی کاربران بر اساس آن چیزی که در استانداد زیر آمده است |
| تگ قابل پیکربندی : | system.webServer/security/authentication/basicAuthentication |
| وابستگی : | None. |
| اثرات حذف آن : | حداقل باید یک سیستم امنیتی برای شناساسایی یا authenticate وجود داشته باشد. httpuser یک ساختار داده‌ای در IIS میباشد و در صورت نبود، هیچ سیستم شناسایی یافت نشده و نبود شیء httpuser در سیستم، خطای 401.2 را تولید میکند. |
| نام ماژول : | WindowsAuthenticationModule |
| توضیح : | ((windows Authentication (NTLM or Negotiate (Kerberos |
| تگ قابل پیکربندی : | system.webServer/security/authentication/windowsAuthentication |
| وابستگی : | ندارد. |
| اثرات حذف آن : | حداقل باید یک سیستم امنیتی برای شناسایی یا authenticate وجود داشته باشد. httpuser یک ساختار داده ای در IIS میباشد و در صورت نبود، هیچ سیستم شناسایی یافت نشده و نبود شیء httpuser در سیستم، خطای 401.2 را تولید میکند. |
| نام ماژول : | DigestAuthenticationModule |
| توضیح : | پیاده سازی سیستم شناسایی دیاجست بر اساس RFC 2617 . |
| تگ قابل پیکربندی : | system.webServer/security/authentication/digestAuthentication |
| وابستگی : | IIS باید بخشی از دامنه Active Directory باشد. |
| اثرات حذف آن : | حداقل باید یک سیستم امنیتی برای شناسایی یا authenticate وجود داشته باشد.
httpuser یک ساختار داده ای در IIS میباشد و در صورت نبود، هیچ سیستم
شناسایی یافت نشده و نبود شیء httpuser در سیستم، خطای 401.2 را تولید
میکند. |
| نام ماژول : | IISCertificateMappingAuthenticationModule |
| توضیح : | پیاده سازی نگاشت مجوزهای IIS، نگهداری و ذخیره اطلاعات همه نگاشت‌ها و مجوزهای کاربری چون SSL client certificates |
| تگ قابل پیکربندی : | system.webServer/iisClientCertificateMappingAuthentication |
| وابستگی : | اطلاعات SSL به همراه دریافت client certificates جهت پیکربندی این ماژول |
| اثرات حذف آن : | حداقل باید یک سیستم امنیتی برای شناسایی یا authenticate وجود داشته باشد.
httpuser یک ساختار داده ای در IIS میباشد و در صورت نبود، هیچ سیستم
شناسایی یافت نشده و نبود شیء httpuser در سیستم، خطای 401.2 را تولید
میکند. |
| نام ماژول : | UrlAuthorizationModule |
| توضیح : | پیاده سازی authorization بر اساس قوانین پیکربندی شده |
| تگ قابل پیکربندی : | system.webServer/security/authorization |
| وابستگی : | ندارد. |
| اثرات حذف آن : | محتواهای محافظت شده توسط authorization دیگر محافظت نمی‌شوند. |
| نام ماژول : | IsapiModule |
| توضیح : | پیاده سازی ISAPI Extension |
| تگ قابل پیکربندی : | system.webServer/isapiCgiRestriction |
| وابستگی : | ندارد. |
| اثرات حذف آن : | هندلر‌های معرفی شده در بخش IsapiModule و تگ handlers دیگر اجرا نمی‌شوند |
| نام ماژول : | IsapiFilterModule |
| توضیح : | پیاده سازی ISAPI filter |
| تگ قابل پیکربندی : | system.webServer/isapiFilters |
| وابستگی : | ندارد. |
| اثرات حذف آن : | اگر برنامه ای از ISAPI filter استفاده میکند، در اجرا دچار مشکل خواهد شد. |
| نام ماژول : | IpRestrictionModule |
| توضیح : | یک سیستم تشخیص دسترسی بر اساس آی پی‌های ورژن4 |
| تگ قابل پیکربندی : | system.webServer/security/ipSecurity |
| وابستگی : | IPv4 stack باید نصب شود. |
| اثرات حذف آن : | کلاینت هایی که IP هایشان در IPsecurity لیست شده‌اند ندید گرفته میشوند |
| نام ماژول : | RequestFilteringModule |
| توضیح : | پیاده سازی یک مجموعه قدرتمند از قوانین امنیتی که درخواست‌های مشکوک را پس می‌زند. |
| تگ قابل پیکربندی : | system.webServer/security/requestFiltering |
| وابستگی : | ندارد. |
| اثرات حذف آن : | دیگر قوانین امنیتی اجرا نخواهند شد و سبب وجود مشکلات امنیتی میشود. |
| نام ماژول : | CustomLoggingModule |
| توضیح : | پیاده سازی اینترفیس ILogPlugin در سمت IIS، به مشتریان اجازه میدهد تا لاگ‌های خود را توسعه دهند. هر چند این روش توصیه نمیشود و توصیه کارشناس مایکروسافت استفاده از یک ماژول دست نویس از نوع RQ_LOG_REQUEST می باشد. Implements the ILogPlugin interface on top of IIS. ILogPlugin is a previous COM implementation that allowed customers to extend IIS logging. We do not not recommend extending IIS using this interface. Instead, customers should write a module and subscribe to the RQ_LOG_REQUEST notification. |
| تگ قابل پیکربندی : | system.webServer/httpLogging and system.applicationhost/sites/site/logFile/customLogPluginClsid |
| وابستگی : | ندارد. |
| اثرات حذف آن : | مسلما پلاگین‌های‌های این اینترفیس از کار میافتند که سیستم ODBC Logging هم جز آن است. |
| نام ماژول : | CustomErrorModule |
| توضیح : | پیاده سازی مدیریت خطاهای ویژه |
| تگ قابل پیکبرندی : | system.webServer/httpErrors |
| وابستگی : | None. |
| اثرات حذف آن : | در صورتی که خطایی از هسته باشد، نتیجه یک صفحه، با توضیح مختصری از خطا خواهد بود. در غیر این صورت اگر خطا از برنامه یا کامپوننتی باشد جزئیات خطا فاش خواهد شد |
| نام ماژول : | HttpLoggingModule |
| توضیح : | پیاده سازی سیستم logging استاندارد http.sys |
| تگ قابل پیکربندی : | system.applicationHost/log and system.webServer/httpLogging |
| وابستگی : | ندارد. |
| اثرات حذف آن : | از کار افتادن سیستم لاگ |
| نام ماژول : | FailedRequestsTracingModule |
| توضیح : | پیاده سازی سیستم ردیابی درخواست‌های ناموفق و اجرای قوانین، طبق پیکربندی |
| تگ قابل پیکربندی : | system.webServer/tracing and system.webServer/httpTracing |
| وابستگی : | ندارد. |
| اثرات حذف آن : | Tracing http requests will no longer work. |
| نام ماژول : | RequestMonitorModule |
| توضیح : | پیاده سازی IIS Run-time State and Control Interface یا به اختصار RSCA . به کاربران اجازه میدهد از اطلاعات، حین اجرا، کوئری بگیرند. مثل درخواست درحال اجرای جاری، آغاز به کار یا توقف وب سایت و دامنه‌های اپلیکیشن در حال اجرای جاری |
| تگ قابل پیکربندی : | ندارد. |
| وابستگی : | ندارد. |
| اثرات حذف آن : | ابزارهای مرتبط با این موضوع از کار میافتند |
| نام ماژول : | CgiModule |
| توضیح : | پیاده سازی CGI در سمت IIS |
| تگ قابل پیکبرندی : | system.webServer/cgi and system.webServer/isapiCgiRestriction |
| وابستگی : | ندارد. |
| اثرات حذف آن : | برنامه‌های CGI متوقف میشوند |
| نام ماژول : | TracingModule |
| توضیح : | پیاده سازی سیستم ردیابی ETW |
| تگ قابل پیکربندی : | system.webServer/httpTracing |
| وابستگی : | ندارد. |
| اثرات حذف آن : | باعث از کار افتادن سیستم مربوطه میشود |
| نام ماژول : | ConfigurationValidationModule |
| توضیح : | اعتبارسنجی تنظیمات برنامه ASP.Net که به حالت integrate انتقال یافته است |
| تگ قابل پیکربندی : | system.webServer/Validation |
| وابستگی : | ندارد. |
| اثرات حذف آن : | عدم اعتبارسنجی و در نتیجه عدم نمایش خطاها |
MANAGED MODULES:
| نام ماژول : | OutputCache |
| توضیح : | پیاده سازی output caching |
| تگ قابل پیکربندی : | system.web/caching/outputCache |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | عدم اجرای output cache |
| نام ماژول : | Session |
| توضیح : | مدیریت سشن ها |
| تگ قابل پیکربندی : | system.web/sessionState |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | سشن‌ها از دسترس خارج میشوند. |
| نام ماژول : | WindowsAuthentication |
| توضیح : | |
| تگ قابل پیکربندی : | system.web/authentication |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | این حالت قابل اجرا نخواهد بود |
| نام ماژول : | FormsAuthentication |
| توضیح : | |
| تگ قابل پیکربندی : | system.web/authentication |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | این حالت قابل اجرا نیست و کاربران مجوز دار هم نمی‌توانند به منابع محافظت شده دسترسی داشته باشند. |
| نام ماژول : | DefaultAuthentication |
| توضیح : | اطمینان از وجود شی Authentication در context مربوطه |
| تگ قابل پیکربندی : | system.web/authentication |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | اگر مد Forms authentication انتخاب شده باشد بر روی بعضی از کاربران ناشناس کار نخواهد کرد و رویداد DefaultAuthentication.OnAuthenticate اجرا نخواهد شد. |
| نام ماژول : | RoleManager |
| توضیح : | |
| تگ قابل پیکربندی : | |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | این قابلیت در دسترس نمی‌باشد |
| نام ماژول : | UrlAuthorization |
| توضیح : | |
| تگ قابل پیکربندی : | system.web/authorization. |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | باعث از کار افتادن asp.net authorization و فاش شدن بعضی اطلاعات و همچنین دیگر تهدیدات امنیتی |
| نام ماژول : | AnonymousIdentification |
| توضیح : | |
| تگ قابل پیکربندی : | |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | The anonymous identification feature used by the ASP.NET Profile will not work. |
| نام ماژول : | Profile |
| توضیح : | |
| تگ قابل پیکربندی : | |
| وابستگی : | ManagedEngine module must be installed. |
| اثرات حذف آن : | ASP.Net Profile از کار خواهد افتاد |
| نام ماژول : | UrlMappingsModule |
| توضیح : | تبدیل یک Url واقعی به یک Url کاربرپسند |
| تگ قابل پیکبرندی : | |
| وابستگی : | نیاز به ManagedEngine . |
| اثرات حذف آن : | نگاشت Urlها صورت نمی‌گیرد |
سیلورلایت 4 با پشتیبانی رسمی از زبان‌های راست به چپ و همچنین ارائه‌ی کوهی از قابلیت‌های جدید، کاندید مناسبی برای توسعه‌ی نرم افزارهای تحت وب (و همچنین برنامه‌های Desktop چند سکویی) میباشد. اما باید درنظر داشت که تیم آن برای کوچک نگه داشتن حجم افزونه‌ی آن تمامی کلاس‌های موجود در دات نت فریم ورک را به آن اضافه نکرده‌اند و تقویم فارسی نیز از این دست است.
مایکروسافت مدتی است که قسمتی را جهت دریافت بازخورد برنامه نویس‌ها و دریافت نظرات و پیشنهادات آنها در این مورد ایجاد کرده است:
در همین زمینه لطفا به آدرس ذیل مراجعه کرده و برای اضافه شدن تقویم فارسی به صورت رسمی به آن رای بدهید؛ با تشکر!
در بخش قبلی به معرفی ماژول angular-tanslate پرداختیم. در این بخش قصد داریم تا به بررسی مفهومی قابلیت‌های موجود در این ماژول بپردازیم.
شکل زیر یک شمای کلی را از قابلیت‌های angular-translate، نمایش میدهد. همانطور که ملاحظه میکنید در مواردی نظیر ذخیره سازی زبان‌ها، بارگذاری ریسورس‌های زبان‌ها و گرامرهای استفاده در DOM راهکارهای گوناگونی دارد.
angular-translate دایرکتیو و فیلتر هایی را به صورت کامپوننت عرضه کرده است که شما میتوانید به وسیله‌ی آنها پروژه خود را به زبان‌های گوناگون localize کنید. آنچه که در تصویر فوق مشاهده میکنید در حقیقت ساختار ماژول angular-translate را نمایش میدهد. به این صورت که در اولین لایه دایرکتیو translate قرار گرفته است.
سطح بعدی شاید کمی جذاب‌تر به نظر برسد. هر دو بخش دایرکتیو و فیلتر از سرویس تزریق شده translate$ استفاده میکنند. این بدین معنی است که در هنگام تغییر یک زبان به زبان دیگر به وسیله دایرکتیوهایی که در view نوشته شده است، در حقیقت شما این دایرکتیو‌ها را به سطح فیلتر انتقال داده‌اید و پس از آن، فیلتر آن را به لایه سرویس برده و سرویس کار اصلی را انجام میدهد.
در سطح بعدی لایه Interpolator قرار گرفته است که وظیفه تغییر DOMها را بر عهده دارد. این فرآیند متغیرهایی را که در ریسورس قرار داده‌ایم، درایه به درایه در view و در مکان‌های هم نام قرار میدهد. این فرآیند به وسیله راهکارهای گوناگونی از قبیل Message Format و یا Angular Core Interpolation Service امکان پذیر است.
جعبه خاکستری رنگ بخش missing translation handler را نشان میدهد. این handlerها زمانی فراخوانی می‌گردند که translator به دنبال یک key می‌گردد که تعریف نشده باشد. angular-translate خود شامل یک logging service میباشد که به صورت extension باید آن را به پروژه خود اضافه نمایید که در بخش‌های بعدی در مورد آن مفصل‌تر بحث میکنیم.
بخش asynchronous loader شما را قادر می‌سازد که داده‌های زبان‌های متفاوت را به صورت غیر هم زمان بارگذاری نمایید. angular-translate از ماژول‌های asynchronous loader پشتیبانی میکند. روش معرفی شده در سایت مرجع در مورد بارگذاری غیر همزمان urlLoader و staticFilesLoader هستند که در بخش‌های بعدی به آن خواهیم پرداخت.
angular-translate برای ذخیره سازی داده‌های بازگذاری شده و نگه داشتن زبان سایت در صورت reload شدن صفحه راهکارهای متفاوتی را ارائه نموده است. این قابلیت در ابتدا چک میکند که ریسورس‌های زبان درون یک local storage قرار گرفته‌اند یا خیر. این عملیات طی یک فرآیند جستجوی key-value صورت می‌گیرد و در نهایت فایل‌های ریسورس زبان مورد نظر که درون کوکی یا localStorage ذخیره شده‌اند بارگذاری میشوند. angular-translate به صورت توکار دارای دو راهکار localStorage و cookieStorage برای ذخیره سازی ریسورس‌ها میباشد.
در بخش بعدی در مورد نحوه‌ی ذخیره سازی داده‌ها به دو روش cookieStorage و localStorage بیشتر صحبت خواهیم کرد.