مطالب
نحوه راه اندازی مجدد یک دیتابیس اس کیوال سرور پس از پر شدن هارد دیسک

امروز یکی از برنامه‌ها (برنامه ASP.Net) با مشکل زیر مواجه شده بود:

پیغام خطا:
اتصال با سرور اس کیوال قطع شده است. لطفا با مسئول مربوطه هماهنگ نمائید.
SQLErr:4060

این خطا به معنای عدم امکان باز کردن دیتابیس است.

در طی این مدت با موارد زیادی از این دست (مشکلات مختلف عدم امکان برقراری ارتباط با اس کیوال سرور) برخورد داشتم که خلاصه تمام آن‌ها تابع زیر شده است:
public void CheckSQLServerStat(Exception ex)
{
try
{
SqlException ar = (SqlException) ex;
switch (ar.Number)
{
case 2:
case 11:
case 17:
case 40:
case 4060:
case 1326:
case 17142:
case 18456:
HttpContext.Current.Response.Write("<br/>" + "اتصال با سرور اس کیوال قطع شده است. لطفا با مسئول مربوطه هماهنگ نمائید." + "<br/> SQLErr:" + ar.Number + "<br/>");
break;
}
}catch{}
}

هنگام رخ‌دادن یک خطا (در توابعی که با اس کیوال سرور کار می‌کنند)، exception حاصل را به این تابع پاس کرده و خطای حاصل را به صورت مختصر و مفید به کاربر نشان می‌دهم. کاربر متوجه می‌شود که یک مشکل اساسی در سیستم رخ داده است. برنامه نویس هم با جستجو در مورد شماره خطا می‌تواند مشکل یابی کند. تابع Response.Write هم بالاتر از هر المان دیگری در صفحه، این خطا را به شکل واضحی نمایش می‌دهد. (کلا ریخت صفحه را به هم می‌ریزد که از لحاظ روانی لازم است! چون عملا در این حالت سیستم از کار افتاده است)

به management studio اس کیوال سرور که مراجعه کردم، علامت خاصی کنار نام دیتابیس نبود فقط برخلاف سایر دیتابیس‌ها که آیکون + مربوط به باز شدن tree آن وجود دارد، این یک مورد آن‌را نداشت. بر روی نام دیتابیس کلیک راست کردم و انتخاب خواص، خطای زیر نمایش داده شد:
------------------------------
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------
Database 'dbName' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details. (Microsoft SQL Server, Error: 945)
------------------------------

بله! دیتابیس قابل باز شدن نبود چون درایو مربوطه پر شده بود. بعد از خالی کردن درایو و باز کردن فضای لازم، باز هم دیتابیس به حالت اجرایی و قابل استفاده برنگشت. یک راه این است که کل سرویس مربوط به اس کیوال سرور را استاپ و استارت کرد. که البته این مورد سبب قطع ارتباط کل مجموعه می‌شود. یا راه دیگر اجرای چند سطر زیر است که دیتابیس را مجددا راه اندازی خواهد کرد (بدون نیاز به ری استارت سرویس)

use master;
alter database dbName set OFFLINE;
alter database dbName set online;

به این صورت دیتابیس مربوطه به حالت عادی بازگشت و قابل استفاده شد.

