نظرات مطالب
Lambda Syntax و کارآیی
تعریف متدهای بی نام (چه بصورت delegate{} و چه بصورت Lambda) مستلزم  ایجاد یک کلاس اضافه بهمراه تشکیل متد و متغیر‌های لازمه توسط کامپایلر هستند اما در مورد متدهای بانام (صریح) اغلب نیازی به ایجاد کلاسی مجزا نیست و توسط برنامه نویس معمولا در همان کلاس نوشته میشوند.
مسلماْ کامپایلر خیلی سریع‌تر از برنامه نویس‌ها میتوانند این موارد رو ایجاد کند.
پس قبل از اجرای برنامه متدها و هندلر‌ها وجود دارند و نمیتواند از این بابت در سرعت اجرا تاثیری داشته باشند. بنظر من تنها دلیل کندتر بودن (خیلی کم) متدهای بی نام در زمان اجرا این است که چون متدهای بی نام در کلاسی مجزا تعریف شده است نیاز به نمونه سازی (newobj ) دارند در حالی که متدهای بانام از این مورد مبرا هستند.
با این توصیف و با چشم پوشی نسبت به زمان اندکی که کامپایلر صرف متدهای بی نام میکند استفاده از متدهای بی نام بصرفه‌تر هستند و برنامه رو هم زیباتر و خواناتر میکنند.
مطالب
بازسازی کد: جایگزینی متغیر موقتی با پرس و جو (Replace temp with query)
زمانیکه متغیری برای نگهداری موقت نتیجه‌ی یک expression تعریف شده‌است، بهتر است expression مربوطه به متدی انتقال پیدا کرده و تمامی استفاده‌ها از متغیر موقتی با فراخوانی متد ایجاد شده جایگزین شوند. 
مشکل اصلی در ارتباط با متغیرهای محلی، ترویج ایجاد متدهای بلند توسط آنها است. مشخص است که این متغیرها در بدنه متد خود قابل استفاده هستند و تنها راه اشتراک مقدار آنها طولانی‌تر شدن متد است. اما زمانیکه این متغیرها با متد پرس و جوی مرتبط با آن جایگزین شوند، این مقدار توسط دیگر متدهای کلاس قابل دسترسی خواهد بود. این کار ایجاد متدهایی با اندازه مناسب را آسان‌تر می‌کند. 
این بازسازی کد بیشتر اوقات در کنار بازسازی استخراج متد استفاده می‌شود؛ به طوری که قبل از انجام استخراج متد، ابتدا تکلیف متغیرهای محلی مشخص می‌شود. یک نوع از متغیرهای محلی که نیاز به بررسی و تغییر خواهند داشت این دسته از متغیرهای محلی هستند.

مراحل انجام این بازسازی کد  

  • متغیر موقتی ای را که تنها یک بار مقداردهی شده است، پیدا کنید (در صورتیکه متغیر چندین بار مقداردهی شده باشد، باید بازسازی جداسازی متغیرهای موقتی را اعمال نمایید).
  • متغیر را به readonly تغییر دهید.
  • کد را کامپایل نمایید تا اطمینان حاصل کنید متغیر تنها یک بار مقداردهی شده‌است.
  • Expression سمت راست مقداردهی متغیر را به متد، منتقل نمایید. دو نکته در مورد متد تازه ایجاد شده:  
    • این متد را به صورت private تعریف نمایید. در صورتی در آینده مصرف دیگری برای آن پیدا کردید می‌توانید سطح دسترسی آن‌را آزادتر نمایید. 
    • اطمینان حاصل نمایید متد مورد نظر، شیء یا خصوصیتی را ویرایش نمی‌کند. در صورتیکه این کار را انجام می‌دهد، باید بخش ویرایش آن را از بخش پرس و جوی آن جدا نمایید (Separate query from modifier). 
  • کد را مجددا کامپایل نمایید.  
  • تمامی استفاده‌های متغیر را با فراخوانی متد ایجاد شده، تغییر دهید. 
مثال: تکه کد زیر را در نظر بگیرید  
public class OrderItem 
{ 
    private double quantity; 
    private double itemPrice; 
    public double CalculateTotal() 
    { 
        double basePrice = quantity * itemPrice; 

        if (basePrice > 1000) 
        { 
            return basePrice * 0.95; 
        } 
        else 
        { 
            return basePrice * 0.98; 
        } 
    } 
}

در این کلاس متدی برای محاسبه قیمت نهایی یک آیتم سفارش ایجاد شده‌است. با دقت در کد می‌توان تشخیص داد که متغیر basePrice یک متغیر محلی موقتی است. این تکه کد را می‌توان به صورت زیر بازسازی کرد   
public class OrderItem 
{ 
    private double quantity; 
    private double itemPrice; 
    public double CalculateTotal() 
    { 
        if (BasePrice() > 1000) 
        { 
            return BasePrice() * 0.95; 
        } 
        else 
        { 
            return BasePrice() * 0.98; 
        } 
    } 
    private double BasePrice() 
    { 
        return quantity * itemPrice; 
    } 
}
کد حاصل از بازسازی انجام شده، شامل یک متد به نام BasePrice است که مقدار قیمت پایه را بر می‌گرداند. این متد را به صورت private تعریف کردیم. اما می‌توان در صورت نیاز به override کردن آن در کلاس‌های مشتق شده‌ی احتمالی، سطح دستری آن را به مقدار مناسبی تغییر داد.  به نظر شما چه بازسازی کد دیگری را می‌توان بر روی متد CalculateTotal انجام داد؟ 

