مطالب
بررسی روش مشاهده خروجی SQL حاصل از کوئری‌های Entity framework Core
هنوز تا Entity framework Core 1.1، مفهوم interceptors موجود در EF 6.x پیاده سازی نشده‌است. اما شبیه به مفاهیم «ارتقاء به ASP.NET Core 1.0 - قسمت 17 - بررسی فریم ورک Logging»، در EF Core نیز زیرساختی جهت مشاهده‌ی SQL نهایی تولیدی وجود دارد.


ایجاد یک ثبت کننده‌ی وقایع EF Core

مرحله‌ی اول مشاهده‌ی خروجی‌های نهایی EF Core، پیاده سازی اینترفیس ILoggerProvider است که در آن قرار است وهله‌ی از نوع ILogger بازگشت داده شود. به همین جهت یک کلاس تو در توی خصوصی را در اینجا مشاهده می‌کنید که اینترفیس ILogger را نیز پیاده سازی کرده‌است:
using System;
using Microsoft.Extensions.Logging;

namespace Tests
{
    public class MyLoggerProvider : ILoggerProvider
    {
        public ILogger CreateLogger(string categoryName)
        {
            return new MyLogger();
        }

        public void Dispose()
        { }

        private class MyLogger : ILogger
        {
            public bool IsEnabled(LogLevel logLevel)
            {
                return true;
            }

            public void Log<TState>(
                        LogLevel logLevel, 
                        EventId eventId, 
                        TState state, 
                        Exception exception, 
                        Func<TState, Exception, string> formatter)
            {
                //File.AppendAllText(@"C:\temp\log.txt", formatter(state, exception));
                Console.WriteLine("");
                Console.WriteLine(formatter(state, exception));
            }

            public IDisposable BeginScope<TState>(TState state)
            {
                return null;
            }
        }
    }
}
در اینجا خروجی‌هایی نهایی توسط Console.WriteLine نمایش داده شده‌اند و مناسب برنامه‌های کنسول هستند و یا می‌توان برای مثال توسط File.AppendAllText، اطلاعات رسیده را در یک فایل نیز ذخیره کرد.
در متد Log:
- پارامتر logLevel، سطح اهمیت اطلاعات رسیده را به همراه دارد. برای مثال اطلاعات است یا خطا؟
برای مثال شاید نیاز به ذخیره سازی اطلاعاتی با سطح‌های بحرانی، خطا و یا اخطار در یک بانک اطلاعاتی وجود داشته باشد:
   if (logLevel == LogLevel.Critical || logLevel == LogLevel.Error || logLevel == LogLevel.Warning)
- eventId: نوع رخداد رسیده را مشخص می‌کند.
- state: می‌تواند هر نوع شیءایی، حاوی اطلاعات وضعیت رخداد رسیده باشد.
- exception: بیانگر استثنای احتمالی رخ داده است.
- formatter: کار آن تولید یک رشته‌ی قابل خواندن، توسط اطلاعات حالت و استثناء است.


معرفی Logger تهیه شده به برنامه

پس از تهیه‌ی Logger فوق، جهت معرفی آن به یک برنامه‌ی کنسول، می‌توان به صورت ذیل عمل کرد:
using (var db = new MyContext())
{
   var loggerFactory = (ILoggerFactory)db.GetInfrastructure().GetService(typeof(ILoggerFactory));
   loggerFactory.AddProvider(new MyLoggerProvider());
 }
این ثبت تنها باید یکبار در آغاز برنامه انجام شود و پس از آن تمام وهله‌ی دیگر Context از آن استفاده خواهند کرد.

در برنامه‌های ASP.NET Core، کار معرفی MyLoggerProvider در متد Configure کلاس آغازین برنامه انجام می‌شود:
public void Configure(ILoggerFactory loggerFactory)
{
   loggerFactory.AddProvider(new MyLoggerProvider());


اختصاصی سازی ثبت وقایع رسیده

کلاس MyLoggerProvider، هر نوع اطلاعات داخلی EF Core را نیز لاگ می‌کند. اگر هدف صرفا بررسی خروجی SQL نهایی تولیدی است، می‌توان در متد ذیل:
public ILogger CreateLogger(string categoryName)
بر اساس categoryName رسیده، یا new MyLogger را بازگشت داده و یا یک NullLogger.Instance را که کاری را انجام نمی‌دهد. به این ترتیب می‌توان کار فیلتر کردن اطلاعات رسیده را انجام داد.
برای این منظور، ابتدای Logger تهیه شده چنین شکلی را پیدا می‌کند:
using Microsoft.EntityFrameworkCore.Storage.Internal;
using Microsoft.Extensions.Logging.Abstractions;
using Microsoft.Extensions.Logging;
using System.Linq;
using System;
 
namespace Tests
{
    public class MyLoggerProvider : ILoggerProvider
    {
        private static readonly string[] _categories =
            {
                typeof(RelationalCommandBuilderFactory).FullName,
                typeof(SqlServerConnection).FullName
            };
        public ILogger CreateLogger(string categoryName)
        {
            if (_categories.Contains(categoryName))
            {
                return new MyLogger();
            }
 
            return NullLogger.Instance;
        }
مطالب
ارسال ایمیل در ASP.NET Core
فضای نام System.Net.Mail در NET Core 1.2. که پیاده سازی netstandard2.0 است، ارائه خواهد شد. بنابراین فعلا (در زمان NET Core 1.1.) راه حل توکار و رسمی برای ارسال ایمیل در برنامه‌های مبتنی بر NET Core. وجود ندارد. اما می‌توان کتابخانه‌ی ثالثی را به نام MailKit، به عنوان راه‌حلی که .NET 4.0, .NET 4.5, .NET Core, Xamarin.Android, و Xamarin.iOS را پشتیبانی می‌کند، درنظر گرفت و توانمندی‌ها و پروتکل‌های پشتیبانی شده‌ی توسط آن، از System.Net.Mail توکار نیز بسیار بیشتر است.


افزودن وابستگی‌های MailKit به برنامه

برای شروع به استفاده‌ی از MailKit، می‌توان بسته‌ی نیوگت آن‌را به فایل project.json برنامه معرفی کرد:
{
    "dependencies": {
        "MailKit": "1.10.0"
    }
}


استفاده از MailKit جهت تکمیل وابستگی‌های ASP.NET Core Identity

قسمتی از ASP.NET Core Identity، شامل ارسال ایمیل‌های «ایمیل خود را تائید کنید» است که آن‌را می‌توان توسط MailKit به نحو ذیل تکمیل کرد:
using System.Threading.Tasks;
using ASPNETCoreIdentitySample.Services.Contracts.Identity;
using MailKit.Net.Smtp;
using MailKit.Security;
using MimeKit;
 
namespace ASPNETCoreIdentitySample.Services.Identity
{
    public class AuthMessageSender : IEmailSender, ISmsSender
    {
        public async Task SendEmailAsync(string email, string subject, string message)
        {
            var emailMessage = new MimeMessage();
 
            emailMessage.From.Add(new MailboxAddress("DNT", "do-not-reply@dotnettips.info"));
            emailMessage.To.Add(new MailboxAddress("", email));
            emailMessage.Subject = subject;
            emailMessage.Body = new TextPart(TextFormat.Html)
            {
                Text = message
            };
 
            using (var client = new SmtpClient())
            {
                client.LocalDomain = "dotnettips.info";
                await client.ConnectAsync("smtp.relay.uri", 25, SecureSocketOptions.None).ConfigureAwait(false);
                await client.SendAsync(emailMessage).ConfigureAwait(false);
                await client.DisconnectAsync(true).ConfigureAwait(false);
            }
        }
 
        public Task SendSmsAsync(string number, string message)
        {
            // Plug in your SMS service here to send a text message.
            return Task.FromResult(0);
        }
    }
}
در اینجا MimeMessage بیانگر محتوا و تنظیمات ایمیلی است که قرار است ارسال شود. ابتدا قسمت‌های From و To آن تنظیم می‌شوند تا مشخص باشد که ایمیل ارسالی از کجا ارسال شده و قرار است به چه آدرسی ارسال شود. در ادامه موضوع و عنوان ایمیل تنظیم شده‌است. سپس متن ایمیل، به خاصیت Body شیء MimeMessage انتساب داده خواهد شد. فرمت ایمیل ارسالی را نیز می‌توان در اینجا تنظیم کرد. برای مثال TextFormat.Html جهت ارسال پیام‌هایی حاوی تگ‌های HTML مناسب است و اگر قرار است صرفا متن ارسال شود، می‌توان TextFormat.Plain را انتخاب کرد.
در آخر، این پیام به SmtpClient جهت ارسال نهایی، فرستاده می‌شود. این SmtpClient هرچند هم نام مشابه آن در System.Net.Mail است اما با آن یکی نیست و متعلق است به MailKit. در اینجا ابتدا LocalDomain تنظیم شده‌است. تنظیم این مورد اختیاری بوده و صرفا به SMTP سرور دریافت کننده‌ی ایمیل‌ها، مرتبط است که آیا قید آن‌را اجباری کرده‌است یا خیر. تنظیمات اصلی SMTP Server در متد ConnectAsync ذکر می‌شوند که شامل مقادیر host ،port و پروتکل ارسالی هستند.


ارسال ایمیل به SMTP pickup folder

روشی که تا به اینجا بررسی شد، جهت ارسال ایمیل‌ها به یک SMTP Server واقعی کاربرد دارد. اما در حین توسعه‌ی محلی برنامه می‌توان ایمیل‌ها را در داخل یک پوشه‌ی موقتی ذخیره و آن‌ها را توسط برنامه‌ی Outlook (و یا حتی مرورگر Firefox) بررسی و بازبینی کامل کرد.
در این حالت تنها کاری را که باید انجام داد، جایگزین کردن قسمت ارسال ایمیل واقعی توسط SmtpClient در کدهای فوق، با قطعه کد ذیل است:
using (var stream = new FileStream($@"c:\smtppickup\email-{Guid.NewGuid().ToString("N")}.eml", FileMode.CreateNew))
{
   emailMessage.WriteTo(stream);
}
تولید فایل‌های eml جهت «شبیه سازی ارسال ایمیل در ASP.Net» بسیار مفید هستند.


FAQ و منبع تکمیلی
مطالب
تنظیمات مدت زمان اعتبار کاربران در ASP.NET Identity
نکته: در این مقاله کلمه "بازه زمانی" معادل Interval می‌باشد.
اگر از سیستم احراز هویت از طریق کوکی در asp.net Identity 2.1 استفاده می‌کنید، دو تنظیم برای  بررسی پایان یافتن اعتبار کاربر وجود دارد که در نگاه اول، هیچ تفاوتی باهم نداشته و شبیه به هم به نظر می‌رسند: ValidateInterval و ExpireTimeSpan
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(15),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)),
    },
    SlidingExpiration = false,
    ExpireTimeSpan = TimeSpan.FromMinutes(30)
});

