توانایی تهیهٔ ISO رو نیز درون خود دارد که با توجه به حذف این امکان در ویندوز ۸ مناسب است. همچنین به یک درایو مجازی محدود نیست و به صورت پویا در لحظه قابلیت حذف و اضافه‌نمودن درایو در آن وجود دارد. مهم‌ترین ویژگی آن نیز متن‌باز بودنش است :) 
پس از نصب ویندوز 8 در VMWare نیاز است ابتدا VMWare Tools نصب شود. سپس فایل vmx ماشین مجازی را یافته و یک سطر ذیل را به انتهای آن اضافه کنید:
svga.vramSize = "134217728"
نقل قولی از متن بالا:
"... حتما از منوی action گزینه install or update virtual machine additions را انتخاب کنید تا کارآیی سیستم عامل مجازی را بهبود بخشید. حداقل فایده آن ..."
"... حتما از منوی action گزینه install or update virtual machine additions را انتخاب کنید تا کارآیی سیستم عامل مجازی را بهبود بخشید. حداقل فایده آن ..."
معماری اطلاعات یا Information Architecture و یا به اختصار IA در یک تیم توسعه نرم‌افزار، یک وظیفه پایه و اساسی است که معمولا بین طراحان، توسعه دهندگان و یا طراحان استراتژی محتوا تقسیم میگردد. اما صرف نظر از اینکه چه کسی در یک تیم آن را بر عهده می‌گیرد، IA تخصص خاص خود را نیازمند است که این تخصص که شامل ابزارها و شاخص‌ها و منابعی است که باید به درستی تحقیق و گردآوری گردند. در این مقاله قصد داریم تا به این امر بپردازیم که واقعا IA چیست؟ و چرا یک جنبه‌ی مهم و ارزشمند در طراحی فرآیندهای user experience به شمار میرود؟
Information Architecture چیست؟
بیان کردن یک تعریف دقیق برای IA کمی پیچیده‌تر از تعاریف دیگری همچون content strategy و یا interaction design به نظر می‌رسد. بر خلاف content strategy که به وسیله طراحان استراتژی محتوا و یا interaction design که توسط طراحان UI/UX انجام می‌گیرد، IA به ندرت در زمره‌ی یک کار جداگانه قرار می‌گیرد. اما با این وجود، این کار در مهندسی نرم افزار بسیار با ارزش و لازم محسوب میگردد. (منبع)
بر اساس تعریف ویکی‌پدیا، IA اینگونه تعریف میگردد: "معماری اطلاعات عبارت است از طراحی ساختاری سامانه‌های اشتراک اطلاعات، که با هدف یافت پذیری و کاربرد پذیری انجام می‌شود."
در فرهنگ معماری اطلاعات، مفهوم یافت‌پذیری یا Findability به زبان ساده، شاخصی است که قابلیت یافت شدن و مکان‌یابی یک مجموعه اطلاعات را محک می‌زند. به عنوان مثال سامانه‌های اطلاع‌رسانی مانند وب سایت‌ها باید به گونه‌ای طراحی شوند که مردم در هر سطحی، به سادگی بتوانند اطلاعات مورد نظر خود را پیدا کنند.
مفهوم کاربردپذیری یا Usability ، شاخصه‌ای است که میزان سهولت کاربری یک ابزار را نشان میدهد. این تعریف را می‌توان به این صورت کامل نمود: "میزانی که یک محصول میتواند توسط کاربران خاصی برای رسیدن به هدفی مشخص مورد استفاده قرار گیرد و در حین استفاده، ضمن داشتن اثربخشی و کارآیی، رضایت کاربر را در زمینه مورد استفاده تامین کند." به عنوان مثال هنگامیکه شما قصد خرید اینترنتی را داشته باشید، در درجه اول مفهوم یافت‌پذیری برای شما پررنگ خواهد شد و پس از آن با انجام خرید حس کاربردپذیری فروشگاه خواهد بود که برای دفعات بعدی شما را به آن وب‌سایت هدایت خواهد کرد.
بنا بر آنچه که گفته شد، مفهوم یافت‌پذیری مقدم بر کاربردپذیری است. یعنی اگر کاربر نتواند آنچه را که به دنبال آن است بیابد، هرگز فرصت استفاده از آنرا نخواهد داشت. به علاوه اگر یافت‌پذیری محقق شود، کاربردپذیری هم بهبود خواهد یافت، چرا که مردم می‌توانند به سرعت و سهولت به آنچه که نیاز دارند دست یابند. ذکر این نکته نیز حائز اهمیت است که موتور‌های جست و جو، تنها وظیفه‌ی هدایت کاربران را به وب‌سایت هدف خواهند داشت. اما وظیفه یافت پذیری، با بازدید کاربران از وب‌سایت آغاز میگردد. به نوعی می‌توان گفت که یافت‌پذیری می‌کوشد به مردم این امکان را بدهد تا در هنگام گذار در وب‌سایت، به اطلاعاتی که نیاز دارند دست یابند.
معماری اطلاعات یکی از مهم‌ترین مراحل توسعه‌ی نرم‌افزار، به خصوص توسعه‌ی نرم‌افزار‌های تحت وب به شمار میرود. در حقیقت با انجام معماری اطلاعات دقیق، می‌توان مواردی از قبیل رسیدن به اهداف تعیین شده، کم کردن هزینه‌ی نگه‌داری و به روز رسانی، افزایش کارآیی و در نهایت کم شدن ریسک‌ها را مدیریت نمود.
بر اساس آنچه که در وب‌سایت UXmatters و webmonkey گفته شده است، IA در شش مرحله صورت می‌گیرد:
1. ارزیابی هدف کسب و کار ( Assess business intent )
2. ارزیابی هدف کاربران ( Assess user intent )
3. ارزیابی محتوا ( Assess content )
4. مدیریت محتوا ( Organize content )
5. برقرارسازی ارتباط میان اطلاعات ( Enable information relationships )
6. فراهم‌سازی فرآیند هدایت محتوا ( Provide navigation )
تصویر زیر که برگرفته از وب‌سایت SitePoint میباشد برخی از مراحل فوق را به صورت مختصر و ساده نمایش داده است.
اگر به وب‌سایت رسمی انجمن معماری اطلاعات سری بزنید مطالب مفیدی در زمینه‌ی پیاده سازی IA به دست خواهید آورد.
تصویر زیر ارتباط تنگاتنگ سه مبحث Information Design ، Interaction Design و Sensorial Design را نمایش میدهد. همانطور که میبینید، محتوا در مرکزیت هر سه موضوع قرار دارد. بنابراین می‌توان اینگونه استنباط کرد که محتوا اصلی‌ترین بخش یک کسب‌وکار نرم‌افزاری را تشکیل میدهد. اما در بخش پیشین دیدیم که محتوا به تنهایی نمی‌تواند راهگشای نتیجه‌ی عالی از یک نرم‌افزار باشد. با توجه به دو مفهوم یافت‌پذیری و کاربردپذیری دیدیم برای آنکه بتوانیم در تولید نرم‌افزار بهترین باشیم، بایستی در قدم اول مفهوم یافت‌پذیری را رعایت نماییم. به زبان ساده باید هر چیزی را در جای مورد نظر خود قرار دهیم تا کاربر در مدت زمان خیلی کمی بتواند به آن دسترسی داشته باشد.
همانطور که در تصویر فوق ملاحظه میکنید دو اصطلاح شاید نا آشنای دیگر نیز آورده شده است، Interaction Design و Sensorial Design. در مقاله‌ای دیگر به آنها خواهیم پرداخت.
با استفاده از Blazor می‌توان برنامه‌های وب تعاملی را با کمک زبان #C تهیه کرد که پیشتر برای نوشتن آنها به جاوا اسکریپت نیاز بود. به این ترتیب می‌توان برای تهیه‌ی قسمت‌های front-end و backend پروژه‌ی خود، از زبانی که به آن تسلط دارید استفاده کنید. یکی از مزایای آن امکان به اشتراک گذاری کدهای سمت سرور و کلاینت است؛ با توجه به اینکه هر دو به یک زبان تهیه میشوند.
وضعیت توسعه‌ی برنامه‌های وب، پیش از ارائه‌ی Blazor
عموما برای توسعه‌ی برنامه‌های وب، در سمت سرور آنها از زبان‌هایی مانند C#، Java و Python و امثال آنها استفاده می‌شود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریم‌ورک‌ها و کتابخانه‌های جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده می‌شود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبان‌ها، مشکل و وقت‌گیر است. بنابراین چقدر خوب میشد اگر امکان تهیه‌ی هر دو قسمت برنامه‌های وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شده‌است.
با استفاده از Blazor می‌توان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان می‌توان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه می‌توان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالت‌های مختلف هاست و ارائه‌ی برنامه‌های مبتنی بر Blazor
برنامه‌های مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامه‌ی استاندارد ASP.NET Core است که در آن تمام قابلیت‌های سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچه‌ای در سراسر برنامه وجود دارد. در این حالت، کامپوننت‌های Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانی‌های UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننت‌های Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنه‌ی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده می‌گیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامه‌ی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا می‌شود. به Blazor web assembly باید همانند فریم‌ورک‌های SPA (تک صفحه‌ای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامه‌ی SPA، از #C استفاده می‌شود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامه‌های Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار می‌گیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی می‌شود؛ منهای IE 11. در این حالت مرورگر کل برنامه‌ی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامه‌ی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا می‌شود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوری‌ها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورک‌های SPA، نیاز به تهیه‌ی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالت‌های مختلف هاست برنامه‌های Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانه‌های سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامه‌های سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجه‌ی نهایی رندر شده، به سمت کلاینت بازگشت داده می‌شود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمی‌توان از برنامه استفاده کرد.
- با توجه به نیاز به استفاده‌ی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامه‌ها کمتر است. البته اگر تعداد کاربران برنامه‌های شما در یک شبکه‌ی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامه‌ی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائه‌ی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت می‌شود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفاده‌ی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت می‌شود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامه‌های SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژه‌های خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژه‌ی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
بنابراین فقط کافی است دستور dotnet new blazorserver و یا dotnet new blazorwasm را در یک پوشه‌ی خالی اجرا کنیم تا بر اساس قالب‌های پیش‌فرض ارائه شده، بتوان پروژه‌های خالی Blazor Server و یا Blazor WebAssembly را ایجاد کرد.
در قسمت بعد، این دو پروژه‌ی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوه‌ی هاست این برنامه‌ها عنوان شد، بر روی این پروژه‌ها مشاهده خواهیم کرد.
وضعیت توسعه‌ی برنامه‌های وب، پیش از ارائه‌ی Blazor
عموما برای توسعه‌ی برنامه‌های وب، در سمت سرور آنها از زبان‌هایی مانند C#، Java و Python و امثال آنها استفاده می‌شود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریم‌ورک‌ها و کتابخانه‌های جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده می‌شود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبان‌ها، مشکل و وقت‌گیر است. بنابراین چقدر خوب میشد اگر امکان تهیه‌ی هر دو قسمت برنامه‌های وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شده‌است.
با استفاده از Blazor می‌توان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان می‌توان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه می‌توان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالت‌های مختلف هاست و ارائه‌ی برنامه‌های مبتنی بر Blazor
برنامه‌های مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامه‌ی استاندارد ASP.NET Core است که در آن تمام قابلیت‌های سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچه‌ای در سراسر برنامه وجود دارد. در این حالت، کامپوننت‌های Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانی‌های UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننت‌های Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنه‌ی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده می‌گیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامه‌ی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا می‌شود. به Blazor web assembly باید همانند فریم‌ورک‌های SPA (تک صفحه‌ای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامه‌ی SPA، از #C استفاده می‌شود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامه‌های Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار می‌گیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی می‌شود؛ منهای IE 11. در این حالت مرورگر کل برنامه‌ی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامه‌ی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا می‌شود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوری‌ها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورک‌های SPA، نیاز به تهیه‌ی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالت‌های مختلف هاست برنامه‌های Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانه‌های سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامه‌های سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجه‌ی نهایی رندر شده، به سمت کلاینت بازگشت داده می‌شود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمی‌توان از برنامه استفاده کرد.
- با توجه به نیاز به استفاده‌ی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامه‌ها کمتر است. البته اگر تعداد کاربران برنامه‌های شما در یک شبکه‌ی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامه‌ی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائه‌ی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت می‌شود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفاده‌ی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت می‌شود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامه‌های SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژه‌های خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژه‌ی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
C:\Users\Vahid>dotnet new --list Templates Short Name Language Tags -------------------------------------------- ------------------- ------------ ---------------------- Blazor Server App blazorserver [C#] Web/Blazor Blazor WebAssembly App blazorwasm [C#] Web/Blazor/WebAssembly
در قسمت بعد، این دو پروژه‌ی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوه‌ی هاست این برنامه‌ها عنوان شد، بر روی این پروژه‌ها مشاهده خواهیم کرد.
در الگوهایی که به عنوان واسط بین اپلیکیشن و دیتابیس تعریف میکنیم نام دو الگوی Repository و Unit of work به چشم میخورد. در این سایت بارها این مباحث به صورت گفتمان و مقالات تکرار شده‌اند و میدانیم که این الگوها کمک شایانی برای بالا بردن کارآیی برنامه، عدم تکرار کد، قابلیت استفاده مجدد و راحتی کار برای آزمون‌های واحد و چهارچوب‌های تقلید میکنند.
Unit of Work یا الگوی کار در واقع یک الگو، جهت جمع آوری عملیات کار با دیتابیس است که همه عملیات را تحت یک تراکنش به سمت دیتابیس ارسال میکند تا مبحث Atomic بودن عملیات، به مرحله اجرا گذاشته شود. در صورتیکه یکی از عملیات با نقص یا خطایی روبرو شود، کل عملیات Roll back یا برگشت میخورد. از آنجا که دیتابیس‌های معدودی چون Ravendb این مراحل را تا حدی پیاده سازی میکنند نباید از مونگو هم چنین انتظاری نداشته باشید. مونگو برخورد تراکنشی یا اتمیک ندارد؛ پس پیاده سازی الگوی واحد کاری تاثیری بر روی روند کاری آن ندارد. هر چند تعدادی مثال بدین شکل پیاده شده‌اند، ولی در عمل حقیقی نیستند و تنها یک حرکت مشابه داشته‌اند.
ولی الگوی repository برای پرهیز از تکرار کد، قابلیت به روزرسانی کد و همچنین عملیاتی چون آزمون‌های واحد و چهارچوب تقلید به کار میرود. وابستگی بین اشیاء را کاهش داده و باعث ایجاد یک کد با دوام‌تر میگردد.
ابتدا قبل از هر چیزی نیاز است تا اتصالات یا ساخت کانکشن به سرور و همچنین دریافت دیتابیس مورد نظر را در قالب یک کلاس تعریف نماییم. نام آن را MongoDbContext میگذارم:
در حالت بالا شما میتوانید در سازنده کلاس اتصال را برقرار کرده و دیتابیس را دریافت نمایید و از متد GetCollection در سطوح بالاتر، نوع کالکشن درخواستی خود را اعلام کنید. اگر به خط اول کلاس دقت نمایید میبینید که ما از اینترفیسی به نام IMongoDbContext که شامل خطوط زیر میباشد استفاده کردیم و دلیل استفاده این است که اگر قرار باشد از کلاس کانتکست، در کلاس‌های repository استفاده شود، ایجاد وابستگی میکند. چرا که معلوم نیست این کانتکست دقیقا چیست و از کجا آمده است و در آزمون واحد و همچنین تقلید دست ما را می‌بندد و الگوی repository را مردود اعلام میکند. پس از این حیث یک اینترفیس با محتوای زیر تولید کرده‌ایم که از این پس از آن در کدها استفاده میکنیم و پر کردن این اینترفیس‌ها را از طریق تزریق وابستگی‌ها در حالت Constructor Injection که ساده‌ترین نوع آن است انجام میدهیم:
در صورتیکه دوست دارید محتوای‌های دیگری را چون کانکشن استرینگ و .. نیز در اینجا بگنجانید، به عهده خود شماست. تنها نیاز به تغییراتی کوچک است.
در مرحله بعد یک IMongoDbRepositry ساخته و محتوای آن را به شکل زیر پر میکنیم:
در اینجا کلاس‌ها را از نوع جنریک تعریف میکنیم تا کاربر بتواند هر نوع کلاسی را که نیاز دارد، به سمت این مخزن ارسال کند. در پیاده سازی هم به شکل زیر آن را تعریف میکنیم:
همانطور که میبینید در ابتدا در سازنده از طریق یک کتابخانه‌ی تزریق وابستگی‌ها (که در اینجا من از Structure map استفاده کرده‌ام) شیء ImongoDbContext را مقدار دهی میکنیم. الان اگر در اینجا بجای تعریف اینترفیس، از همان کلاس مستقیما استفاده میکردیم، بین دو لایه repository و context یک وابستگی ایجاد میشد. ولی در اینجا کانتکست میتواند هر چیزی باشد. بعد از آن به تعریف متد مورد نظر پرداخته‌ایم. البته با توجه به اینکه این تنها یک مثال است، بنده تنها یکی از این متدها را به عنوان نمونه نشان داده‌ام و میتوانید فایل‌های کامل آن را در انتهای مقاله دریافت نمایید. همانطور که مشاهده میکنیم، متدها به صورت غیرهمزمان نوشته شده‌اند که باعث مقیاس پذیری برنامه میشوند و در اینجا از متدهای همزمان استفاده نکرده‌ایم؛ چرا که افرادی که از دیتابیس‌های غیر رابطه‌ای استفاده میکنند، نیاز به مقیاس پذیری بالایی دارند. به همین دلیل نیاز چندانی به استفاده از متدهای همزمان دیده نمیشود. ولی خودتان در صورت تمایل میتوانید آنها را به اینترفیس اضافه کنید. در ضمن در کد بالا متد خصوصی را جهت دریافت کالکشن نوشته‌ایم تا دریافت کالکشن را در کدها، تا حدی خلاصه‌تر و شیواتر کنیم.
الگوی بالا در یک کنترلر به شرح زیر استفاده شده است:
در کد بالا رستورانهایی را که 400 نفر یا بیشتر ظرفیت پذیرایی دارند، واکشی کرده و در ویوو نشان میدهد. در اینجا الگوی repo، توسط تزریق وابستگی‌ها ساخته شده و کانتکست آنها به همین شکل ساخته خواهد شد و در کل کنترلر، قابلیت استفاده را دارند.
MongoRepository.zip
Unit of Work یا الگوی کار در واقع یک الگو، جهت جمع آوری عملیات کار با دیتابیس است که همه عملیات را تحت یک تراکنش به سمت دیتابیس ارسال میکند تا مبحث Atomic بودن عملیات، به مرحله اجرا گذاشته شود. در صورتیکه یکی از عملیات با نقص یا خطایی روبرو شود، کل عملیات Roll back یا برگشت میخورد. از آنجا که دیتابیس‌های معدودی چون Ravendb این مراحل را تا حدی پیاده سازی میکنند نباید از مونگو هم چنین انتظاری نداشته باشید. مونگو برخورد تراکنشی یا اتمیک ندارد؛ پس پیاده سازی الگوی واحد کاری تاثیری بر روی روند کاری آن ندارد. هر چند تعدادی مثال بدین شکل پیاده شده‌اند، ولی در عمل حقیقی نیستند و تنها یک حرکت مشابه داشته‌اند.
ولی الگوی repository برای پرهیز از تکرار کد، قابلیت به روزرسانی کد و همچنین عملیاتی چون آزمون‌های واحد و چهارچوب تقلید به کار میرود. وابستگی بین اشیاء را کاهش داده و باعث ایجاد یک کد با دوام‌تر میگردد.
ابتدا قبل از هر چیزی نیاز است تا اتصالات یا ساخت کانکشن به سرور و همچنین دریافت دیتابیس مورد نظر را در قالب یک کلاس تعریف نماییم. نام آن را MongoDbContext میگذارم:
public class MongoDbContext : IMongoDbContext
{
public const string DatabaseName = "MongoDbTest";
private static readonly IMongoClient _client;
private static readonly IMongoDatabase Database;
static MongoDbContext()
{
_client = new MongoClient();
Database = _client.GetDatabase(DatabaseName);
}
public IMongoCollection<TEntity> GetCollection<TEntity>()
{
return Database.GetCollection<TEntity>(typeof(TEntity).Name.ToLower() + "s");
}
} public interface IMongoDbContext
{
IMongoCollection<TEntity> GetCollection<TEntity>();
} در مرحله بعد یک IMongoDbRepositry ساخته و محتوای آن را به شکل زیر پر میکنیم:
public interface IMongoDbRepository
{
Task<List<TEntity>> GetMany<TEntity>(FilterDefinition<TEntity> filter) where TEntity : class, new();
} public class MongoRepository : IMongoDbRepository
{
private IMongoDbContext _mongoDbContext ;
public MongoRepository(IMongoDbContext mongoDbContext)
{
_mongoDbContext = mongoDbContext;
}
public async Task<List<TEntity>> GetMany<TEntity>(FilterDefinition<TEntity> filter) where TEntity : class, new()
{
var collection = GetCollection<TEntity>();
var entities = await collection.Find(filter).ToListAsync();
return entities;
}
private IMongoCollection<TEntity> GetCollection<TEntity>()
{
return _mongoDbContext.GetCollection<TEntity>();
}
} الگوی بالا در یک کنترلر به شرح زیر استفاده شده است:
public class HomeController : Controller
{
private IMongoDbRepository _mongoDbRepository;
public HomeController(IMongoDbRepository mongoDbRepository)
{
this._mongoDbRepository = mongoDbRepository;
}
// GET: Home
public async Task<ActionResult> Index()
{
var filter = Builders<Resturant>.Filter.Gte("Capacity", 400);
var c =await _mongoDbRepository.GetMany<Resturant>(filter);
return View(c);
}
} MongoRepository.zip
Easy to get started sample reference microservice and container based application. Cross-platform on Linux and Windows Docker Containers, powered by .NET Core 2.0 and Docker engine. Supports Visual Studio 2017, VS for Mac and CLI based environments with Docker CLI, dotnet CLI, VS Code or any other code editor.
از قبل در لینوکس وجود داشت در ورژن 17.06 برای ویندوز نیز موجود می‌شود.
Secrets are a first-class citizen in Docker. They're for storing sensitive application data, like API keys and connection strings. Secrets have been in Docker on Linux for a while, and with Docker version 17.06 they're coming to Windows.
Many developers I talk to are either using Docker actively or planning to adopt containers in their environment. Containers are an important trend in our industry and .NET is part of that. Microsoft and Docker have been working together so that you’ll have a great experience using Docker with .NET apps.
Today the Docker team announced the availability of a technical preview of the Docker Engine for Windows Server 2016. This is huge for us and all software teams that work primarily on the Windows platform
یک لینک هم در مورد Dockerها در ویندوز سرور 2016 از سایت weblogs.asp.net Visual Studio 2015 Tools for Docker - August Preview
برای اطلاعات بیشتر در مورد Dockerها هم میتوانید به ترجمه این مصاحبه مراجعه کنید ^^^