مطالب
اهمیت Controller های ساده در ASP.NET MVC
Controller‌ها به نوعی رابط بین View و Model هستند. ساده ترین محل برای قرار دادن کد‌های تصمیم گیری (decision-making code) ، قرار دادن منطق تجاری و یا فراهم ساختن داده برای View مثل ایجاد یک لیست از Select List برای یک DropDownList می‌باشند. اما انجام این کار‌ها به نرم افزار ما پیچیدگی تحمیل می‌کند. Controller‌ها باید در طول زمان توسعه‌ی یک نرم افزار کم حجم و سبک باقی بمانند. در این مطلب  بحث شد که یکی از اهداف استفاده از ASP.NET MVC نوشتن نرم افزار هایی تست پذیر می‌باشد. نوشتن آزمون واحد و نگهداری Controller هایی که مسئولیت زیادی بر عهده دارند سخت می‌باشد. Controller‌ها باید به نحوی توسعه پیدا کنند که نگهداری آن‌ها ساده باشد ، تست پذیر باشند و اصل SRP  را رعایت کرده باشند.
نگهداری آسان
کدی که درک آن سخت باشد ، تغییر دادن آن نیز سخت است ، هنگامی که درک کدی سخت باشد زمینه برای به وجود آمدن خطاها ، دوباره کاری و سردرد فراهم می‌شود. هنگامی که مسئولیت یک Action به صورت شفاف مشخص نباشد و انواع و اقسام کار‌ها به آن سپرده شده باشد تغییر در آن سخت می‌شود ،  ممکن است این تغییر باید چند جای دیگر هم داده شود در نتیجه فاز نگهداری هزینه و زمان اضافی به نرم افزار تحمیل می‌کند.
تست پذیری
 بهترین راه برای اطمینان از این که درک و تست پذیری سورس کد ما ساده هست انجام و تمرین توسعه‌ی تست محور (TDD) می‌باشد. هنگامی که از روش TDD استفاده می‌کنیم با سورسی کدی کار می‌کنیم که هنوز وجود ندارد. در این مرحله از به وجود آمدن کلاس هایی که تست آن‌ها دشوار یا غیر ممکن است (به دلیل داشتن مسئولیت‌های اضافی) از جمله Controller‌ها جلوگیری می‌شود. نوشتن آزمون‌های واحد برای Controller‌های کم حجم ساده می‌باشد. 
تمرکز بر روی یک مسئولیت
 بهترین راه برای ساده سازی Controller‌ها گرفتن مسئولیت‌های اضافی از آن می‌باشد  به Action زیر توجه کنید :
  
public RedirectToRouteResult Ship(int orderId)
{
   User user = _userSession.GetCurrentUser();
   Order order = _repository.GetById(orderId);
   if (order.IsAuthorized)                                
   {
      ShippingStatus status = _shippingService.Ship(order);
      if (!string.IsNullOrEmpty(user.EmailAddress))      
      {
         Message message = _messageBuilder
            .BuildShippedMessage(order, user);
         _emailSender.Send(message);
      }
      if (status.Successful)
      {
         return RedirectToAction("Shipped", "Order", new {orderId});
      }
   }
   return RedirectToAction("NotShipped", "Order", new {orderId});
}
 این Action کار زیادی انجام می‌دهد ، تقریبا می‌توان تعداد مسئولیت‌های این Action را با شمارش تعداد If‌ها پیدا کرد . مسئولیت تصمیم گیری درباره این که آیا Order مورد نظر آماده برای تحویل است یا خیر به این Action سپرده شده ، همچنین تصمیم گیری درباره اینکه آیا کاربر دارای آدرس ایمیل جهت ارسال ایمیل می‌باشد یا خیر به این Action سپرده شده است. منطق‌های domain logic و business logic نباید در کلاس‌های presentation همانند Controller‌ها قرار داده شود. تست و نگهداری کدی مثل کد بالا دشوار خواهد بود. Refactoring که باید در این Code اعمال شود Refactor Architecture by Tiers  نام دارد. این Refactoring به توسعه دهنده می‌گوید که منطقی که در لایه‌ی نمایش (Presentation) پیاده کرده را به لایه‌ی Business انتقال دهد. پس از انتقال منطق کد بالا به OrderShippingService ، کد Action ما ساده‌تر می‌شود : 