ExpireTimeSpan

CookieAuthenticationOptions.ExpireTimeSpan یک خصیصه است که به شما اجازه می‌دهد تا مدت زمان اعتبار کوکی ساخته شده توسط Identity را مشخص کنید. در مثال بالا، کوکی به مدت 30 دقیقه از زمان ایجاد آن، معتبر است. هنگامی که این 30 دقیقه به پایان برسد، کاربر باید مجددا لاگین کند، چون SlidingExpiration به false تنظیم شده است.
اگر SlidingExpiration مقدار true داشته باشد، کوکی بعد از هر درخواستی که پس از گذشت بیش از نیمی از مدت زمان مشخص شده در ExpireTimeSpan ارسال شود، مجددا ایجاد خواهد شد. برای مثال در اینجا (با توجه قطعه به کد بالا) اگر کاربر login شود و درخواست بعدی را پس از گذشت 16 دقیقه ارسال کند، کوکی به مدت 30 دقیقه دیگر معتبر خواهد شد. اما اگر کاربر پس از لاگین، در خواست بعدی را 31 دقیقه بعد ارسال کند، باید مجددا عمل لاگین را انجام دهد.

بازه زمانی اعتبارسنجی SecurityStampValidator

ValidateInterval از تابع SecurityStampValidator.OnValidateIdentity، فیلد SecurityStamp را بعد از گذشت یک بازه زمانی بررسی می‌کند تا از اعتبار کوکی اطمینان حاصل شود. این همان بررسی منقضی شدن کوکی نیست، اگرچه می‌تواند سبب همان عملکرد و یا لاگ آوت کاربر شود.
Security Stamp هربار که رمز عبور ایجاد یا عوض شود و یا یک لاگین خارجی (External Login) ایجاد یا حذف شود، به روز می‌شود. اگر کاربر رمز عبورش را تغییر دهد این فیلد تغییر خواهد کرد و این تغییر باعث می‌شود که در بررسی مجدد این فیلد پس از مدت زمان مشخص شده در ValidateInterval، کوکی نامعتبر شناخته شود و کاربر را مجبور به لاگین مجدد کند.
نکته: در صورتی که بخواهید به صورت دستی مقدار این فیلد را تغییر دهید می‌توانید از کد زیر استفاده کنید:
UserManager.UpdateSecurityStampAsync(userId);
برای درک بهتر مثال زیر را در نظر بگیرید:
  1. کاربر در مکان A لاگین می‌شود.
  2. همان کاربر مکان خود را تغییر داده و ده دقیقه بعد در مکان B لاگین می‌شود.
  3. کاربر رمزعبورش را در مکان B در دقیقه 12ام تغییر می‌دهد.
  4. کاربر به مکان A برمی گردد و یک درخواست را در دقیقه 20ام ارسال می‌کند.
  5. چون کاربر یک درخواست را بعد از مدت زمان مشخص شده در ValidateInterval (یعنی 15 دقیقه) در مکان A ارسال می‌کند، پس عملیات چک کردن فیلد SecurityStamp انجام می‌شود و از آنجایی که این فیلد به علت تغییر رمز عبور، به روز شده است، بنابراین کاربر لاگ آوت خواهد شد.
دلیل لاگ آوت شدن کاربر در این سناریو، با حالتی که کوکی منقضی می‌شود تفاوت دارد، چون مدت زمان انقضای کوکی یعنی 30 دقیقه (در این مثال) هرگز نمی‌رسد. درعین حال کاربر لاگ آوت می‌شود چون مقدار validateInterval بر روی 15 دقیقه تنظیم شده است.

تفاوت این دو چیست؟
تفاوت دو حالت در نگاه اول خیلی ظریف است اما این تفاوت مزایای بزرگی فراهم می‌کند، مانند لاگ آوت کردن از هر مکان. اما این ویژگی می‌تواند گیج کننده هم باشد از آنجا که الگوی پیش فرض ASP.NET Identity فقط validateInterval را دارد و ExpireTimeSpan به طور صریح ذکر نشده و مقدار پیش فرض آن روی 14 روز تنظیم شده است.
مطالب
استفاده از ماژول Remote
همانطور که در مقاله «آغاز کار با الکترون» گفتیم، فرآیند اصلی، تنها فرآیندی است که توانایی استفاده از گرافیک بومی سیستم عامل را دارد. ولی بسیاری از اوقات نیاز است در سمت renderProcess توانایی انجام این کار‌ها را داشته باشیم. در این مقاله قصد داریم که همان دیالوگ‌های open و save را از طریق Render Process اجرا نماییم.
الکترون برای اینکار از یک ماژول به نام remote استفاده می‌کند که وظیفه آن برقراری ارتباط IPC از Render Process به Main Process است و مواردی را که لازم است، در اختیار شما قرار می‌دهد. در این شیوه لازم نیست شما مرتبا به ارسال پیام بپردازید، بلکه این ارتباطات را ماژول remote فراهم می‌کند. این مورد شبیه به سیستم RMI در جاواست.