آیا این بازسازی کد تاثیر منفی بر کارآیی خواهد داشت؟ 

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

اگر امروز با استفاده از دستور dotnet new console یک برنامه‌ی کنسول را شروع کنیم، به یک فایل program.cs تقریبا خالی و یک فایل csproj. مرتبط می‌رسیم و ... همین! اما نیازهای واقعی ما در یک برنامه‌ی کنسول، شامل این موارد هستند:
- نیاز به انجام تزریق وابستگی‌ها
- نیاز به دسترسی به فایل‌های کانفیگ؛ شبیه به برنامه‌های وب
- نیاز به کار با EF و مدیریت صحیح طول عمر Context آن
- مشخص بودن شماره نگارش دات نت و همچنین ابزارهای EF استفاده شده
- غنی سازی کامپایلر با یک سری آنالایزر و تنظیمات مخصوص آن جهت اعمال سخت گیری‌های بیشتر!
- استفاده از مدیریت مرکزی بسته‌های نیوگت برای پروژه‌های مختلف در Solution
- نیاز به کار با HttpClient؛ آن هم به نحو صحیحی
- نیاز به دسترسی به سوئیچ‌ها و پارامترهای ارسالی به برنامه‌ی کنسول از طریق خط فرمان
- نیاز به دسترسی به سیستم Logging؛ شبیه به برنامه‌های وب
- امکان انجام آزمون‌های واحد و یکپارچگی درون حافظه‌ای

تمام این موارد به صورت از پیش تنظیم شده، در قالب ارائه شده‌ی توسط این پروژه موجود هستند.
برای نصب آن‌، ابتدا مخزن کد فوق را clone کرده و سپس فایل register_template.cmd آن‌را اجرا کنید. پس از آن دستور dotnet new dntconsole، جهت ایجاد پروژه‌های جدید مبتنی بر این قالب، در دسترس خواهد بود.

تهیه قالبی بهتر برای برنامه‌ها‌ی کنسول دات نتی
مطالب
اتصال به سرویس WCF در NETCF 3.5

با توجه به پیشرفتی که در حوزه اپلیکشن‌های وابسته به فریمورک دات نت بوجود آمده، ولی شاید حرکت عملی بزرگی از سمت تولیدکندگان در حوزه کامپکت صورت نگرفته و همچنان شاهد فرمانروایی سیستم عاملهایی چون Windows Compact 6.0 با استفاده از دات نت فریمورک‌هایی نهایت با نسخه 3.5 هستیم. البته میتوان ارزان‌تر بودن در خارج و مسئله تحریم در داخل را هم در نظر داشت و نمونه عینی این مورد را میتوان در دستگاههای وارد شده در حوزه Compact،  دید. البته شرکت‌های تولید کننده خارجی که عمدتا در کشورهای جنوب شرق و شرق آسیا هستند، جزو شرکت‌های مطرح در این زمینه هستند که بازارهای خوبی هم در کشورهای توسعه یافته‌ای چون آمریکا پیدا کرده‌اند.

در این بین برای عقب نماندن از تکنولوژی‌های جدید بوجود آمده در حوزه دات نت مانند WCF این مقاله کمکی هر چند کوچک برای استفاده از این قابلیت موثر در فریمورک کامپکت می‌تواند باشد.

پیشنیاز‌های لازم:

- Microsoft Visual Studio 2008 + Service Pack 1

- نصب Power Toys for .NET Compact Framework 3.5


پیاده سازی سرویس (بر روی سیستمی غیر از ویندوز کامپکت):  

در ویژوال استودیو 2008 سرویس پک یک، پروژه ای از نوعclass library  را  ایجاد کرده و سرویسی تستی را برای استفاده ایجاد میکنیم:  
[ServiceContract(Namespace = "http://samples.wcf.cfnet.sample")]
    public interface ICalculator
    {
        [OperationContract]
        int Add(int a, int b);
    }

و پیاده سازی آن:

public class CalculatorService : ICalculator
    {
        public static int count;

        public int Add(int a, int b)
        {
            count++;
            Console.WriteLine(string.Format("{3}\tReceived 'Add({0}, {1})' returning {2}", a, b, a + b, count));
            return a + b;
        }

سرور سرویس:

برای هاست این سرویس از یک برنامه‌ی کنسول که در سلوشن ایجاد میکنیم استفاده میکنیم. البته امکان‌های دیگر برای هاست سرویس در هر پروسس دات نتی را میتوان یاد آور شد. برای هاست کردن شروع یک سرویس WCF باید یک IP درون شبکه را که قابل دسترسی از سمت ویندوز کامپکت بوده و به سیستم انتساب داده شده، دریافت و استفاده کنیم:  

var addressList = Dns.GetHostEntry(Dns.GetHostName());

string hostIP = addressList.AddressList.Single(x=>x.ToString().StartsWith("192.168.10.")).ToString();
Uri address = new Uri(string.Format("http://{0}:8000/Calculator", hostIP));

در قطعه بالا IP در رنج مناسب و قابل دسترسی انتخاب میشود چون ویندوز کامپکت (فارق از اینکه در شبیه ساز باشد یا واقعی) از طریق شبکه به سرور دسترسی پیدا میکند باید IP مناسب انتساب داده شده انتخاب شود.

ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService),address);
serviceHost.AddServiceEndpoint(typeof(ICalculator), new BasicHttpBinding(), "Calculator");

در ادامه یک سرویس هاست را new کرده و سرویس و بایندینگ را به آن در سازنده پاس میدهیم.

var serviceMetadataBehavior =
new ServiceMetadataBehavior { HttpGetEnabled = true };
serviceHost.Description.Behaviors.Add(serviceMetadataBehavior);

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

serviceHost.Open();
Console.WriteLine("CalculatorService is running at " + address.ToString());
Console.WriteLine("Press <ENTER> to terminate");
Console.ReadLine();
serviceHost.Close();

و در نهایت، شروع سرویس با فرمان Open و خاتمه آن با فرمان Close .


کلاینت سرویس (در داخل ویندوز کامپکت):

همراه با ارائه دات نت فریمورک 3.5 برای کار با سرویس WCF که از آن یک نسخه‌ی ارائه شده برای کامپکت نیز تهیه شده‌است، ابزاری مانند netcfSvcUtil.exe که در SDK نسخه‌ی کامپکت موجود است و کاربرد هندل کردن بعضی از موارد مانند تولید کد پروکسی‌های سمت کلاینت را دارد که در ادامه طرز استفاده از آن را بررسی خواهیم کرد. بعد از اجرای سرویس WCF با رفتار HttpGetEnabled = true برای بررسی سریع کارکرد صحیح سرویس، آدرس آن را در مرورگر میبینیم. تصویر زیر نتیجه‌ی آن در مرورگر است:



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

(Windows Drive)\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\bin
(Windows Drive)\Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\bin

و فرمان زیر را اجرا میکنیم:

netcfSvcUtil.exe /language:C# /target:code /directory:D:\GeneratedCode\CF\CaculatorService http://192.168.10.189:8000/BooksService.svc?wsdl

البته ذکر IP شبکه در اینجا الزامی نیست؛ زیرا در صورت استفاده از آدرسهای داخلی سیستم، این فرمان به مشکلی بر نخواهد خورد. در این فرمان تولید کد با زبان c# و تولید کد که بصورت پیش فرض نیز وجود دارد و محل ذخیره سازی کدهای تولیدی را مشخص میکنیم و بعد از اجرای این فرمان، باید دو فایل در مسیر اشاره شده در فرمان تولید شود که اساس کار ما در سمت کلاینت خواهد بود:


کلاینت سرویس نیز با استفاده کدهای تولیدی بصورت زیر آماده سازی و اجرا میشود:

var addressList = Dns.GetHostEntry(Dns.GetHostName());
var localAddress = addressList.AddressList.Single(x => x.ToString().StartsWith("192.168.10.")).ToString();

دوباره IP مناسب در شبکه جاری استخراج میشود. بایندیگ مورد نیاز برای ارتباط با سرور ساخته میشود:

var binding = CalculatorClient.CreateDefaultBinding();

نکته‌ای که دراین قسمت باید مدنظر قرار گیرد این است که در زمان تولید کدها اگر از localhost یا 127.0.0.1 و یا آدرسهای دیگر انتساب داده شده به سرور استفاده کرده باشید در متد CreateDefaultBinding از همان آدرس استفاده میشود و برای اصلاح آن بصورت زیر عمل میکنیم:

string remoteAddress = CalculatorClient.EndpointAddress.Uri.ToString();
remoteAddress = remoteAddress.Replace("localhost", serviceAddress.Text);

یک EndpointAddress با استفاده از این آدرس ساخته و به‌همراه بایندینگ، یک آبجکت از جنس CalculatorClient که در کدهای تولیدی داریم میسازیم:

CalculatorClient _client = new CalculatorClient(binding, endpoint);

برای تست نیز تنها متد این سرویس را با یک جفت عدد، صدا میزنیم:

var result = _client.Add(82, 18).ToString(CultureInfo.InvariantCulture);

به این ترتیب خروجی مورد نظر زیر را در کنسول سرویس مشاهده خواهیم کرد:


 
نظرات مطالب
تفاوت انواع var و dynamic
بله اینها صحیح، ولی statically typed dynamic عبارتی است که Anders Hejlsberg هنگام صحبت در مورد آینده C# در  PDC09 به کاربرد.
The Future of C#
 