public RedirectToRouteResult Ship(int orderId)
{
   var status = _orderShippingService.Ship(orderId);
   if (status.Successful)
   {
      return RedirectToAction("Shipped", "Order", new {orderId});
   }
   return RedirectToAction("NotShipped", "Order", new {orderId});
}
پس از انتقال منطق تجاری به محل مناسب خودش تنها مسئولیتی که برای برای Controller باقی مانده این است که کاربر را به کجا Redirect کند. پس از این Refactoring علاوه برا اینکه مسئولیت‌ها در جای مناسب خود قرار گرفتند ، اکنون می‌توان به سادگی منطق کار را بدون تحت تاثیر قرار گرفتن کد‌های لایه‌ی نمایش تغییر داد. 
در آینده به تکنیک‌های ساده سازی Controller‌‌ها خواهیم پرداخت.
مطالب
Iterators در ES 6
یکی از اهداف ES 6، استاندارد سازی کار با Iterators و Iterables است. فرض کنید شیءایی را داریم که مجموعه‌ای از عناصر را در بر دارد. این مجموعه می‌تواند آرایه‌ای از عناصر باشد و یا set و map اضافه شده به ES 6 و یا حتی اشیایی که در زمان اجرا ایجاد می‌شوند. اگر این مجموعه Iterable باشد، حرکت بر روی آن یک Iterator را تولید می‌کند که امکان حرکت در این مجموعه را آیتم به آیتم میسر خواهد کرد:
 


هر Iterator شیءایی است که دارای متد next می‌باشد. هر بار که این متد فراخوانی می‌شود، عضو بعدی مجموعه، بازگشت داده خواهد شد. خروجی هر مرحله، درون یک شیء با دو خاصیت value و done قرار داده می‌شود. value‌، مقدار مرحله‌ی بعد است و done مشخص می‌کند که آیا به پایان مجموعه رسیده‌ایم یا خیر (بنابراین در اینجا تعداد اعضای Iterator مشخص نیست).


مثالی از پیمایش یک آرایه با چندین روش مختلف

در مثال زیر، آرایه‌ای از اعداد را داریم که نیاز است جمع اعضای آن محاسبه شود:
 let sum = 0;
let numbers = [1,2,3,4];
این‌کار را می‌توان با استفاده از یک حلقه‌ی for متداول انجام داد. از آنجائیکه آرایه دارای خاصیت length است، می‌توان از آن جهت تعیین حد بالایی آرایه استفاده کرد:
 // for loop
sum = 0;
for(let i =0; i < numbers.length; i++){
     sum += numbers[i];
}
//sum = 10
روش دوم انجام این‌کار، استفاده از حلقه‌ی for in است. این حلقه هربار ایندکس بعدی قابل استفاده‌ی آرایه را بازگشت می‌دهد که از آن می‌توان جهت دسترسی به اعضای آرایه استفاده کرد:
 // for in
sum = 0;
for(let i in numbers) {
    sum += numbers[i];
}
//sum = 10
روش دیگر انجام این‌کار با استفاده از Iterators است:
 // iterator
sum = 0;

let iterator = number.values();
let next = iterator.next();
while(!next.done){
    sum += next.value;
    next = iterator.next();
}
//sum = 10
برای کار با Iterators، ابتدا باید یک شیء Iterator را از مجموعه‌ایی که در اختیار داریم، تولید کنیم. برای مثال آرایه‌ها دارای متدی به نام values هستند که با فراخوانی ()number.values، سبب تولید یک Iterator می‌شوند. این Iterator امکان حرکت بین مقادیر آرایه را در اینجا میسر می‌کند.
مرحله‌ی بعدی، فراخوانی متد next این Iterator است. این عملیات باید در طی یک حلقه، تا پایان کار Iterator انجام شود. همانطور که در ابتدای بحث نیز عنوان شد، خروجی متد next یک شیء است که دارای خواص value و done می‌باشد. اگر done مساوی true شد، یعنی به پایان کار پیمایش رسیده‌ایم.
البته هدف از این مثال، صرفا نمایش سطح پایین کار با Iterators بود. در عمل از حلقه‌ی جدیدی به نام for of برای انجام این پیمایش استفاده می‌شود.


معرفی حلقه‌ی for of

جاوا اسکریپت سال‌ها است که دارای حلقه‌ی for in می‌باشد و نمونه‌ای از کاربرد آن‌را در مثال قبل مشاهده کردید. اگر این حلقه بر روی آرایه‌ها فراخوانی شود، هربار ایندکس پیمایش شده را بازگشت می‌دهد و اگر بر روی یک شیء فراخوانی شود، خواص آن شیء را بازگشت می‌دهد:
 var person = { first: "Vahid", last "N" };