برای استفاده از remote در فایل html، کدهای زیر را در تگ اسکریپت اضافه می‌کنیم:
  const remote=require("electron").remote;
    const dialog=remote.dialog;
اینبار هم مانند قسمت قبلی، کدها را به شیوه دیگری انتساب دادیم. قصد ما از تغییر این رویه این است که با انواع حالت‌های انتساب اشیاء، آشنا شویم. بعد از آن توابع زیر را اضافه می‌کنیم:
  function OpenDialog()
    {
      dialog.showOpenDialog({
        title:'باز کردن فایل متنی',
         properties: [ 'openFile']//[ 'openFile', 'openDirectory', 'multiSelections' ]
        ,filters:[
        {name:'فایل‌های نوشتاری' , extensions:['txt','text']},
        {name:'جهت تست' , extensions:['doc','docx']}
         ]
      },
        (filename)=>{
          if(filename===undefined)
             return;
             var content=  fs.readFileSync(String(filename),'utf8');
             document.getElementById("TextFile").value=content;
    });
    }

    function SaveDialog()
    {
      dialog.showSaveDialog({
        title:'باز کردن فایل متنی',
         properties: [ 'openFile']//[ 'openFile', 'openDirectory', 'multiSelections' ]
        ,filters:[
        {name:'فایل‌های نوشتاری' , extensions:['txt','text']}
         ]
      },
        (filename)=>{
          if(filename===undefined)
             return;
             var content=document.getElementById("TextFile").value;
             fs.writeFileSync(String(filename),content,'utf8');
       });
    }
برای استفاده از این توابع، کدهای زیر را نیز به فایل اضافه می‌کنیم تا دکمه‌های open و save به صفحه اضافه شوند:
<button onclick="OpenDialog();" > Open File</button>
<button onclick="SaveDialog();" > Save File</button>
حالا برنامه را اجرا و تست کنید.

عبارت remote شامل متدهای فراوانی است که تعدادی از آن‌ها را بر می‌شماریم:
remote.getCurrentWindow()
شیء BrowserWindow صفحه جاری را باز می‌گرداند.

remote.getCurrentWebContents()
شیء webContents صفحه جاری را باز می‌گرداند.

remote.getGlobal(name)
این متد، دسترسی به شیء global را داراست و یکی از اشیاء ارتباطی بین Main Process و RenderProcess است که می‌تواند هر نوع داده‌ای را جابجا نماید. برای مشاهده بهتر از نحوه کارکرد این متد کد زیر را مشاهده نمایید:
Main Process
global.testData={year:1395};

Render Process
alert(remote.getGlobal("testData").year);
از این پس هر موقع renderProcess به این کد برسد، پیام 1395 را روی صفحه نمایش خواهد داد.

remote.process
شیء، process را از main process دریافت می‌کند و با کد زیر برابر است. ولی مزیت این متد این است که از کش نیز استفاده می‌نماید.
remote.getGlobal('process')

در مورد شیء process باید گفت که شامل خصوصیات و متدهایی در مورد پروسه اصلی اپلیکیشن می‌باشد. این اطلاعات مثل دریافت شماره نسخه الکترون، شماره نسخه کرومیوم، دریافت اطلاعات حافظه در مورد پروسه اپلیکیشن و حتی دریافت اطلاعات حافظه در مورد کل سیستم و ... می‌شود.
مطالب
آشنایی با CLR: قسمت بیست و سوم
در قسمت قبل یاد گرفتیم که اگر یک ناشر، باگی را در یک اسمبلی برطرف کند، باید مدیر سیستم با تغییر فایل پیکربندی، نسخه‌ی جدید اسمبلی را به CLR معرفی کند. ولی اگر ناشر بخواهد این اسمبلی را در اختیار همه‌ی کاربرانش قرار دهد و به همه‌ی کاربران بگوید که باید فایل را تغییر دهید، این روش آن چنان راحت و مناسب نیست. به همین دلیل ناشر باید یک فایل تعیین سیاست داشته باشد، تا این کار راحت صورت بگیرد.
بیایید فرض کنیم که شما، ناشر این اسمبلی جدید با رفع باگ‌های اسمبلی قبلی هستید. موقعیکه شما یک اسمبلی جدید را توزیع می‌کنید، به همراه آن فایل پیکربندی جدیدی را تشکیل داده و ارسال می‌کنید. این فایل پیکربندی جدید دقیقا شبیه به همان فایل پیکربندی است که با آن آشنا شدیم، منتها همنام اسمبلی مورد نظر می‌باشد؛ مثل dotnettips.config برای dotnettips.dll.
<configuration>
     <runtime>
        <assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">
           <dependentAssembly>
                <assemblyIdentity name="SomeClassLibrary"  publicKeyToken="32ab4ba45e0a69a1" culture="neutral"/>
                <bindingRedirect   oldVersion="1.0.0.0" newVersion="2.0.0.0" />
                <codeBase version="2.0.0.0"  href="http://www.Wintellect.com/SomeClassLibrary.dll"/>
             </dependentAssembly>
        </assemblyBinding>
     </runtime>
  </configuration>
در واقع این فایل، تنها یک تعیین سیاست برای این اسمبلی است و تنها از همین المان‌هایی که در بالا می‌بینید، می‌شود استفاده کرد و المان‌هایی غیر از آن‌ها مثل Probing یا publisher policy در اینجا قابل استفاده نیست. خطوط بالا به CLR میگویند، هر موقع به نسخه‌ی یک این اسمبلی ارجاعی را داشتی، از نسخه‌ی 2 آن استفاده کن. برای ساخت فایل بالا می‌توانید از طریق دستور زیر نیز اقدام کنید:
AL.exe /out:Policy.1.0.SomeClassLibrary.dll
          /version:1.0.0.0          
/keyfile:MyCompany.snk         
/linkresource:SomeClassLibrary.config
تشریح دستور بالا به شکل زیر است:

سوئییچ out باعث ساخت فایل PE با نام مشخص شده می‌باشد که تنها شامل یک manifest می‌شود و شامل 5 بخش می‌شود:
  بخش اول شامل عبارت policy است تا بگویید که این اسمبلی شامل یک فایل اطلاعاتی درباره سیاست‌های تعیین شده است.  بخش دوم و سوم مربوط به ورژن اسمبلی است که به ترتیب major و minor آن مشخص می‌شوند و این سیاست‌ها فقط روی این نسخه‌ها اتفاق می‌افتد. ادامه شماره نسخه‌ها چون revision number و ... اهمیتی ندارد و فقط همان دو مقدار اول شرط اصلی هستند. بخش چهارم هم شامل نام اسمبلی مربوطه می‌شود و بخش پنجم هم پسوند اسمبلی است.
سوئیچ version تنها مشخص کننده ورژن فایل پیکربندی است و هیچ ارتباطی با ورژن خود اسمبلی ندارد. این ورژن به این دلیل است که مثلا امروز ناشر دوست دارد که CLR به جای اسمبلی 1.0.0، نسخه‌ی 2.0.0 آن مورد استفاده قرار بگیرد. ولی در آینده تصمیم می‌گیرد از نسخه‌ی 1.0.0 به نسخه‌ی 2.5.0 هدایت شود و در اینجاست که بالاترین نسخه‌ی فایل پیکربندی مورد استفاده قرار می‌گیرد.