The dynamic keyword acts as a static type declaration in the C# type system. This way C# got the dynamic features and at the same time remained a statically typed language. 

http://msdn.microsoft.com/en-us/magazine/gg598922.aspx 
در واقع کلمه کلیدی dynamic به کامپایلر می‌فهماند که compile-time checking  را غیر فعال کن! تا در زمان اجرا به نوع متغییر رسیدگی شود.

شاید اگر بگوییم dynamic نوعی static است که مزایای انواع dynamic را در بر می‌گیرد بهتر باشد.

خواندن این مقاله هم خالی از لطف نیست:
نظرات مطالب
ASP.NET MVC #16
نه. برای استفاده در سایت‌های غیرتجاری، رایگان است. من از همان نسخه‌ای که در سایت قرار داده برای دانلود، استفاده می‌کنم. نسخه کاملی است و قابلیت آپلود هم دارد. البته مثال‌های آن با PHP است که تبدیل آن به دات نت کار ساده‌ای است. به علاوه نسخه رایگان آن پشتیبانی ندارد که مهم نیست.
ضمن اینکه درخواست من این است: لطفا بحث جاری مقابله با خطاها را تغییر جهت ندهید. با تشکر.
مطالب
Owin چیست ؟ قسمت اول
مطمئنا اکثر شما برنامه نویسان با معماری IIS و ASP.NET کمابیش آشنایی دارید
Request از سمت کلاینت به IIS ارسال می‌شود، و عموما بسته به نوع درخواست کلاینت یا به یک Static File مپ می‌شود( مثلا به یک عکس )، و یا به یک ISAPI
ISAPI کدی است که عموما با ++C نوشته می‌شود، و برای درخواست آمده از سمت کلاینت کاری را انجام می‌دهد
یکی از این ISAPI‌ها برای ASP.NET است، که درخواست کلاینت را به یک کد مبتنی بر NET. مپ می‌کند ( به همین علت به آن ASP.NET می‌گویند )
نکته ای که در خطوط فوق به وضوح دیده می‌شود، وابستگی شدید ASP.NET به IIS است
بدیهتا کدی که بر روی بستر ASP.NET نوشته می‌شود نیز وابستگی فوق العاده ای به IIS دارد، که یکی از بدترین نوع این وابستگی‌ها در ASP.NET Web Forms دیده می‌شود.
خب، این مسئله چه مشکلاتی را ایجاد می‌کند ؟
مشکل اول که شاید کمتر به چشم بیاید، بحث کندی اجرای بار اول برنامه‌‌های ASP.NET است.
اما مشکل دوم عدم توانایی در نوشتن کد برنامه، بدون وابستگی به وب سرور (در اینجا IIS ) است، که این مشکل دوم روز به روز در حال جدی‌تر شدن است.
این مشکل دوم را برنامه نویسان جاوا سالهاست که با آن درگیرند، نکته این است که بین دو وب سرور در نحوه پردازش یک درخواست کلاینت تفاوت هایی وجود دارد، که بالطبع این تفاوت‌ها در نحوه‌ی اجرای کد بالاخره خودش را جاهایی نشان می‌دهد، این که بگوییم رفتار وب سرورها نباید متفاوت باشد کمی مسخره است، زیرا تفاوت آنها  با یکدیگر باعث شده که سرعت یکسان و امکانات یکسانی نداشته باشند و هر کدام برای یک سناریوی خاص مناسب‌تر باشند
این مسئله برای ما نیز روز به روز دارای اهمیت بیشتری می‌شود، دیگر این که Web Server ما فقط IIS صرف باشد، سناریوی متداول در پروژه‌های Enterprise نیست
در چه جاهایی می‌توان یک برنامه را هاست کرد ؟
IIS به همراه ASP.NET
IIS بدون ASP.NET ( می‌خواهیم برنامه بر روی IIS هاست شود، ولی کاری با ASP.NET نداریم )
CLR AppDomains
و وب سرورهای لینوکسی در صورت اجرای برنامه بر روی Mono
و ...
هم اکنون به میزان زیادی مشکل شفاف شده است، مطابق با معماری فعلی داریم
 Request >> IIS >>  aspnet_isapi.dll >>  System.Web.dll >> Your codes
