تعداد ویدئو | 71 |
---|---|
زمان دوره | 03:42:45 |
مترجم | پرووید |
ناظر ترجمه | پرووید |
دوبلر | پرووید |
ناظر دوبلاژ | پرووید |
سایت منتشر کننده | پلورال سایت |
آموزش کار با داکر (Docker) در برنامه های دات نت یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته آموزشی، کار کردن با داکر در مدرن سازی و توسعه معماری اپلیکیشن های مبتنی بر دات نت فریم ورک است که با نام اصلی Modernizing .NET Framework Apps with Dockerاز شرکت Pluralsight منتشر شده است.
در سال 2000 آقای روی فیلدینگ (Roy Fielding) سبک معماری REST که سرنام عبارت Representational State Transfer می باشد را به منظور روشی برای طراحی وب سرویس ها معرفی کرد. REST یک سبک معماری و یا architectural style برای ساخت سیستم های توزیع شده بر اساس hypermedia می باشد. سبک معماری REST مستقل از پروتکلی است که با استفاده از آن پیادهسازی میشود. به عبارت دیگر این سبک معماری لزوماً وابسته به HTTP نمی باشد. با این وجود بسیاری از پیاده سازی های REST API امروز از پروتکل HTTP استفاده میکنند. یکی از مزیت های اصلی استفاده کردن از سبک معماری REST و پروتکل HTTP استفاده کردن از استانداردهای باز می باشد. به عبارت دیگر این ترکیب باعث میشود که پیاده سازی API و یا اپلیکیشن های کلاینت به یکدیگر وابسته نباشد. به عنوان مثال یک وب سرویس REST میتواند با تکنولوژی ASP.NET ایجاد شود و اپلیکیشنهای کلاینت میتوانند از هر زبان و یا مجموعه ابزارهایی برای تولید کردن HTTP request ها و دریافت کردن HTTP response ها از API توسعه داده شده استفاده کنند.
استفاده کردن از resource ها در طراحی یک API که با سبک معماری REST توسعه داده شده است بسیار مهم می باشد. به عبارت دیگر در توسعه این گونه از API ها بایستی تمرکز را بر روی موجودیت های تجاری و یا business entity های بگذاریم که web API آنها را به بیرون منتشر می کند. به عنوان مثال؛ در یک سیستم تجارت الکترونیک entity های اصلی ممکن است مواردی از قبیل customer و order که به ترتیب مشتری و یا سفارش می باشند، باشد. ایجاد کردن یک order جدید میتوانند با ارسال کردن یک request از نوع HTTP POST که شامل اطلاعات مربوط به آن order و یا سفارش است انجام بپذیرد. ضمناً HTTP response نیز می تواند مشخص کننده این باشد که سفارش و یا order ارسال شده با موفقیت ثبت گردیده است یا خیر.
در صورت امکان بایسیتی تلاش شود که URI های مربوط به resource ها در قالب اسم های زبان انگلیسی پیاده سازی شوند. فعل ها نمایانگر عملیات و یا operation های هستند که بر روی هر resource قابل انجام میباشد. مورد دیگر که در طراحی REST API ها بسیار اهمیت دارد، استفاده کردن از HTTP method ها برای پیاده سازی عملیات مربوط به API می باشد. در پروتکل HTTP تعدادی از متد های مختلفی وجود دارند که هر کدام از آنها به یک request معنا و یا semantic اضافه می کنند. معمول ترین HTTP method هایی که توسط web API های RESTful مورد استفاده قرار میگیرند، شامل GET و POST و PUT و PATCH و DELETE هستند.
فعل GET: از GET به منظور بازیابی کردن یک نمایش ویا representation مربوط به یک resource در یک URI خاص قرار گرفته است استفاده می شود. بدنه response دریافت شده از سرور شامل جزئیات مربوط به resource درخواست داده شده خواهد بود.
فعل POST: از POST به منظور ایجاد کردن یک resource جدید در URI مشخص شده استفاده می کنیم. بدنه اینگونه از request ها شامل جزئیات مربوط به resource جدید که در حال اضافه کردن آن هستیم می باشد. دقت کنید که از فعل POST می توانیم به منظور انجام عملیاتی که به ایجاد کردن یک resource جدید منجر نمیشوند نیز استفاده کنیم.
فعل PUT: از این فعل برای ایجاد کردن و یا جایگزین کردن یک resource که در یک URI خاص قرار گرفته است استفاده می کنیم. بدنه اینگونه از request ها شامل اطلاعات مربوط به resource است که قصد اضافه کردنو یا به روز رسانی کردن آن را داریم.
فعل PATCH: از PATCH به منظورعملیات به روز رسانی جزئی و یا partial update بر روی یک resource استفاده می کنیم. بدنه اینگونه ها از request ها شامل مجموعه تغییراتی هستند که می بایستی بر روی یک resource اعمال بشوند.
فعل DELETE: از DELETE به منظور حذف کردن یک resource که در یک URI خاص قرار گرفته است استفاده می کنیم.
فصل اول: مقدمه دوره آموزشی
فصل دوم: بسته بندی کردن و یا Package کردن اپلیکیشن های ASP.NET برای استفاده شدن در داکر
فصل سوم: اجرا کردن Database های SQL Server در Containerها
فصل چهارم: مقیاس کردن و یا Scale کردن Performance با استفاده از NATS به عنوان Message Queue
فصل پنجم: اضافه کردن Self-service Analytics با Elasticsearch و Kibana
فصل ششم: لحاظ کردن Self-service Content Management با Umbraco
فصل هفتم: مدیریت و Monitor کردن Solution های چند Container
فصل هشتم: بررسی کردن مسیر رفتن به Production
تمامی حقوقی مادی و معنوی متعلق به گروه آموزشی پرووید است.
نقد و بررسیها
هیچ دیدگاهی برای این محصول نوشته نشده است.