سوئیچ KeyFile بدیهی است که فایل سیاست‌های یک اسمبلی با نام قوی نیز باید با جفت کلید عمومی و خصوصی که برای خود اسمبلی مورد نظر استفاده می‌کنید، امضاء شود و بدین ترتیب CLR این اطمینان را کسب کند که واقعا این فایل پیکربندی متعلق به آن است.

سوئیچ linkresource هم میگوید که فایل پیکربندی قرار است جدای از اسمبلی باشد و ناشر باید این فایل را به همراه نسخه‌ی جدید اسمبلی ارسال و توزیع کند. شما نمی‌توانید با استفاده از سوئیچ EmbedResource فایل پیکربندی را داخل اسمبلی قرار دهید؛ چون CLR انتظار دارد این فایل جدا باشد. (در مورد این سوئیچ‌ها در قسمت شانزدهم توضیح داده‌ایم)

در صورتی که اسمبلی جدید ناشر، باگ‌های بیشتری به همراه داشته باشد، به طوریکه ادمین میخواهد فعلا این فایل سیاست‌های تعیین شده جدید را موقتا لغو کند، می‌تواند تگ زیر را در فایل پیکربندی اصلی به کار ببرد:
<publisherPolicy apply="no"/>
نحوه‌ی استفاده از این تگ را در قسمت قبلی دیده بودیم.

پایان فصل سوم و بخش اول
مطالب
روش های مختلف پردازش یک رشته و تبدیل آن به نوع داده تاریخ
DateTime در طبقه بندی سی شارپ، جزء Strcut Type‌ها قرار می‌گیرد . عمدتا از DateTime برای مدیریت تاریخ، زمان و یا تاریخ-زمان استفاده می‌شود. خیلی از اوقات ما نیاز داریم تا رشته‌ای را به نوع تاریخ تبدیل کنیم تا بتوانیم عملیات مختلفی، همچون محاسبه‌ی اختلاف دو تاریخ، روز هفته، روز ماه و غیره را بدست آوریم. در دات نت متد‌های مختلفی وجود دارند که جداسازی تاریخ را از یک رشته برای ما فراهم می‌کنند:
  • Convert.ToDateTime()
  • DateTime.Parse()
  • DateTime.ParseExact()
  • DateTime.TryParse()
  • DateTime.TryParseExact()
در این مطلب این متد‌ها و تفاوت آنها را بررسی می‌کنیم.

تابع ()Convert.ToDateTime 
این تابع یک رشته‌ی با فرمت مشخص را به تاریخ و زمان تبدیل می‌کند. overload‌ها مختلف این تابع را در بخش زیر مشاهده می‌کنید:
• ToDateTime(string value)
Value  : رشته‌ای از تاریخ و زمان است.
 • ToDateTime(string value,IFormatProvider provide)
Value  : رشته‌ای از تاریخ و زمان است.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
CultureInfo culture = new CultureInfo("en-US");    
DateTime tempDate = Convert.ToDateTime("1/1/2010 12:10:15 PM", culture);
در اینجا en-us اطلاعاتی را درباره‌ی فرهنگ کشور آمریکا، ارائه می‌دهد. لیست کامل فرهنگ‌های موجود در net. را می‌توانید در اینجا مشاهده کنید.
اگر رشته‌ی ما تهی (null) نباشد، بصورت درونی متد ()DateTime.Parse فراخوانی و نتیجه‌ی آن بازگردانده می‌شود. اما در صورتیکه رشته‌ی ارسالی ما تهی باشد، مقدار بازگردانده شده مقدار DateTime.MinValue که برابر با 0001/1/1 می‌باشد، بازگردانده می‌شود.
نمونه‌ای از خروجی این تابع با ورودی‌های مختلف :
string datestr = null;
Console.WriteLine(Convert.ToDateTime(datestr));//0001-01-01T00:00:00
datestr = "wrong string";
Console.WriteLine(Convert.ToDateTime(datestr));
//Unhandled Exception: System.FormatException: 
//The string was not recognized as a valid DateTime. 
//There is an unknown word starting at index 0.
datestr = "Tue Dec 30,2015";
Console.WriteLine(Convert.ToDateTime(datestr));
//Unhandled Exception: System.FormatException: 
//String was not recognized as a valid DateTime.

تابع () DateTime.Parse :
این تابع یک رشته‌ی با فرمت مشخص را به تاریخ و زمان تبدیل می‌کند. دو overload این تابع را در زیر می‌بینیم:
• DateTime.Parse(string value)
Value  : رشته‌ای از تاریخ و زمان می‌باشد.
• DateTime.Parse(String value, IFormatProvider provider)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
  • DateTime.Parse(String value, IFormatProvider provider, DateTypeStyles styles)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند 
Styles  : از طریق این پارامتر، تنظیمات قالب بندی رشته‌ی دریافتی برای سفارشی سازی کردن عملیات پردازش تعریف می‌شود. فرض کنید می‌خواهید کلیه‌ی فضاهای خالی (Space) را که قبل و بعد از رشته‌ی تاریخ هستند و نه در داخل رشته‌ی تاریخ، در زمان جداسازی و پردازش در نظر نگیرید. این پارامتر می‌تواند در اینجا به کمک ما بیاید (DateTimeStyles.AllowWhiteSpaces). مشاهده‌ی لیست کامل این خصوصیت از اینجا.
اگر مقدار رشته تهی باشد، استثنای Null نمایش داده خواهد شد (ArgumentNullException ) و اگر فرمت تاریخ ورودی صحیح نباشد، با استثنای فرمت غیرمعتبر روبرو خواهیم شد (FormatException).
string datestr = null;
Console.WriteLine(DateTime.Parse(datestr));
//// Exception: Argument null exception
datestr = "wrong string";            
Console.WriteLine(DateTime.Parse(datestr));
//// Exception: The string was not recognized as a valid DateTime. 
//// There is an unknown word starting at index 0.  
datestr = "Tue Dec 30, 2015";
//Unhandled Exception: System.FormatException: 
//String was not recognized as a valid DateTime. 
Console.WriteLine(DateTime.Parse(datestr));  

تابع ()DateTime.ParsExact
این تابع رشته‌ای شامل تاریخ و زمان را به‌همراه فرهنگ ارسالی، دریافت و آن را تبدیل به نوع DateTime می‌کند. فرمت رشته‌ی ارسالی باید با فرمت استاندارد رشته‌ی تاریخ یکسان باشد. overload‌های مختلف این تابع را در زیر مشاهده می‌کنید:
 • DateTime.ParseExact(string value, string format, IFormatProvider provider)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.