مشکل دیگری که وجود دارد این است که اگر تیمی بخواهد فریم ورکی برای برنامه نویسان نهایی فراهم کند، باید آنرا بر روی اکثر گزینه‌های هاست موجود سازگار  کنید، برای   مثال مشاهده می‌کنید که ASP.NET Signal R را هم می‌توان بر روی IIS و ASP.NET هاست کرد و هم بر روی یک App Domain کاملا معمولی  و علاوه بر این که تیم   SignalR باید این هزینه مضاعف را پرداخت کند، خروجی برای ما نیز چندان خوشایند نیست، برای مثال اجرای همزمان ASP.NET SignalR و ASP.NET  Web API اگر چه که بر  روی هاستی به غیر از ASP.NET نیز امکان پذیر است، اما متاسفانه به عنوان دو بازیگر جدا از هم کار می‌کنند و عملا تعاملی با یکدیگر ندارند، مگر این  که بر روی ASP.NET  هاست شوند، و یا بسیاری از امکانات Routing موجود در WCF بر روی بستری غیر از ASP.NET کار نمی‌کند.
بدیهی است که این بازار پر آشوب به نفع هیچ کس نیست.
و اما راه حل چیست ؟
تعدادی از برنامه نویسان حرفه ای NET. دور یکدیگر جمع شدند و طی بررسی هایشان به این نتیجه رسیدند که هاست‌های مختلف نقاط اشتراک بسیار زیادی دارند و  تفاوت‌ها نباید باعث این میزان مشکل شود.
پس استانداری را طراحی کردند با نام OWIN  یا Open Web Interface for .NET
این استاندارد به صورت کاملا ریز به طراحی هر چیزی را که شما به آن فکر کنید پرداخته است، Request, Cookie, Response, Web Sokcet و ...
اما همانطور که از نامش مشخص است این یک استاندارد است و پیاده سازی ندارد، و هر هاستی باید یک بار این استاندارد را بر روی خود پیاده سازی کند
خبر خوش این است که تا این لحظه اکثر هاست‌های مهم این استاندارد را پیاده سازی کرده اند و یا در دست پیاده سازی دارند
پروژه Helios برای IIS
پروژه Katana  برای IIS به در کنار و سازگار با ASP.NET برای پروژه هایی که تا این لحظه از امکانات سطح پایین ASP.NET استفاده زیادی کرده اند و فرصت تغییر ساختاری ندارند
پروژه هایی برای App Domains و ...
مرحله‌ی بعدی این است که فریم ورک‌ها خوشان را با Owin سازگار کنند
معروف‌ترین فریم ورک هایی که تا این لحظه اقدام به انجام این کار کرده اند، عبارتند از:
ASP.NET Web API
ASP.NET MVC
ASP.NET Identity
ASP.NET Signal R ( در حال حاضر Signal R فقط بر روی Owin قابلیت استفاده دارد )
بدیهی است که زمانی که پروژه ASP.NET Web API بر روی استاندارد OWIN نوشته می‌شود، دیگر نیازی به تحمل هزینه مضاعف برای سازگاری خود با انواع هاست ها ندارد و این مسئله توسط Katana، Helios  و ... انجام شده است، که بالطبع بزرگترین نفع آن برای ما جلوگیری از چند باره کاری توسط تیم Web API و ... است که بالطبع در  زمان کمتر امکانات بیشتری را به ما ارائه می‌دهند.
البته واضح است فریم ورک هایی که با کلاینت و درخواست‌ها کاری ندارند، با این مقولات کاری ندارند، پس Entity Framework و ... از این داستان مستثنا هستند.
و علاوه بر این فریم ورک هایی با طراحی اشتباه و قدیمی مانند ASP.NET Web Forms به صورت کلی قابلیت سازگار شدن با این استاندارد را ندارند، زیرا کاملا به ASP.NET  وابسته هستند
و در نهایت در مرحله‌ی بعدی لازم است شما نیز از فریم ورک هایی استفاده کنید که مبتنی بر OWIN هستند، یعنی برای مثال پروژه بعدی تان را مبتنی بر ASP.NET MVC و ASP.NET Web API و ASP.NET Identity پیاده سازی کنید، در این صورت شما می‌توانید برنامه ای بنویسید که به Web Server هیچ گونه وابستگی ندارد.
به این صورت کد زدن چند مزیت بزرگ دیگر هم دارد که از کم اهمیت‌ترین آنها شروع می‌کنیم:
1- سرعت بسیار بالاتر برنامه در هاست‌های غیر ASP.NET ای، مانند زمانی که شما از IIS به صورت مستقیم و بدون وابستگی به System.Web.dll استفاده می‌کنید.
توجه کنید که حتی در این حالت هم می‌توانید از ASP.NET Web API و Signal R و Identity استفاده کنید و تا 25% سرعت بیشتری داشته باشید ( بسته به سناریو ) 
2- قابلیت توسعه آسانتر و با قابلیت نگهداری بالاتر پروژه‌های Enterprise، برای مثال در یکی از پروژه‌ها من مجبور بودم از ASP.NET Web API به صورتی استفاده کنم  که هم توسط کلاینت JavaScript ای استفاده شود، و هم توسط کدهای Controller‌های MVC ( بدون استفاده مستقیم از کد سرویس با رفرنس زدن به سرویس‌ها البته )  که خوشبختانه OWIN به خوبی از پس این کار بر آمد، و عملا یک سرویس Web API را هم بر روی IIS هاست کردم و هم داخل یک AppDomain
3- در چند سال آینده که اکثریت مطلق سایت‌ها از این روش استفاده کنند ( شما چه بدانید و چه ندانید اگر در برنامه خودتان از Signal R نسخه 2 دارید استفاده می‌کنید،حتما از OWIN استفاده کرده اید )، مایکروسافت می‌تواند دست به تغییرات اساسی‌تری بزند، برای مثال معماری جدیدی از IIS ارائه دهد که مشکلات ساختاری فراوان  فعلی  IIS  را   که  از حوصله توضیح این مقاله خارج است را نداشته باشد، و فقط یک پیاده سازی OWIN جدید بر روی آن ارائه دهد و برنامه‌های ما بدون تغییر بر روی آن نیز کار  کنند، و یا  این که بتواند تعدادی از فریم ورک‌های با طراحی قدیمی را راحت‌تر از دور خارج کند، مانند Web Forms
نکته پایانی، اگر هم اکنون پروژه ای دارید که در داخل آن از ASP.NET استفاده شده، و برای مثال تعدای فرم ASP.NET Web Forms نیز دارد، نگران نباشید، کماکان می‌توانید از Owin برای سایر قسمت‌ها مانند Web API استفاده کنید، البته در این حالت تاثیری در بهبود سرعت اجرای برنامه مشاهده نخواهید کرد، اما برای مهاجرت و اعمال تغییرات این آسانترین روش ممکن است
در قسمت بعدی، مثالی را شروع می‌کنیم مبتنی بر ASP.NET Web API، ASP.NET Identity و Helios
مطالب
پیاده سازی برنامه‌های چند مستاجری در ASP.NET Core

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

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

 در معماری Multi-Tenancy، چندین کاربر می‌توانند از یک نمونه (Single Instance) از اپلیکیشن نرم‌افزاری استفاده کنند. یعنی این نمونه روی سرور اجرا می‌شود و به چندین کاربر سرویس می‌دهد. هر کاربر را یک Tenant می‌نامیم. می‌توان به Tenantها امکان تغییر و شخصی‌سازی بخشی از اپلیکیشن را داد؛ مثلا امکان تغییر رنگ رابط کاربری و یا قوانین کسب‌وکار، اما آنها نمی‌توانند کدهای اپلیکیشن را شخصی‌سازی کنند.