for(let i in person) {
   console.log(person[i]);
}
در این مثال، i بار اول به first و بار دوم به خاصیت last اشاره می‌کند.
چون این حلقه صرفا ایندکس‌ها و کلیدها را بازگشت می‌دهد، جهت کار با Iterators که نیاز است به مقادیر اعضاء دسترسی پیدا کنیم، مناسب نیست. به همین جهت در ES 6، حلقه‌ی جدیدی به نام for of برای کار با Iterators معرفی شده‌است:
 let numbers = [1,2,3,4];
for(let i of numbers) {
   console.log(i);
}
این حلقه برخلاف for in، بر روی values، کار پیمایش را انجام می‌دهد. همچنین به صورت خودکار در پشت صحنه متد next یک Iterator را فراخوانی می‌کند و خاصیت done آن‌را بررسی کرده و زمانیکه این خاصیت مساوی true شد، حلقه را خاتمه می‌دهد. برای نمونه مثال سطح پایین while دار ابتدای بحث را به نحو ساده‌تری با حلقه‌ی for of ذیل می‌توان جایگزین کرد:
let sum = 0;
let numbers = [1,2,3,4];

for(let n of numbers){
   sum += n;
}

for of یکی از روش‌های پیمایش Iterators است. پارامترهای rest و همچنین Array.from نیز چنین قابلیتی را فراهم می‌کنند.

امکان پیاده سازی Iterators سفارشی نیز وجود دارد که پیشنیاز آن، درک مبحث جدید Symbols است که به صورت جداگانه‌ای بررسی خواهد شد.
مطالب
الگوی سردر Facade Pattern
یکی از الگوهای ساختاری Gang Of Four، استفاده از الگوی Facade است که پیچیدگی‌های یک سیستم را مخفی می‌سازد و با ارائه یک پیاده سازی ساده‌تر، استفاده از آن و تست آن را راحت‌تر می‌سازد. این الگو یک کلاس یا یک سیستمی را با متدها و رویدادهایی ساده، در اختیار ما قرار می‌دهد و در یک لحظه، تنها با یک کلاس واحد سر و کله می‌زنیم. احتمالا بسیاری از شما از این الگو استفاده کرده‌اید، ولی شاید با اسم آن آشنا نبوده‌اید.

کار این کلاس در واقع ترکیب کلاس‌ها و کتابخانه‌های کاری مشخص است که نیاز به ارتباط با یکدیگر را دارند. به عنوان مثال یک برنامه کتابخانه، برای وظیفه‌ای چون امانت یک کتاب نیاز است تا چندین کلاس مختلف را با یکدیگر به کار بگیرد که این وظایف شامل موارد زیر می‌باشند:
  1. بررسی وجود کتاب
  2. بررسی تعداد موجود یک کتاب در کتابخانه
  3. بررسی وضعیت امانی کتاب (آیا کتاب در دست کسی از قبل امانت است؟ یا کتاب برای امانت آزاد است؟)
  4. در صورتی که کتابی بیش از زمان مورد نظر در دست کسی امانت است، با یک پیامک از او بخواهیم که کتاب را بازگرداند.
تمامی موارد بالا تنها قسمتی از انجام یک عمل ساده هستند که در یک گروه جای می‌گیرند؛ ولی در واقع از چندین کلاس جدا مثل کلاس کتاب، امانت، سیستم پیامکی و ... استفاده شده است . الگوی Facade به ما کمک می‌کند تا پیچیدگی و تعداد خطوط اجرا را در سطوح بالاتر مخفی سازیم و تنها با صدا زدن یک یا چند متد ساده، کار را به اتمام برسانیم. این کار باعث کاهش کد و خوانایی برنامه در سطوح بالاتر می‌شود.