• DateTime.ParseExact(string value, string format, IFormatProvider provider, DateTimeStyles style)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Format : فرمت مورد نظر برای نمایش تاریخ بعد از تبدیل را مشخص می‌کند.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
Styles  : از طریق این پارامتر تنظیمات قالب بندی رشته برای سفارشی کردن عملیات جداسازی و پردازش تعریف می‌شود.
• DateTime.ParseExact(string value, string[] formats, IFormatProvider provider, DateTimeStyles style)
 
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Format : فرمت مورد نظر برای نمایش تاریخ بعد از تبدیل را مشخص می‌کند. تفاوت این حالت با حالت قبل این است که لیستی از فرمت‌ها را قبول می‌کند و حداقل باید یک فرمت با رشته‌ی ارسالی قابل انطباق باشد.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
Styles : از طریق این پارامتر تنظیمات قالب بندی رشته برای سفارشی کردن عملیات جداسازی تعریف می‌شود. 
اگر مقدار رشته تهی باشد، استثنای Null نمایش داده خواهد شد (ArgumentNullException) و اگر فرمت تاریخ ورودی صحیح نباشد، با استثنای فرمت غیرمعتبر روبرو خواهیم شد(FormatException).
فرمت رشته‌ی تاریخ حتما باید با فرمت نوع تاریخ منطبق باشد. به همین منظور حالت‌های مختلفی را در آرایه می‌توان پیش بینی کرد. بطور مثال ممکن است رشته‌ی ما بصورت "2012-2-1" و یا "2012/2/1" باشد. بنابر این فرمت‌های "MM/dd/yyyy" و "MM-dd-yyyy" را از طریق آرایه ارسال می‌کنیم.
برای درک بهتر این موضوع، کد‌های زیر را مشاهده کنید: 
string datestr = null;
CultureInfo provider = CultureInfo.InvariantCulture;
Console.WriteLine(DateTime.ParseExact(datestr, "mm/dd/yyyy", provider));
//Unhandled Exception: System.ArgumentNullException: 
//String reference not set to an instance of a String.
datestr = "wrong date";
Console.WriteLine(DateTime.ParseExact(datestr, "mm/dd/yyyy", provider));
//Unhandled Exception: System.FormatException: 
//String was not recognized as a valid DateTime
datestr = "Tue Dec 30, 2015";
Console.WriteLine(DateTime.ParseExact(datestr, "mm/dd/yyyy", provider));
//Unhandled Exception: System.FormatException: 
//String was not recognized as a valid DateTime.
datestr = "10-22-2015";
Console.WriteLine(DateTime.ParseExact(datestr, "MM-dd-yyyy", provider));
//30/07/1394 12:00:00 ق.ظ
datestr = "10-22-2015";
Console.WriteLine(DateTime.ParseExact(datestr, new string[]
    {"MM-dd-yyyy", "MM/dd/yyyy", "MM.dd.yyyy"}, provider, DateTimeStyles.None));
//30/07/1394 12:00:00 ق.ظ

تابع ()DateTime.TryParse
این تابع رشته‌ای شامل تاریخ و زمان را به‌همراه فرهنگ مشخصی، دریافت و آن را تبدیل به نوع DateTime می‌کند و یک مقدار bool را برای اعلان این موضوع که عملیات تبدیل با موفقیت انجام شده است یا خیر، باز می‌گرداند. فرمت رشته‌ی ارسالی باید با فرمت رشته‌ی تاریخ یکسان باشد. overload‌های مختلف این تابع را در زیر مشاهده می‌کنید:
 
• DateTime.TryParse (String value, out DateTime result)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Result : مقدار تاریخ را بعد از جداسازی در خود ذخیره می‌کند.

• DateTime.TryParse(String value, IFormatProvider provider, DateTimeStyles styles, out DateTime result)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
Styles  : از طریق این پارامتر می‌توانیم قالب پارامتر ارسالی را مشخص کنیم (مثلا نادیده گرفتن فضاهای خالی).
Result : مقدار تاریخ را بعد از جداسازی در خود ذخیره می‌کند.
این تابع همیشه سعی می‌کند رشته‌ی تاریخ را جداسازی کند. در صورت موفقیت در عملیات جداسازی رشته، تاریخ معتبر را بر می‌گرداند و در غیر اینصورت میزان کوچکترین تاریخ یا همان MinValue را که قبلا در همین مطلب اشاره شد، باز می‌گرداند. در صورتی هم که رشته‌، null یا با فرمت رشته‌ای غیر معتبر باشد، همان مقدار DateTime.MinValue بازگردانده می‌شود. همیشه با کنترل مقدار بازگشتی صحت انجام عملیات را می‌توان متوجه شد (true موفقیت در عملیات جداسازی و false عدم موفقیت در عملیات جداسازی).
نکته‌ی مهم عدم پرتاب استثتاء در صورت عدم موفقیت در عملیات جداسازی می‌باشد.
string datestr = null;
            DateTime temp;
            Console.WriteLine(DateTime.TryParse(datestr, out temp));
            Console.WriteLine(temp);
            //False
            //0001 - 01 - 01T00: 00:00

            datestr = "wrong date";
            Console.WriteLine(DateTime.TryParse(datestr, out temp));
            Console.WriteLine(temp);
            //False
            //0001 - 01 - 01T00: 00:00

            datestr = "Tue Dec 30, 2015";
            Console.WriteLine(DateTime.TryParse(datestr, out temp));
            Console.WriteLine(temp);
            //False
            //0001 - 01 - 01T00: 00:00

تابع ()DateTime.TryParseExact
این تابع رشته‌ای شامل تاریخ و زمان را به‌همراه فرهنگ مشخصی دریافت و آن را تبدیل به نوع DateTime می‌کند. رشته‌ی ارسالی باید منطبق با فرمت تاریخ باشد. overload‌های مختلف این تابع را در زیر مشاهده می‌کنید:

• DateTime.ParseExact(string value, string format, IFormatProvider provider, DateTimeStyles style)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Format : فرمت مورد نظر را برای نمایش تاریخ بعد از تبدیل، مشخص می‌کند.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
Styles  : از طریق این پارامتر می‌توانیم قالب پارامتر ارسالی را مشخص کنیم (مثلا نادیده گرفتن فضاهای خالی).