بدون داشتن دانش کافی، پیاده سازی معماری multi tenant می‌تواند تبدیل یه یک چالش بزرگ شود. مخصوصا در نسخه‌ی قبلی ASP.NET که یکپارچه نبودن فریم ورک‌های مختلف می‌توانست باعث ایجاد چندین پیاده سازی مختلف در برنامه شود. موضوع وقتی پیچیده‌تر می‌شد که شما قصد داشتید در یک برنامه چندین فریم ورک مختلف مثل SignalR, MVC, Web API را مورد استفاده قرار دهید.

خوشبختانه اوضاع با وجود OWIN بهتر شده و ما در این مطلب قصد استفاده از یک تولکیت را به نام SaasKit، برای پیاده سازی این معماری در ASP.NET Core داریم. هدف از این toolkit، ساده‌تر کردن هر چه بیشتر ساخت برنامه‌های SaaS (Software as a Service) هست. با استفاده از OWIN ما قادریم که بدون در نظر گرفتن فریم ورک مورد استفاده، رفتار مورد نظر خودمان را مستقیما در یک چرخه درخواست HTTP پیاده سازی کنیم و البته به لطف طراحی خاص ASP.NET Core 1.0 و استفاده از میان افزار‌هایی مشابه OWIN در برنامه، کار ما با SaasKit باز هم راحت‌تر خواهد بود.

شروع کار 

یک پروژه ASP.NET Core جدید را ایجاد کنید و سپس ارجاعی را به فضای نام SaasKit.Multitenancy  (موجود در Nuget) بدهید. 
PM> Install-Package SaasKit.Multitenancy
بعد از اینکار ما باید به SaasKit اطلاع دهیم که چطور مستاجر‌های ما را شناسایی کند.

شناسایی مستاجر (tenant) 

اولین جنبه در معماری multi-tenant، شناسایی مستاجر بر اساس اطلاعات درخواست جاری می‌باشد که می‌تواند از hostname ، کاربر جاری یا یک HTTP header باشد.
ابتدا به تعریف کلاس مستاجر می‌پردازیم: 
    public class AppTenant
    {
        public string Name { get; set; }
        public string[] Hostnames { get; set; }
    }
سپس از طریق پیاده سازی اینترفیس ITenantResolver  و نوشتن یک tenant resolver به SaasKit اطلاع می‌دهیم که چطور مستاجر جاری را بر اساس اطلاعات درخواست جاری شناسایی کند و در صورتیکه موفق به شناسایی شود، یک وهله از نوع <TenantContext<TTenant را بازگشت خواهد داد. 
    public class AppTenantResolver : ITenantResolver<AppTenant>
    {
        IEnumerable<AppTenant> tenants = new List<AppTenant>(new[]
        {
            new AppTenant {
                Name = "Tenant 1",
                Hostnames = new[] { "localhost:6000", "localhost:6001" }
            },
            new AppTenant {
                Name = "Tenant 2",
                Hostnames = new[] { "localhost:6002" }
            }
        });
        public async Task<TenantContext<AppTenant>> ResolveAsync(HttpContext context)
        {
            TenantContext<AppTenant> tenantContext = null;
            var tenant = tenants.FirstOrDefault(t =>
                t.Hostnames.Any(h => h.Equals(context.Request.Host.Value.ToLower())));
            if (tenant != null)
            {
                tenantContext = new TenantContext<AppTenant>(tenant);
            }
            return tenantContext;
        }
    }