در کد زیر ما قصد داریم نمونه‌ای از اجرای این الگو را ببینیم. ابتدا سه کلاس اطلاعاتی زیر را ایجاد می‌کنیم:
کلاس کتاب Book:
    class Book
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public int Quantity { get; set; }
        public bool IsLoanable { get; set; }
    }

کلاس کاربر User
 class User
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public  string CellPhoneNumber { get; set; }
    }

کلاس امانت Loan
  class Loan
    {
       public DateTime ExpiredDate { get; set; }
        public User User { get; set; }
    }

بعد از آن سه کلاس را برای مدیریت کتاب، مدیریت امانت و مدیریت پیامکی، ایجاد می‌کنیم:
کلاس کتاب BookManager:
 class BookManager
    {
        public Book GetBook(int id)
        {
                return new Book()
                {
                    Id=id,
                    Title = "a book",
                    Quantity = 3,
                    IsLoanable = true
                };
        }
    }
کلاس بالا یک کتاب را با موجودی سه عدد بازمی‌گرداند که خاصیت IsLoanable آن می‌گوید کتاب را برای بردن به خانه امانت می‌دهند؛ ولی اگر کتاب به فرض یک کتاب مرجع باشد باید False برگرداند تا از امانت آن خودداری شود.

کلاس LoanManager برای مدیریت امانت‌ها
 public int IsLoan(int bookId)
        {
            return 2;
        }

        public List<Loan> GetLoans(int bookId)
        {
            return new List<Loan>()
            {
                new Loan()
                {
                    ExpiredDate = DateTime.Now.AddDays(-15),
                    User = new User()
                {
                    Id = 2,
                    Title = "User1",
                    CellPhoneNumber = "342342424"
                }
                },
                new Loan()
                {
                    ExpiredDate = DateTime.Now.AddDays(5),
                    User = new User()
                        {
                            Id = 56,
                            Title = "User56",
                            CellPhoneNumber = "324324324324"
                        }
                }
            };
        }
این کلاس شامل دو متد است که اولین متد آن کد کتاب را دریافت می‌کند و تعداد افرادی را که در حال حاضر نسخه‌های مختلف آن را به امانت برده‌اند، برمی‌گرداند. در کد بالا عدد دو بازگردانده می‌شود که میگوید از نسخه‌های موجود این کتاب در کتابخانه، دوتای آن‌ها به امانت برده شده‌اند. در متد دوم، کد کتاب داده شده و امانت‌های فعلی آن کتاب که همان دو عدد بالا می‌باشد را برگشت می‌دهد.

در نهایت سومی کلاس مدیریتی برای پیامک هاست:
   class SmsManager
    {
        public void SendMessage(string number)
        {
            Console.WriteLine("please take back the book to the library : "+number);
        }
    }

و در کلاس Facade داریم
    class FacadeBookLoan
    {
        private readonly BookManager _bookManager;
        private readonly LoanManager _loanManager;
        private readonly SmsManager _smsManager;
        public FacadeBookLoan()
        {
            _bookManager = new BookManager();
            _loanManager=new LoanManager();
            _smsManager=new SmsManager();
        }

        public int IsLoanable(int bookId)
        {
            var book = _bookManager.GetBook(2);
            if (book == null)
                return -2;
            if (!book.IsLoanable)
                return -1;
            var howManyBookIsLoaned = _loanManager.IsLoan(bookId);

            if(howManyBookIsLoaned>0) ManageLoaners(bookId);

            return book.Quantity - howManyBookIsLoaned;
        }

        private void ManageLoaners(int bookId)
        {
            var loans = _loanManager.GetLoans(bookId);

            foreach (var loan in loans)
            {
                if (loan.ExpiredDate > DateTime.Now)
                {
                    _smsManager.SendMessage(loan.User.CellPhoneNumber);
                }
            }
        }
    }