• DateTime.ParseExact(string value, string[] formats, IFormatProvider provider, DateTimeStyles style)
Value : رشته‌ای از تاریخ و زمان می‌باشد.
Format : فرمت مورد نظر برای نمایش تاریخ بعد از تبدیل را مشخص می‌کند و می‌توان آرایه‌ای از فرمت‌ها را در اینجا ارسال کرد.
Provider : اطلاعات فرهنگ مورد نظر را فراهم می‌کند.
Styles  : از طریق این پارامتر می‌توانیم قالب پارامتر ارسالی را مشخص کنیم (مثلا نادیده گرفتن فضاهای خالی).
این تابع را در شرایط زیر، مقدار (MinValue( 1/1/0001 12:00:00 AM را باز می‌گرداند:
• رشته null  باشد.
• رشته خالی باشد "".
• فرمت رشته‌ی تاریخ غلط باشد.
• رشته با فرمت معرفی شده‌ی در provider، انطباق نداشته باشد.
• تنها در صورتی که مقدار انتخابی DateTimeStyle معتبر نباشد، استثنایی رخ می‌دهد.
همچنین همیشه پس از انجام عملیات، مقداری بولین را برای نمایش موفقیت یا عدم موفقیت جدا سازی، باز می‌گرداند.
  string datestr = null;
            DateTime temp;
            CultureInfo provider = CultureInfo.InvariantCulture;
            Console.WriteLine(DateTime.TryParseExact(datestr, "MM/dd/yyyy", provider, DateTimeStyles.None, out temp));
            Console.WriteLine(temp);
            //False
            //1/1/0001 12:00:00 AM

            datestr = "wrong date";
            Console.WriteLine(DateTime.TryParseExact(datestr, "MM/dd/yyyy", provider, DateTimeStyles.None, out temp));
            Console.WriteLine(temp);
            //False
            //1/1/0001 12:00:00 AM

            datestr = "Tue Dec 30, 2015";
            Console.WriteLine(DateTime.TryParseExact(datestr, "MM/dd/yyyy", provider, DateTimeStyles.None, out temp));
            Console.WriteLine(temp);
            //False
            //1/1/0001 12:00:00 AM

            datestr = "10‐22‐2015";
            Console.WriteLine(DateTime.TryParseExact(datestr, "MM/dd/yyyy", provider, DateTimeStyles.None, out temp));
            Console.WriteLine(temp);
            //False
            //1/1/0001 12:00:00 AM

            datestr = "10‐22‐2015";
            Console.WriteLine(DateTime.TryParseExact(
            datestr, "MM‐dd‐yyyy", provider, DateTimeStyles.None, out temp));
            Console.WriteLine(temp);
            //True
            //30/07/1394 12:00:00 ق.ظ

            datestr = "10‐12‐2015";
            Console.WriteLine(DateTime.TryParseExact(datestr, new string[] { "MM/dd/yyyy", "MM‐dd‐yyyy", "MM.dd.yyyy" }, provider, DateTimeStyles.None, out temp));
            Console.WriteLine(temp);
            //True
            //20/07/1394 12:00:00 ق.ظ


آنالیز متد‌های معرفی شده 
نوع DateTime متد‌های مختلفی را برای جداسازی رشته و تبدیل آن به تاریخ دارد. تفاوت‌های این متد‌ها را در بخش زیر بررسی می‌کنیم :

تفاوت Parse و ConvertToDateTime:
این دو متد شبیه به هم هستند، اما چند تفاوت کوچک با هم دارند:
• اگر مقدار رشته‌ی ارسالی null باشد، متد Parse، یک استثناء را ارسال می‌کند و متد ConvertToDateTime مقدار MinValue را باز می‌گرداند.
• در متد Parse می‌توان یک پارامتر اضافه‌تر نیز ارسال کرد که DateTimeStyle نامیده می‌شود. اما متد ConvertToDateTime این قابلیت را ندارد.
• تابع ConvertToDateTime به‌صورت داخلی از متد DateTime.Parse به‌همراه فرهنگ جاری استفاده می‌کند.

تفاوت تابع Parseو ParseExact:
این دو تابع شبیه به هم هستند، اما می‌توان یک پارامتر اضافی format را نیز به تابع ParseExact ارسال کرد. این پارامتر به ما کمک می‌کند تا رشته‌ای را که فرمت متفاوتی از حالت معمولی دارد، به تاریخ تبدیل کنیم. مثلا اگر رشته‌ی "11232015" بدین شکل باشد، فرمت باید به شکل "MMddyyyy" تعریف شود.

تفاوت تابع Parse و TryParse:
این دو متد شبیه به هم هستند، با این تفاوت که تابع TryParse در صورت عدم موفقیت جداسازی رشته، استثنائی را ارسال نمی‌کند و همیشه مقدار MinValue را در صورت عدم موفقیت در تبدیل، باز می‌گرداند.

تفاوت تابع TryParse و TryParseExact:
هر دو تابع شبیه به هم هستند؛ بجز در پارامتر format. تابع TryParseExact از یک پارامتر اضافه‌ی format استفاده می‌کند. ولی تابع TryParse اگر نتواند فرمت مورد نیاز را فراهم کند، مقدار minValue را باز می‌گرداند.
 
مطالب
تزریق وابستگی‌های رایج ASP.NET MVC به برنامه
در پروژه خود می‌توانیم StructureMap را به گونه‌ایی تنظیم کنیم که کار تزریق لایه‌های انتزاعی ASP.NET را نیز انجام دهد؛ مثلاً CurrentHttpContext و یا داده‌های مربوط به مسیریابی و...
به عنوان مثال در برنامه شما ممکن است کدهای زیر چندین و چند بار تکرار شده باشند:
var userId= User.Identity.GetUserId();
var user = _context.Users.Find(userId);

var user = int.Parse(User.Identity.GetUserId());
کدهای فوق به این معنی است که پروژه‌ی شما به صورت کامل به سیستم ASP.NET Identity گره خورده است. خوب، این حالت زمانی پیچیده‌تر خواهد شد که در آینده بخواهید به یک سیستم Identity جدیدتر مهاجرت کنید.
در ادامه نحوه‌ی تزریق وابستگی‌های رایج ASP.NET را بررسی خواهیم کرد. ابتدا یک کلاس رجستری را به صورت زیر ایجاد خواهیم کرد:
public class CommonASPNETRegistry : StructureMap.Configuration.DSL.Registry
{
        public CommonASPNETRegistry()
        {
            For<IIdentity>().Use(() => HttpContext.Current.User.Identity);
            // Other dependencies
        }
}
در کد فوق همانطور که مشخص است، یک کلاس ریجستری ایجاد کرده‌ایم (Registry در واقع یکی از مفاهیم مربوط به استراکچرمپ می‌باشد که امکان ماژولار کردن تنظیمات را درون کلاس‌هایی مجزا، در اختیارمان قرار می‌دهد). درون سازنده‌ی این کلاس گفته‌ایم: زمانیکه درخواستی برای اینترفیس IIdentity داده شد، یک وهله از HttpContext.Current.User.Identity را در اختیار درخواست کننده قرار بده.
لازم به ذکر است می‌توانستیم از وابستگی‌های عنوان شده نیز بدون تزریق کردن آنها درون کنترلرها نیز استفاده کنیم. اما ریجستر کردن آنها این امکان را در اختیارمان قرار می‌دهد تا در هر جایی از برنامه‌مان بتوانیم به آنها دسترسی پیدا کنیم. در ادامه خواهید دید که دسترسی آسان به آنها می‌تواند خیلی مفید واقع شود؛ همچنین امکان تست کردن نیز آسانتر خواهد شد.
قدم بعدی افزودن Registry ایجاد شده به تنظیمات IoC Containerمان است:
public static class SmObjectFactory
{
        private static readonly Lazy<Container> _containerBuilder =
            new Lazy<Container>(defaultContainer, LazyThreadSafetyMode.ExecutionAndPublication);

        public static IContainer Container
        {
            get { return _containerBuilder.Value; }
        }

        private static Container defaultContainer()
        {
            return new Container(ioc =>
            {
                // Other settings
                ioc.AddRegistry(new CommonASPNETRegistry());
                
            });
        }
}
اکنون به سادگی می‌توانیم از وابستگی‌های عنوان شده در برنامه‌مان استفاده کنیم. برای استفاده‌ی از آن، مثال اول را در نظر بگیرید "یافتن کاربر فعلی". همانطور که عنوان شد، استفاده از کدهایی شبیه به حالت زیر جهت یافتن کاربر جاری در برنامه ممکن است چندین بار تکرار شده باشد:
var user = int.Parse(User.Identity.GetUserId());
خوب، برای حل این مشکل اینترفیس زیر را اضافه می‌کنیم:
public interface ICurrentUser
{
        ApplicationUser User { get; }
}
پیاده‌سازی آن نیز به این صورت خواهد بود:
public class CurrentUser : ICurrentUser
{
        private readonly IIdentity _identity;
        private readonly IApplicationUserManager _userManager;
        private ApplicationUser _user;
        public CurrentUser(IIdentity identity, IApplicationUserManager userManager)
        {
            _identity = identity;
            _userManager = userManager;
        }
        public ApplicationUser User
        {
            get { return _user ?? (_user = _userManager.FindById(int.Parse(_identity.GetUserId()))); }
        }
}
درون کلاس فوق به اینترفیس IIdentity جهت ارائه آی‌دی کاربر جاری و اینترفیس IApplicationUserManager جهت یافتن اطلاعات کاربر نیاز خواهیم داشت. همانطور که مشاهده می‌کنید فیلد user_ در صورتیکه از قبل موجود باشد، برگردانده خواهد شد؛ در غیر اینصورت آن را از کانتکست مربوطه واکشی خواهد کرد.
اکنون با استفاده از روش فوق نه تنها درون کنترلرهایمان بلکه در هر جایی از برنامه‌مان می‌توانیم به کاربر جاری دسترسی داشته باشیم. همچنین در آینده نیز به راحتی می‌توانیم از سیستم ASP.NET Identity به هر سیستم دیگری سوئیچ کنیم.
برای استفاده از اینترفیس فوق نیز به این صورت عمل خواهیم کرد:
public class HomeController : BaseController
{
    private readonly ICurrentUser _currentUser;
    public HomeController(ICurrentUser user)
    {
        _user = user;
    }
    public ActionResult Index()
    {
        // user
        var user = _currentUser.User;
        // user id
        var userId = _currentUser.User.Id;
    }
}

مطالب
درخت‌ها و گراف‌ها قسمت پنجم

در ،قسمت قبلی پیاده سازی درخت‌ها را بررسی کردیم و در این قسمت مبحث گراف‌ها را آغاز می‌کنیم .

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

مفهوم پایه‌ای گراف
در این بخش تعدادی از مهمترین خصوصیات گراف‌ها را بررسی می‌کنیم که تعدادی از آن‌ها بسیار شبیه به ساختمان درخت‌هاست، ولی تفاوت‌های زیادی با هم دارند؛ زیرا که درخت، خود نوع متفاوتی از ساختمان گراف‌ها است .

درخت زیر را در نظر بگیرید؛ این درخت هم مانند سایر درخت‌ها با گره‌های شماره دار، نامگذاری شده است که تشخیص آن‌ها را برای ما آسان‌تر می‌سازد. در گراف، به گره‌ها راس یا vertice    هم می‌گویند. هر چند نام گره هم برای آن‌ها به کار برده می‌شود. به فلش‌هایی که به این رئوس اشاره می‌کنند، لبه‌های جهت دار directed edges  گفته می‌شود که در ویکی پدیا و کتب آموزشی فارسی، به آن‌ها یال اطلاق می‌شود . به یال هایی که از هر راس بیرون می‌آیند Predecessor گفته می‌شود که به معنی آغاز کننده است و به راسی که اشاره می‌کند، Successor گویند که به معنی ارث برنده یا جایگزین شناخته می‌شود. در شکل زیر عدد راس 19 آغاز کننده راس 1 است و 1 هم جایگزین یا ارث برنده 19 و اگر با دقت به شکل نگاه کنید می‌بینید که یک راس می‌تواند از چند راس ارث برنده باشد؛ مثل راس 21 .




برای نمایش گراف، ما از عبارت (V,E) استفاده می‌کنیم که V مجموعه‌ای از راس‌ها و E مجموعه‌ای از لبه‌هاست. هر لبه (که با e کوچک نمایش داده می‌شود) و در مجموعه E قرار دارد، پیوند دو راس v و u را نشان می‌دهد یا به عبارتی به صورت ریاضی می‌شود (e=(u,v .
برای اینکه مطالب را بهتر درک کنیم بهتر است که هر راس را یک شهر و هر لبه را یک جاده‌ی یک طرفه برای ارتباط با این راس‌ها فرض کنیم. مثلا اگر یکی از راس‌ها را تهران تصور کنیم و دیگری را کاشان، لبه یا جاده‌ی یک طرفه‌ای که این دو شهر را به هم متصل می‌کند، می‌شود جاده یا لبه‌ی تهران کاشان.

در بعضی مواقع از لبه‌های بدون جهت استفاده می‌شود که این لبه‌ها را لبه‌های دو طرفه می‌گویند؛ مثل جاده‌ی دو طرفه. گاهی هم از دو لبه‌ی جهت دار به جای یک لبه‌ی بدون جهت استفاده می‌کنند که نمونه‌ی آن را در شکل زیر می‌بینید.

دو راسی که به وسیله‌ی یک یال به یکدیگر متصل می‌شوند را همسایه Neighbor می‌نامند. هر یال می‌تواند یک عدد برای خود داشته باشد که به این عدد وزن یال یا لبه می‌گویندWeight (Cost)   و در مثال بالا می‌توان گفت وزن هر یال می‌شود مسافت آن جاده؛ مسافتی که بین دو شهر همسایه باید طی شود. تصویر زیر یک گراف را نشان می‌دهد که وزن یال‌های آن در کنار هر یال نوشته شده است.


مسیر Path در گراف همانند درخت‌ها، طی کردن مسیری است که از یک راس به راس دیگر می‌رسد. در مثال بالا باید گفت که برای رسیدن از شهر مبدا به شهر مقصد، باید از چه شهرهایی عبور کرد. در شکل بالا مسیر 1 - 12 - 19 - 21 - 7 - 21 و 1 مسیر نیستند؛ چرا که راس 21 هیچ لبه‌ی آغاز کننده‌ای ندارد و بیشتر ارث برنده است.

طول Length هر مسیر هم تعداد یال‌هایی است که در طول مسیر قرار دارد یا تعداد راس‌ها منهای یک؛ به این مثال دقت کنید:

مسیر 1 -12-19-21 مسیری است که طول آن سه می‌باشد.

وزن مسیر هم از جمع وزن یال‌هایی که در طول مسیر طی می‌شود به دست می‌آید.

حلقه Loop مسیری است که راس اولیه با راس نهایی یکی باشد. نمونه‌ی آن مسیر 1-12-19-1 می‌باشد. ولی مسیر 1-7-21 حلقه‌ای تشکیل نمی‌دهد.

لبه‌ی حلقه ای Looping Edge لبه‌ای است که مبداء یا آغاز کننده‌ی آن با مقصد یا ارث برنده‌ی آن یکی باشد. یعنی به راسی وصل شود که از همان، آغاز شده است. مثل لبه‌ی متصل به راس 14.


یک کلاس گراف به چه مواردی نیاز دارد:

عملیات ایجاد گراف

افزودن و حذف یک راس یا لبه

بررسی اینکه بین دو راس لبه ای وجود دارد یا خیر

جست و جوی جانشین‌های یک راس


در قسمت آینده کد آن را در سی شارپ پیاده سازی خواهیم کرد.

مطالب
آشنایی با ساختار یک Pull Request خوب
در مطلب «نحوه‌ی مشارکت در پروژه‌های GitHub به کمک Visual Studio» با مفهوم pull request آشنا شدیم. اما ... یک pull request خوب چه خصوصیاتی دارد و فرهنگ ارسال یک PR خوب چیست؟

اخلاق مشارکت در یک پروژه‌ی سورس باز

بعضی از توسعه دهنده‌ها در حین مشارکت در یک پروژه‌ی سورس باز، برای مثال جهت افزودن قابلیتی جدید و یا رفع مشکلی، ابتدا سعی می‌کنند تا کدهای فعلی را برای خودشان «قابل فهم‌تر» کنند. این قابل فهم‌تر کردن پروژه، شامل تغییر نام متغیرها و متدهای فعلی، انتقال کدهای موجود به فایل‌هایی دیگر یا حتی یکی کردن چندین فایل با هم، مرتب سازی متدهای یک کلاس بر اساس حروف الفباء و امثال آن می‌شود.
این کارها را نباید در حین مشارکت و توسعه‌ی پروژه‌های سورس باز دیگران انجام دهید! اگر هدفتان رفع مشکلی است یا افزودن قابلیتی جدید، باید نحوه‌ی کدنویسی فعلی را حفظ کنید. از این جهت که نگهدارنده‌ی اصلی پروژه، پیش از شما این‌کار را شروع کرده‌است و زمانیکه شما به پروژه‌ای دیگر رجوع خواهید کرد، باز نیز باید همین کار را ادامه دهد.
اگر refactoring گسترده‌ی شما به هر نحوی سبب بهبود پروژه‌ی اصلی می‌شود، ابتدا این مورد را با مسئول اصلی پروژه مطرح کنید. اگر او قبول کرد، سپس اقدام به چنین کاری نمائید.


بحث در مورد تغییرات پیش از ارسال PR

قبل از اینکه PR ایی را ارسال کنید، بهتر است یک issue یا ticket جدید را باز کرده و در مورد آن بحث کنید یا توضیح دهید. در این حالت ممکن است توضیحات بهتری را در مورد سازگار سازی تغییرات خود با کدهای فعلی دریافت کنید.


Pull requestها را کوچک نگه‌دارید

برای اینکه شانس قبول شدن PR خود را بالا ببرید، حجم و تمرکز آن‌را کوچک نگه دارید. بسیاری از توسعه دهنده‌های سورس باز اگر با یک PR حجیم روبرو شوند، آن‌را رد می‌کنند چون مشکل اصلی، مدت زمان بالایی است که باید جهت بررسی این PR اختصاص داد. هرچقدر حجم آن بیشتر باشد، زمان بیشتری را خواهد برد.


فقط یک کار را انجام دهید

شبیه به اصل تک مسئولیتی کلاس‌ها، یک PR نیز باید تنها یک کار را انجام دهد و بر روی یک موضوع خاص تمرکز داشته باشد. فرض کنید PR ایی را ارسال کرده‌اید که سه مشکل A، B و C را برطرف می‌کند. از دیدگاه مسئول اصلی پروژه، موارد A و C قابل قبول هستند؛ اما نه مورد C مطرح شده. در این حالت کل PR شما برگشت خواهد خورد. به همین جهت بهتر است بجای یک PR، سه PR مختلف و مجزا را جهت رفع مشکلات A، B و C ارسال کنید.


سازگاری تغییرات ارسالی را بررسی کنید

حداقل کاری را که پیش از ارسال PR باید انجام دهید این است که بررسی کنید آیا این تغییرات قابل Build هستند یا خیر. همچنین اگر پروژه دارای یک سری Unit tests است، حتما آن‌ها را یکبار بررسی کنید تا مطمئن شوید جای دیگری را به هم نریخته‌اید. ضمنا وجود این تست‌ها به صورت ضمنی به این معنا است که تغییرات جدید شما نیز باید به همراه تست‌های مرتبطی باشند تا پذیرفته شوند.


PR ایی را بر روی شاخه‌ی master ارسال نکنید

پس از اینکه یک fork از پروژه‌ای سورس باز را ایجاد کردید و سپس آن‌را clone نمودید تا به صورت Local بتوانید با آن کار کنید، فراموش نکنید که در همینجا باید یک branch و انشعاب جدید را جهت کار بر روی ویژگی مدنظر خود ایجاد کنید (برای مثال feature-X, fix-Y). بسیاری از پروژه‌های سورس باز به هیچ عنوان PRهای کار شده‌ی بر روی انشعاب master را قبول نمی‌کنند.


برای مطالعه بیشتر
Open Source Contribution Etiquette  
ten tips for better Pull Requests 
Getting a Pull Request Accepted 
Optimize Your Pull-request 

مطالب
درخت‌ها و گراف قسمت چهارم
در قسمت قبلی مبحث پیاده سازی ساختمان (ساختار) درخت‌های جستجوی دودویی را به پایان رساندیم. در این قسمت قرار است بر روی درخت متوازن بحث کنیم و آن را پیاده سازی نماییم.

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

در این حالت دیگر درخت مانند یک درخت رفتار نمی‌کند و بیشتر شبیه لیست پیوندی است و عملیات جستجو همینطور کندتر و کندتر می‌شود و دیگر مثل سابق نخواهد بود، پیچیدگی برنامه بیشتر خواهد شد و از (Log(n به n می‌رسد. از آنجا که دوست داریم برای عملیات‌های رایجی چون درج و جستجو و حذف، همین پیچیدگی لگاریتمی را حفظ کنیم، از ساختاری جدیدتر بهره خواهیم برد.

درخت دودویی متوازن:  درختی است که در آن هیچ برگی، عمقش از هیچ برگی بیشتر نیست.

درخت دودویی متوازن کامل: درختی که تفاوتش در تعداد گره‌های چپ یا راست است و حداقل یک فرزند دارند.

درخت دودویی متوازن حتی اگر کامل هم نباشد، در عملیات پایه‌ای چون افزودن، حذف و جستجو در بدترین حالت هم با پیچیدگی لگاریتمی تعداد گام‌ها همراه است. برای اینکه این درخت با به هم ریختگی توازنش روبرو نشود، باید حین انجام عملیات پایه، جایگاه تعداد المان‌های آن بررسی و اصلاح شود که به این عملیات چرخش یا دوران Rotation می‌گویند. انجام این عملیات بستگی دارد که پیاده سازی این درخت به چه شکلی باشد و به چه صورتی پیاده سازی شده باشد. از پیاده سازی‌های این درخت می‌توان به درخت سرخ-سیاه Black Red Tree ، ای وی ال AVL Tree ، اسپلی Splay و ... اشاره کرد.

با توجه به موارد بالا میتوانیم به نتایج زیر برسیم که چرا این درخت در هر حالت، پیچیدگی زمانی خودش را در لگاریتم n حفظ می‌کند:

  • المان‌ها و عناصرش را مرتب شده نگه می‌دارد.
  • خودش را متوازن نگه داشته و اجازه نمی‌دهد عمقش بیشتر از لگاریتم n شود.

نمونه ای از درخت جستجوی دو دویی

همان درخت ولی به صورت متوازن با پیاده سازی AVL


درخت‌های متوازن هم می‌متوانند دو دویی یا باینری باشند و هم غیر باینری non-Binary

درخت‌های دو دویی در انجام عملیات بسیار سریع هستند و در بالا به تعدادی از انواع پیاده سازی‌های آن اشاره کردیم.

درخت‌های غیر باینری نیز مرتب و متوازن بوده، ولی می‌توانند بیش از یک کلید داشته باشند و همچنین بیشتر از دو فرزند. این درخت‌ها نیز عملیات خود را بسیار سریع انجام می‌دهند. از نمونه‌های این درخت می‌توان به B Tree,B+ Tree,Interval Tree اشاره کرد.

از آنجا که پیاده‌سازی این نوع درخت کمی دشوار و پیچیده و طولانی است و همچنین پیاده سازی‌های مختلفی دارد؛ تعدادی از منابع موجود را در زیر معرفی می‌کنیم:

در خود دات نت در فضای نام system.collection.generic کلاس TreeSet یک نوع پیاده سازی از این درخت است که این پیاده سازی از نوع درخت سرخ سیاه می‌باشد و جالب است بدانید، در طی بیست گام می‌تواند در یک میلیون آیتم به جستجو بپردازد ولی خبر بد اینکه استفاده مستقیم از این کلاس ممکن نیست چرا که این کلاس به صورت داخلی internal برای استفاده‌ی خود کتابخانه طراحی شده است ولی خبر خوب اینکه کلاس sortedDictionary از این کلاس بهره برده است و به صورت عمومی در دسترس ما قرار گرفته است. همچنین کلاس SortedSet هم از دات نت 4  نیز در دسترس است.

 

کتابخانه‌های خارجی جهت استفاده در دات نت که به پیاده‌سازی درخت‌های متوازن پرداخته‌اند:

پیاده سازی Splay Tree با سی شارپ 

پیاده سازی AVL به صورت بهینه و آسان برای استفاده

پیاده سازی درخت AVL با کارایی بالا

پیاده سازی درخت AVL به همراه نمایش گرافیکی آن

درخت سرخ-سیاه

کتابخانه ای متن باز برای درخت سرخ-سیاه

درخت متوازن به همراه جست و جو و حذف و پیمایش ها

غیر دودویی‌ها

پیاده سازی B Tree

پیاده سازی Interval Tree 
پیاده سازی Interval Tree در سی ++