در نظر داشته باشید که اینجا ما اطلاعات مستاجر را از روی hostname استخراج کردیم؛ اما از آنجا که شما به شیء HttpContext دسترسی کاملی دارید، می‌توانید از هر چیزی که مایل باشید استفاده کنید؛ مثل URL، اطلاعات کاربر، هدر‌های HTTP و غیره. در اینجا فعلا مشخصات مستاجر‌های خودمان را در کد نوشتیم. اما شما می‌توانید در برنامه خودتان این اطلاعات را از فایل تنظیمات برنامه و یا یک بانک اطلاعاتی دریافت کنید.
 

سیم کشی کردن 

بعد از پیاده سازی این اینترفیس نوبت به سیم کشی‌های SaasKit میرسد. من در اینجا سعی کردم که مثل الگوی برنامه‌های ASP.NET Core عمل کنم. ابتدا نیاز داریم که وابستگی‌های SaasKit را ثبت کنیم. فایل startups.cs  را باز کنید و کدهای زیر را در متد ConfigureServices اضافه نمایید: 
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMultitenancy<AppTenant, AppTenantResolver>();
    }
سپس باید میان افزار SaasKit را ثبت کنیم. کدهای زیر را به متد Configure اضافه کنید:
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        // after .UseStaticFiles()
        app.UseMultitenancy<AppTenant>();
        // before .UseMvc()
    }


دریافت مستاجر جاری 

حالا هر جا که نیاز به وهله‌ای از شیء مستاجر جاری داشتید، می‌توانید به روش زیر عمل کنید: 
    public class HomeController : Controller
    {
        private AppTenant tenant;
        public HomeController(AppTenant tenant)
        {
            this.tenant = tenant;
        }
    }
به عنوان مثال قصد داریم نام مستاجر را در عنوان سایت نمایش دهیم. برای اینکار ما از قابلیت جدید MVC Core یعنی تزریق سرویس‌ها به View استفاده خواهیم کرد.  در فایل Layout.cshtml_ تکه کد زیر را به بالای صفحه اضافه کنید:
    @inject AppTenant Tenant;
این کد، AppTenant را برای ما در تمامی View‌ها از طریق شی Tenant قابل دسترس می‌کند. حالا می‌توانیم در View خود از جزییات مستاجر به شکل زیر استفاده کنیم: 
    <a asp-controller="Home" asp-action="Index">@Tenant.Name</a>


اجرای نمونه مثال 

فایل project.json را باز کنید و مقدار web را به شکل زیر مقدار دهی کنید: (در اینجا برای سایت خود 3 آدرس را نگاشت کردیم) 
    "commands": {
      "web": "Microsoft.AspNet.Server.Kestrel --server.urls=http://localhost:6000;http://localhost:6001;http://localhost:6002",
    },
سپس کنسول را در محل ریشه پروژه باز نموده و دستور زیر را اجرا کنید: 
    dotnet run
حال اگر در مرورگر خود آدرس http://localhost:6000 را وارد کنیم، مستاجر 1 را خواهیم دید:


و اگر آدرس http://localhost:6002 را وارد کنیم، مستاجر 2 را مشاهده می‌کنیم:


قابل پیکربندی کردن مستاجر ها 

از آنجائیکه نوشتن مشخصات مستاجر‌ها در کد زیاد جالب نیست، برای همین تصمیم داریم که این مشخصات را با استفاده از قابلیت‌های ASP.NET Core از فایل appsettings.json دریافت کنیم. تنظیمات مستاجر‌ها را مطابق اطلاعات زیر به این فایل اضافه کنید:

    "Multitenancy": {
      "Tenants": [
        {
          "Name": "Tenant 1",
          "Hostnames": [
            "localhost:6000",
            "localhost:6001"
          ]
        },
        {
          "Name": "Tenant 2",
          "Hostnames": [
            "localhost:6002"
          ]
        }
      ]
    }
سپس کلاسی را که بیانگر تنظیمات چند مستاجری باشد، می‌نویسیم: 
    public class MultitenancyOptions
    {
        public Collection<AppTenant> Tenants { get; set; }
    }
حالا نیاز داریم که به برنامه اعلام کنیم تا تنظیمات مورد نیاز خود را از فایل appsettings.json بخواند. کد زیر را به ConfigureServices اضافه کنید: 
    services.Configure<MultitenancyOptions>(Configuration.GetSection("Multitenancy"));