در این کلاس متد IsLoanable چک می‌کند که آیا کتاب قابل امانت هست یا خیر. در اینجا مرحله به مرحله، وجود کتاب و قابلیت امانت کتاب بررسی شده و در صورت نتیجه، کد وضعیت -1 یا -2 بازگردانده می‌شوند و در مرحله بعد تعداد نسخه‌های آن کتاب که در حال حاضر در دست امانت هستند، بررسی می‌شوند. اگر کتابی در درست امانت باشد، متد خصوصی صدا زده شده و به کاربرانی که بیش از مدت معینی یک نسخه از کتاب را داشته‌اند، پیامک می‌زند که کتاب را بازگردانید؛ چرا که نسخه‌ها در حال کاهش هستند و در مرحله بعد تعداد نسخه‌های موجود از آن کتاب را در کتابخانه باز می‌گرداند که در این مثال تنها یک نسخه از آن کتاب در کتابخانه موجود است و دو تای آن‌ها در دست امانت هستند که یکی از امانت دارها 15 روز است کتاب را در تاریخ معینی تحویل نداده است.

کد بدنه اصلی برنامه:
var myfacade=new FacadeBookLoan();
var loansCount= myfacade.IsLoanable(2);
Console.WriteLine(loansCount > 0 ? "you can loan the book" : "you can't loan the book");
خروجی برنامه:
please take back the book to the library : 324324324324
you can loan the book
مطالب
پیاده سازی مکانیسم سعی مجدد (Retry)
فرض کنید در برنامه‌ای که نوشته‌اید، قصد فراخونی یک وب سرویس را دارید. به طور قطع نمی‌توان همیشه انتظار داشت این سرویس مورد نظر بدون هیچ مشکلی اجرا شود و خروجی مورد نظر را بدهد. برای نمونه ممکن است در لحظه فراخوانی متد مورد نظر، اختلالی در شبکه رخ دهد و فراخوانی سرویس شما با مشکل مواجه شود. در چنین مواقعی دو مورد را پیش‌رو داریم: 
- یک: اعلام نتیجه عدم موفق بودن فراخوانی.
- دو: یک (یا چند) بار دیگر، سعی در فراخوانی سرویس مورد نظر کنیم.
مکانیسم سعی مجدد فقط و فقط محدود به فراخوانی وب سرویس‌ها نمی‌شود. برای نمونه می‌توان به ارسال ایمیل، خطا در اجرای یک کوئری T_SQL و مورادی از این قبیل اشاره کرد.
چرا باید سعی مجدد را پیاده سازی کنیم؟ 
عدم وجود امکان سعی مجدد هیچ چیزی را از پروژه شما سلب نمیکند؛ ولی وجود آن یک امکان را به پروژه شما اضافه میکند که تا حدودی باعث سهولت در استفاده از نرم افزار شما خواهد شد.
نباید‌های مکانیسم سعی مجدد
با خواندن مطالب فوق شاید به این موضوع فکر کنید که مکانیسم سعی مجدد امکان خوبی برای پروژه است و همه بخش‌های پروژه را درگیر این مکانیز کنیم. واقعیت این است که استفاده از مکانیسم سعی مجدد بهتر است محدود به بخش هایی از پروژه شود و نه کل پروژه.
پیش نیاز‌ها
تا به این مرحله با «مکانیسم سعی مجدد» بیشتر آشنا شدیم. برای پیاده سازی یک «سعی مجدد» نیازمندیم یک سری موارد را بدانیم:
یک: میزان تعداد دفعات تلاش 
دو: اختلاف بین هر دو  تلاش مجدد (وقفه)
سه: مقدار افزایش وقفه
چهار: سعی مجدد بر اساس نوع Exception

سه مورد اول از لیست  بالا تقریبا برای یک پیاده سازی سعی مجدد پاسخگو می‌باشد. در ادامه ابتدا قصد داریم یک «سعی مجدد ساده» را نوشته و سپس به معرفی یکی از کتابخانه‌های پرکاربرد آن می‌پردازیم.
قطعه کد زیر را در نظر بگیرد که شبیه ساز ارسال ایمیل می‌باشد:
 public class Mailer
    {
        public static bool SendEmail()
        {
            Console.WriteLine("Sending Mail ...");

            // simulate error
            Random rnd = new Random();
            var rndNumber = rnd.Next(1, 10);
            if (rndNumber != 3) // *
                throw new SmtpFailedRecipientException();

            Console.WriteLine("Mail Sent successfully");
            return true;
        }
    }