سپس کدهای resolver خود را جهت دریافت اطلاعات از MultitenancyOptions مطابق زیر تغییر می‌دهیم: 
    public class AppTenantResolver : ITenantResolver<AppTenant>
    {
        private readonly IEnumerable<AppTenant> tenants;
        public AppTenantResolver(IOptions<MultitenancyOptions> options)
        {
            this.tenants = options.Value.Tenants;
        }
        public async Task<TenantContext<AppTenant>> ResolveAsync(HttpContext context)
        {
            TenantContext<AppTenant> tenantContext = null;
            var tenant = tenants.FirstOrDefault(t => 
                t.Hostnames.Any(h => h.Equals(context.Request.Host.Value.ToLower())));
            if (tenant != null)
            {
                tenantContext = new TenantContext<AppTenant>(tenant);
            }
            return Task.FromResult(tenantContext);
        }
    }
برنامه را یکبار re-build کرده و اجرا کنید . 


در آخر 

اولین قدم در پیاده سازی یک معماری multi-tenant، تصمیم گیری درباره این موضوع است که شما چطور مستاجر خود را شناسایی کنید. به محض این شناسایی شما می‌توانید عملیات‌های بعدی خود را مثل تفکیک بخشی از برنامه، فیلتر کردن داده‌ای، نمایش یک view خاص برای هر مستاجر و یا بازنویسی قسمت‌های مختلف برنامه بر اساس هر مستاجر، انجام دهید.

_ سورس مثال بالا در گیت هاب قابل دریافت می‌باشد.

_ منبع: اینجا  

مطالب
تاثیر تعداد فونت‌های نصب شده در سیستم بر روی سرعت بارگذاری اولیه برنامه‌ها
مدتی بود که سرعت آغاز ویژوال استودیو و همچنین تمام برنامه‌های دات نتی موجود، به نحو عجیبی کاهش پیدا کرده بودند. آغاز ویژوال استودیو گاهی تا 3 دقیقه هم طول می‌کشید. تا اینکه آغاز یک برنامه ساده‌ی دات نتی را توسط برنامه‌ی معروف Procmon بررسی کردم:


بله. همانطور که مشاهده می‌کنید، چون تعداد فونت‌های نصب شده‌ی بر روی سیستم من بیش از اندازه است (1800 فونت)، این مشکل رخ می‌دهد. هر بار آغاز برنامه‌های دات نت، به همراه بررسی تمام فونت‌های نصب شده‌ی بر روی سیستم هم هست و اگر تعداد آن‌ها زیاد باشد، شاید چند دقیقه‌ای این بررسی طول بکشد.

راه حل‌ها

الف) حذف فونت‌های اضافی سیستم
این مورد به طور قطع بر روی سایر برنامه‌های غیردات نتی هم تاثیر مثبت خواهد گذاشت. برای نمونه، این مورد بارگذاری فونت‌ها، در مرورگرها هم صادق است. به علاوه مصرف RAM سیستم را هم کاهش خواهد داد.
برای حذف فونت‌های اضافی:
- ابتدا به مسیر C:\Windows\Fonts مراجعه کنید. در لیست فونت‌ها، ابتدا ctrl+a و سپس delete. بله! حذف تمام فونت‌ها، تا جایی که ممکن است.
- در ادامه ویندوز به صورت توکار، قابلیت بازگشت به لیست ابتدایی سیستمی خود را دارد (جهت ترمیم مواردی که نباید حذف می‌شدند). برای این منظور باید مراحل ذیل را طی کنید:
 Start > Control Panel -> Appearance and Personalization -> Fonts -> Font Settings -> Restore Default Font Settings
و یا مراجعه‌ی مستقیم به پوشه‌ی C:\Windows\Fonts نیز معادل طی مسیر فوق است:



با کلیک بر روی دکمه‌ی «Restore Default Font Settings» قلم‌های اصلی ویندوز مجددا نصب خواهند شد و سیستم به حالت اول باز می‌گردد.


ب) تنظیم سرویس Font Cache ویندوز
سرویس ویژه‌ای به نام «Windows Presentation Foundation Font Cache 3.0.0.0» در ویندوزهایی که دات نت فریم ورک بر روی آن‌ها نصب است، وجود دارد:


کار آن کش کردن و به اشتراک گذاشتن اطلاعات قلم‌های نصب شده‌ی بر روی سیستم، بین تمام برنامه‌های WPF در حال اجرا است.
حالت آغاز این سرویس بر روی manual است. به این معنا که تا یک برنامه‌ی WPF ایی بر روی سیستم اجرا نشود، این سرویس فعال نخواهد شد. می‌توان این حالت آغاز را بر روی automatic قرار داد تا به تمام برنامه‌های WPF سیستم به صورت یکسانی، پیش از اجرای آن‌ها اعمال شود.
این تغییر توسط مایکروسافت هم توصیه شده‌است: «12. Understand the PresentationFontCache service »


نتیجه گیری
اگر آغاز برنامه‌ی دات نتی شما آنچنان سریع نیست، الزاما مشکل از Entity framework نیست. چه تعدادی فونت را نصب کرده‌اید؟!