خط *  برای شبیه  سازی وقوع یک خطا استفاده شده است.
 قطعه کد زیر برای پیاده سازی مکانیزم سعی مجدد می‌باشد:
 public static class Retry
    {
        public static void Do(Action action,TimeSpan retryInterval,int maxAttemptCount = 3)
        {
            Do<object>(() =>
            {
                action();
                return null;
            }, retryInterval, maxAttemptCount);
        }

        public static T Do<T>(Func<T> action,TimeSpan retryInterval,int maxAttemptCount = 3)
        {
            var exceptions = new List<Exception>();

            for (int attempted = 0; attempted < maxAttemptCount; attempted++)
            {
                try
                {
                    if (attempted > 0)
                    {
                        Thread.Sleep(retryInterval);
                    }
                    return action();
                }
                catch (Exception ex)
                {
                    exceptions.Add(ex);
                }
            }
            throw new AggregateException(exceptions);
        }
    }
قطعه کد فوق ساده‌ترین حالت پیاده سازی Retry می‌باشد که به تعداد MaxAttemptCount سعی در فراخوانی متد مورد نظر خواهد کرد.
یادآوری: متد Do با پارامتر Action در پارامتر اول جهت توابعی که مقدار خروجی ندارند می‌باشد.
همانطور که ذکر شد مقدار Interval بهتر است طبق یک مقدار از پیش تعیین شده افزایش یابد تا درخواست‌های ما با بازه زمانی خیلی کوتاهی نسبت به هم اجرا نشوند. برای رفع این مشکل بعد از Sleep می‌توان مقدار Interval را به صورت زیر افزایش داد:
retryInterval= retryInterval.Add(TimeSpan.FromSeconds(10));
همانطور که بیان کردیم ، قطعه کد نوشته شده فوق برای انجام یک Retry بسیار ساده می‌باشد. موارد دیگری را می‌توان به Retry فوق اضافه نمود. برای نمونه اگر Exception رخ داده شده از نوع مورد نظر ما بود، مجدد Retry کند، در غیر اینصورت از ادامه کار منصرف شود. برای نوشتن هندل کردن نوع Exception می‌توانیم از کتابخانه Polly استفاده کنیم.

کتابخانه Polly
Polly یکی از کتابخانه‌های پرکاربرد است و یکی از امکانات آن، «مکانیسم سعی مجدد» آن، به صورت زیر می‌باشد:


در ساده‌ترین حالت، استفاده از Polly همانند زیر است:

var policy = Policy.Handle<SmtpFailedRecipientException>().Retry();
            policy.Execute(Mailer.SendEmail);

متد Retry، دارای Overload‌های مختلفی است که یکی از آنها مقدار تعداد دفعات تلاش را دریافت می‌کند؛ همانند:

var policy = Policy.Handle<SmtpFailedRecipientException>().Retry(5);

لازم به ذکر است که باید دقیقا Exception مورد نظر را در بخش Config به کار ببرید. برای نمونه اگر کد فوق را همانند زیر به کار ببرید، در صورتیکه متد ارسال ایمیل با خطایی مواجه شود، هیچ تلاشی برای اجرای مجدد نخواهد کرد:

   var policy = Policy.Handle<SqlException>().Retry(5);

برای نمونه می‌توان از متد ForEver آن استفاده کرد تا زمانیکه متد مورد نظر Success نشده باشد، سعی در اجرای آن کند:

Policy
  .Handle<DivideByZeroException>()
  .RetryForever()

جهت کسب اطلاعات بیشتر می‌توانید در مخزن کد آن با سایر قابلیت‌های کتابخانه Polly بیشتر آشنا شوید: Github

اشتراک‌ها
پروژه Angular

پیاده سازی یک شبکه‌ی اجتماعی ساده در Angular

پروژه Angular