مطالب
تزریق وابستگی‌ها در ASP.NET Core - بخش 1 - مقدمه
مقدمه

زمانیکه یک برنامه را بر پایه‌ی شیء گرایی طراحی می‌کنید و می‌نویسید، به صورت معمول جریان وابستگی‌ها در برنامه‌ی شما به صورت زیر است:


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

به عبارت دیگر در طراحی ساخت یافته، کلاس‌های سطح بالا، به کلاس‌های سطح پایین وابسته‌اند. این مسئله دو مشکل را ایجاد می‌کند:
  1. هر تغییری در کلاس‌های سطح پایین ممکن است باعث ایجاد اشکالی در کلاس‌های سطح بالا گردد.
  2. استفاده‌ی مجدد از کلاس‌های سطح بالا در جاهای دیگر مشکل است؛ زیرا وابستگی مستقیمی به کلاس‌های سطح پایین دارند.

اصل معکوس سازی / وارونگی وابستگی‌ها Dependency Inversion Principle
 
یکی از اصول پنجگانه‌ی طراحی برنامه‌های شیء گرا  که با نام اصول SOLID  شناخته می‌شوند، اصل «وارونگی وابستگی‌ها» است که روشی برای مشکل جفت شدگی و وابستگی کلاس‌ها به یکدیگر را به صورت تئوری ارائه می‌دهد.

 اصل وارونگی وابستگی‌ها بیان می‌کند:
  •   ماژول‌های (کلاس‌های) سطح بالا نباید به ماژولهای (کلاس‌های) سطح پایین وابسته باشند و هر دو باید به انتزاعات وابسته باشند (برای مثال interface‌ها).
  •   انتزاعات نباید وابسته به جزئیات باشند؛ بلکه جزئیات (پیاده سازی) باید وابسته به انتزاعات باشند.

بر اساس این اصل، ما باید در سطوح بالا سیاست گذاری‌ها و انتزاعات را در قالب interface‌ها تعریف کرده و کلاس‌های سطح بالای خود را بر همین اساس پیاده سازی کنیم و در سطوح پائین‌تر، پیاده سازی‌هایی را بر اساس انتزاعات و سیاست گذاری‌های سطوح بالاتر، انجام دهیم.

در شکل زیر، حالت عادی جریان کنترل را می‌بینید .
 


همانطور که می‌بینید، کلاس M برای اجرا، وابسته به کلاس N و متد F در درون آن است. در اینجا ما با استفاده از اینترفیس‌ها می‌توانیم جریان کنترل را معکوس یا وارونه کنیم که به این عمل «وارونگی کنترل یا Inversion of Control» می‌گویند.


 
شیء گرایی در واقع در مورد نحوه‌ی جریان کنترل است. در اینجا اینترفیس‌ها به ما کنترل کاملی را بر جریان کنترل (Flow of control) می‌دهند که با استفاده از این امکان می‌توانیم از نوشتن کدهای جفت شده، شکننده و کلاس‌هایی یکبار مصرف، بپرهیزیم.


الگوی Dependency Injection 
تزریق وابستگی یا Dependency Injection، یک الگوی طراحی است که از آن برای طراحی و پیاده سازی IoC Container‌ها استفاده می‌شود. این الگو به ما اجازه می‌دهد که اشیاء وابسته را خارج از کلاس بسازیم و آنها را به طریقی دیگر به کلاس، جهت استفاده ارائه دهیم. به‌وسیله‌ی DI ما ساخت و اتصال اشیاء وابسته به کلاس را از تعریف آن خارج می‌کنیم.

الگوی تزریق وابستگی 3 نوع کلاس را درگیر می‌کند:
  •  کلاس کلاینت / Client Class : کلاس کلاینت (کلاس وابسته) کلاسی است که به کلاس سرویس وابسته است .
  • کلاس سرویس  /  Service Class :  کلاس سرویس (وابستگی) کلاسی است که یک سرویس را به کلاس کلاینت ارائه می‌دهد.
  •  کلاس تزریق کننده / Injector Class  :  کلاس تزریق کننده، نمونه‌ای از کلاس سرویس را ساخته و به کلاس کلاینت، تزریق می‌کند.

شکل زیر وابستگی بین کلاس‌ها را شرح می‌دهد:

 
همانطور که می‌بینید، کلاس Injector، نمونه‌ای از کلاس سرویس را می‌سازد و آن را به نمونه‌ای از کلاس Client تزریق می‌کند. با این کار، DI، وظیفه‌ی ساخت یک نمونه از کلاس Service را از درون کلاس Client جدا می‌کند.

انواع تزریقات وابستگی‌ها:
به صورت کلی به سه روش و در سه مکان، امکان تزریق وابستگی کلاس سرویس، درون کلاس کلاینت وجود دارد:
  •   تزریق درون سازنده / Constructor Injection  : در تزریق درون سازنده، در سازنده‌ی کلاس کلاینت، لیستی از سرویس‌های مورد نیاز کلاس، که کلاس، برای عملکرد خود به آن‌ها «وابسته» است، ثبت می‌شوند و کلاس Injector، سرویس (وابستگی) مورد نظر را درون سازنده‌ی کلاس Client ارائه می‌دهد.
  •   تزریق درون Property  کلاس / Property Injection : در این حالت که همچنین با نام (Setter Injection) هم شناخته می‌شود، تزریق کننده، وابستگی را به وسیله‌ی یک Property عمومی کلاس کلاینت ارائه می‌دهد.
  •  تزریق درون متد / Method Injection  : در این حالت، خود کلاس کلاینت، یک پیاده سازی از یک interface را ارائه می‌کند که درون آن متدهایی برای ارائه‌ی وابستگی‌ها به کلاینت تعریف شده‌اند. در این وضعیت، تزریق کننده از این اینترفیس برای ارائه‌ی وابستگی‌ها به کلاینت درون متدها، استفاده می‌کند. 

هر کدام از روش‌های فوق مزایا و معایب خود را دارند، ولی در NET Core. بیشتر از «تزریق درون سازنده» استفاده می‌شود. در صورت لزوم می‌توانید از اینجا نمونه‌هایی از تزریق وابستگی را به هر کدام از سه روش بالا، مشاهده کنید.

Inversion of Control Container
در واژگان فنی مهندسی نرم افزار، Container (محفظه)  به جزیی از برنامه گفته می‌شود که می‌تواند اجزای دیگر برنامه را در بر بگیرد.  IoC Container ‌ها در واقع فریم ورک‌ها/چارچوب‌ها یا کتابخانه‌های برنامه نویسی هستند که ما در آنها می‌توانیم اشیاء مختلف را به سبک‌های خاصی تعریف و ثبت کنیم و در مواقع لزوم آنها را واکشی و به کلاس‌ها تزریق کنیم. معمولا  IoC Container‌ها لیستی از اشیاء هستند که در آن اینترفیس‌ها و پیاده سازی‌های مربوط به هر کدام از آن‌ها ثبت می‌شوند. درون IoC Container برای پیاده سازی اصل وارونگی وابستگی‌ها، معمولا از یکی از دو الگوی زیر استفاده می‌کنند (گاها هم دو الگو را با هم پیاده سازی می‌کنند) :
  •  Dependency Injection 
  • Service Locator

تمرکز اصلی ما در این نوشتار بر روی DI Container هاست. فرق Dependency Injection و Service Locator در این است که در DI، وابستگی‌ها توسط IoC Container از درون محفظه واکشی می‌شوند و به درون کد تزریق می‌شوند ولی در Service Locator در هر جایی از برنامه می‌توان با استفاده‌ی مستقیم از Container و با استفاده از متدهایی که به ما ارائه می‌دهد،  پرس و جو کرد (کوئری زد) و وابستگی مورد نظر را واکشی کرد.
در تزریق وابستگی، کلاس استفاده کننده از سرویس‌ها، درگیر نحوه‌ی واکشی و نمونه سازی از سرویس مورد نظر خود نمی‌شود و همه‌ی کار توسط DI Container انجام می‌گیرد. ولی در Service Locator باید سرویس مورد نظر، درون خود کلاس، مستقیما از Container دریافت و ساخته شود.
برای استفاده از Service Locator، تنها پیش نیاز، دسترسی به شیء Service Locator است.

به صورت کلی IoC Container ‌ها سه وظیفه‌ی اساسی را برعهده دارند:
  • ثبت سرویس درون خود
  •   ساخت نمونه‌های مورد نظر از سرویس‌ها و ارائه دادن آن‌ها به کلاس‌هایی که نیاز دارند.
  •  از بین بردن نمونه سرویس‌های ساخته شده (Dispose) کردن آن‌ها .

در ادامه با ساخت پروژه‌ای، اولین سرویس خودمان را درون Microsoft Dependency Injection Container یا به اختصار DI Container، ثبت کرده و آن را واکشی می‌کنیم.
مطالب
مروری بر قابلیت جدید ASP.NET FriendlyUrls
احتمالا به اهمیت بحث SEO و  آدرس‌های تمیز آن آشنا هستید. ASP.NET MVC از همان ابتدا از قابلیت URL Routing پشتیبانی می‌کرد و ASP.NET Web Forms هم از نسخه NET 4.0. این قابلیت را در خود اضافه نمود. با این حال نوشتن Url Routing برای وب سایت‌ها کمی مشکل و در ASP.NET کمتر استفاده می‌شود. علاوه بر آن تغییر آدرس‌های قدیمی با Url Routing بسیار وقت گیر می‌باشد. به همین خاطر تیم توسعه ASP.NET کتابخانه ای با نام Asp.NET FriendlyUrls که فعلا نسخه قبل از نهایی آن منتشر شده است را در اختیار توسعه دهندگان وب سایت‌ها قرار داده‌اند که با حداقل کد نویسی و بدون اضافه نمودن مسیریابی آدرس‌ها، تمام آدرس‌های قدیم و جدید را مطابق استاندارد SEO تغییر می‌دهد.

دریافت و نصب Asp.NET FriendlyUrls از Nuget
در Visual Studio 2012.2 در صورتی که یک پروژه جدید از نوع ASP.NET Web Forms ایجاد نمایید بصورت پیشفرض این کتابخانه نصب شده است. اما می‌توانید با دستور زیر نیز آن را از Nuget دریافت نمایید:
Install-Package Microsoft.AspNet.FriendlyUrls -Pre

پس از نصب، در کلاس Global می‌بایست کتابخانه را فعال نمایید:
public static class RouteConfig
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.EnableFriendlyUrls();
        }
    }
و همچنین در Application_Start
void Application_Start(object sender, EventArgs e)
        {
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
به همین راحتی؛ حال دو صفحه First.aspx و Second.aspx را به پروژه اضافه نمائید و وب سایت را اجرا کنید. بدون نوشتن پسوند aspx به صفحات دسترسی خواهید داشت:

از درون برنامه هم به راحتی می‌توانید صفحات را به همان صورت قبل بدون پسوند صدا بزنید:
Response.Redirect("~\\Second");
دسترسی به پارامترها نیز به صورت قبل امکان پذیر می‌باشد:
Response.Redirect("~\\First?Id=1001");

string Id = Request.QueryString["Id"] as string;
برای آدرس‌های پیشرفته‌تر، 3 متود الحاقی اضافه گردیده است. مثلا اگر آدرس زیر را داشته باشیم
http://localhost:57353/First/Products/NewProduct
  1. ()Request.GetFriendlyUrlFileVirtualPath
    مسیر مجازی فایل را بر می‌گرداند

  2. ()Request.GetFriendlyUrlSegments
    بخش‌های آدرس را بر می‌گرداند

  3. ()Request.GetFriendlyUrlFileExtension
    پسوند فایل آدرس را بر می‌گرداند

کلاس FriendlyUrl دو متود استاتیک و یک خاصیت دارد 

  1. FriendlyUrl.Segments
    شبیه ()Request.GetFriendlyUrlSegments مجموعه بخش‌های آدرس صفحه جاری را بر می‌گرداند 
  2. FriendlyUrl.Resolve 
    آدرس صفحه جاری را بر می‌گرداند 
  3. FriendlyUrl.Href
    امکان ساخت یک آدرس را با استفاده از مسیر مجازی، بخش‌ها و پارامتر‌ها، فراهم می‌نماید

  

در آخر، فضای نام کتابخانه، Microsoft.AspNet.FriendlyUrls می‌باشد.
اشتراک‌ها
ساخت برنامه های پویای Blazor به کمک فریم ورک Octane

Octane فریم ورکی است جهت ساخت برنامه‌های Modular در Blazor. به کمک این برنامه می‌توانید صفحات مورد نظر خود را طراحی کرده و به وب سایت خود اضافه کنید. لینکی جهت نمایش بعضی از قابلیتهای آن در یوتیوب نمایش .

ساخت برنامه های پویای Blazor به کمک فریم ورک Octane
اشتراک‌ها
با پلیمر احساس متفاوتی از طراحی المان های وب داشته باشید

شرکت گوگل جدیدا محصولی به نام Polymer ارائه کرده است که میتواند برای نوسع دهندگان وب مفید و لذتبخش باشد. این طراحی همانند sdk می‌باشد که با آن میتوانید کنترل‌های اختصاصی‌تری بسازید و المان‌های پیش فرض جالبی دارد.

با پلیمر احساس متفاوتی از طراحی المان های وب داشته باشید
نظرات مطالب
EF Code First #12
توضیحات بالا برای برنامه‌های وب بهینه شده. در آنجا در Application_EndRequest به صورت خودکار کانکشن بسته میشه (با کد ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects  که نوشته شد).
در برنامه‌های ویندوزی این مدیریت رو باید خودتون دستی انجام بدید و چنین مکانیزمی در آن طراحی نشده.
مطالب دوره‌ها
مدیریت تغییرات گریدی از اطلاعات به کمک استفاده از الگوی واحد کار مشترک بین ViewModel و لایه سرویس
قالب پروژه WPF Framework به همراه چندین صفحه ابتدایی لازم، برای شروع هر برنامه‌ی تجاری دسکتاپی است؛ مثال مانند صفحه لاگین، صفحه تغییرات مشخصات کاربر وارد شده به سیستم و امثال آن. صفحه‌ای را که در این قسمت بررسی خواهیم کرد، صفحه تعریف کاربران جدید و ویرایش اطلاعات کاربران موجود است.


در این صفحه با کلیک بر روی دکمه به علاوه، یک ردیف به ردیف‌های موجود اضافه شده و در اینجا می‌توان اطلاعات کاربر جدیدی به همراه سطح دسترسی او را وارد و ذخیره کرد و یا حتی اطلاعات کاربران موجود را ویرایش نمود. اگر بخواهیم مانند مراحلی که در قسمت قبل در مورد تعریف یک صفحه جدید در برنامه توضیح داده شد، عمل کنیم، به صورت خلاصه به ترتیب ذیل عمل شده است:
1) ایجاد صفحه تغییر مشخصات کاربر
ابتدا صفحه Views\Admin\AddNewUser.xaml به پروژه ریشه که Viewهای برنامه در آن تعریف می‌شوند، اضافه شده است. به همراه دو دکمه و یک ListView که تطابق بهتری با قالب متروی مورد استفاده دارد.

2) تنظیم اعتبارسنجی صفحه اضافه شده
مرحله بعد تعریف هر صفحه‌ای در سیستم، مشخص سازی وضعیت دسترسی به آن است:
/// <summary>
/// افزودن و مدیریت کاربران سیستم
/// </summary>
[PageAuthorization(AuthorizationType.ApplyRequiredRoles, "IsAdmin, CanAddNewUser")]
ویژگی PageAuthorization به فایل Views\Admin\AddNewUser.xaml.cs اعمال شده است. در اینجا تنها کاربرانی که خاصیت‌های IsAdmin و CanAddNewUser آن‌ها true باشند، مجوز دسترسی به صفحه تعریف کاربران را خواهند یافت.

3) تغییر منوی برنامه جهت اشاره به صفحه جدید
در ادامه در فایل منوی برنامه Views\MainMenu.xaml تعریف دسترسی به صفحه Views\Admin\AddNewUser.xaml قید شده است:
                <Button Style="{DynamicResource MetroCircleButtonStyle}"
                        Height="55" Width="55"  
                        Command="{Binding DoNavigate}"
                        CommandParameter="\Views\Admin\AddNewUser.xaml"
                        Margin="2">
                    <Rectangle Width="28" Height="17.25">
                        <Rectangle.Fill>
                            <VisualBrush Stretch="Fill" Visual="{StaticResource appbar_user_add}" />
                        </Rectangle.Fill>
                    </Rectangle>
                </Button>
همانطور که در قسمت قبل نیز توضیح داده شده، تنها کافی است در اینجا CommandParameter را مساوی مسیر فایل AddNewUser.xaml قرار دهیم تا سیستم راهبری به صورت خودکار از آن استفاده کند.

4) ایجاد ViewModel متناظر با صفحه
مرحله نهایی تعریف صفحه AddNewUser، افزودن ViewModel متناظر با آن است که سورس کامل آن‌را در فایل ViewModels\Admin\AddNewUserViewModel.cs پروژه Infrastructure می‌توانید ملاحظه کنید.
نکته مهم این ViewModel، ارائه خاصیت لیست کاربران از نوع ObservableCollection به View و گرید برنامه است:
public ObservableCollection<User> UsersList { set; get; }
اطلاعات آن از IUsersService تزریق شده در سازنده کلاس ViewModel دریافت می‌شود:
        /// <summary>
        /// جهت مقاصد انقیاد داده‌ها در دبلیو پی اف طراحی شده است
        /// لیستی از کاربران سیستم را باز می‌گرداند
        /// </summary>
        /// <param name="count">تعداد کاربر مد نظر</param>
        /// <returns>لیستی از کاربران</returns>
        public ObservableCollection<User> GetSyncedUsersList(int count = 1000)
        {
            _users.OrderBy(x => x.FriendlyName).Take(count)
                  .Load();

            // For Databinding with WPF.
            // Before calling this method you need to fill the context by using `Load()` method.
            return _users.Local;
        }
این کدها را در فایل UsersService.cs لایه سرویس برنامه می‌توانید مشاهده نمائید.
در اینجا از قابلیت خاصیتی به نام Local که یک ObservableCollection تحت نظر EF را بازگشت می‌دهد، استفاده شده است. برای استفاده از این خاصیت، ابتدا باید کوئری خود را تهیه و سپس متد Load را بر روی آن فراخوانی کرد. سپس خاصیت Local بر اساس اطلاعات کوئری قبلی پر و مقدار دهی خواهد شد.
علت انتخاب نام Synced برای این متد، تحت نظر بودن اطلاعات خاصیت Local است تا زمانیکه Context تعریف شده زنده نگه داشته شود. به همین جهت در برنامه جاری از روش زنده نگه داشتن Context به ازای یک ViewModel استفاده شده است.
به Context، توسط اینترفیس IUnitOfWork تزریق شده در سازنده کلاس ViewModel می‌توان دسترسی یافت. چون در اینجا از تزریق وابستگی‌ها استفاده شده است، وهله‌ای که IUnitOfWork کلاس AddNewUserViewModel را تشکیل می‌دهد، دقیقا همان وهله‌ای است که در کلاس UsersService لایه سرویس استفاده شده است. در نتیجه، در گرید برنامه هر تغییری اعمال شود، تحت نظر IUnitOfWork خواهد بود و صرفا با فراخوانی متد uow.ApplyAllChanges آن، کلیه تغییرات تمام ردیف‌های تحت نظر EF به صورت خودکار در بانک اطلاعاتی درج و یا به روز خواهند شد.
همچنین در مورد ViewModelContextHasChanges نیز در قسمت قبل بحث شد. در اینجا پیاده سازی کننده آن صرفا خاصیت uow.ContextHasChanges است. به این ترتیب اگر کاربر، تغییری را در صفحه داده باشد و بخواهد به صفحه دیگری رجوع کند، با پیام زیر مواجه خواهد شد:


از همین خاصیت برای فعال و غیرفعال کردن دکمه ذخیره سازی اطلاعات نیز استفاده شده است:
  /// <summary>
  /// فعال و غیرفعال سازی خودکار دکمه ثبت
  /// این متد به صورت خودکار توسط RelayCommand کنترل می‌شود
  /// </summary>  
  private bool canDoSave()
  {
     // آیا در حین نمایش صفحه‌ای دیگر باید به کاربر پیغام داد که اطلاعات ذخیره نشده‌ای وجود دارد؟
     return ViewModelContextHasChanges;
  }
این متد توسط RelayCommand ایی به نام  DoSave
  /// <summary>
  /// رخداد ذخیره سازی اطلاعات را دریافت می‌کند
  /// </summary>
  public RelayCommand DoSave { set; get; }
که به نحو زیر مقدار دهی شده است، مورد استفاده قرار می‌گیرد:
DoSave = new RelayCommand(doSave, canDoSave);
به ازای هر تغییری در UI، این RelayCommand به نتیجه canDoSave مراجعه کرده و اگر خروجی آن true باشد، دکمه متناظر را به صورت خودکار فعال می‌کند و یا برعکس.
این بررسی نیز بسیار سبک و سریع است. از این جهت که تغییرات Context در حافظه نگهداری می‌شوند و مراجعه به آن مساوی مراجعه به بانک اطلاعاتی نیست.
مطالب
مدیریت سشن‌ها در برنامه‌های وب به کمک تزریق وابستگی‌ها
سشن‌ها در برنامه‌های وب، یکی از وابستگی‌های استاتیکی هستند که می‌توان آن‌ها را از طریق تزریق وابستگی‌ها، جهت بالا بردن قابلیت آزمون پذیری برنامه، تامین کرد. همچنین اگر از سشن‌ها برای نمونه در برنامه‌های ASP.NET MVC استفاده کنید، مقدار آن‌ها در سازنده‌ی کنترلرها نال خواهند بود؛ از این جهت که در زمان نمونه سازی یک کنترلر توسط IoC Container، کار مدیریت سشن‌ها صورت نمی‌گیرد و اگر در این بین سرویسی نیاز به سشن داشته باشد، دیگر وهله سازی نخواهد شد؛ به این دلیل که صرفنظر از مقدار دهی متغیر سشن در صفحه‌ای دیگر، این مقدار در سازنده‌ی کلاس، نال است. در ادامه این مشکل را از طریق غنی سازی تزریق وابستگی‌ها با اطلاعات سشن جاری، برطرف خواهیم کرد.


طراحی یک تامین کننده‌ی عمومی سشن

public interface ISessionProvider
{
    object Get(string key);
    T Get<T>(string key) where T : class;
    void Remove(string key);
    void RemoveAll();
    void Store(string key, object value);
}
در اینجا یک اینترفیس عمومی را مشاهده می‌کنید که کار آن کپسوله سازی اعمال متداول کار با سشن‌ها است؛ برای مثال دریافت اطلاعات یک سشن، بر اساس کلیدی مشخص و یا ذخیره سازی اطلاعات اشیاء در سشن‌ها.
یک نمونه پیاده سازی عمومی آن نیز برای کار با سشن‌ها در برنامه‌های وب ASP.NET وب فرم و MVC، می‌تواند به صورت زیر باشد:
public class DefaultWebSessionProvider : ISessionProvider
{
    private readonly HttpSessionStateBase _session;
 
    public DefaultWebSessionProvider(HttpSessionStateBase session)
    {
        _session = session;
    }
 
    public object Get(string key)
    {
        return _session[key];
    }
 
    public T Get<T>(string key) where T : class
    {
        return _session[key] as T;
    }
 
    public void Remove(string key)
    {
        _session.Remove(key);
    }
 
    public void RemoveAll()
    {
        _session.RemoveAll();
    }
 
    public void Store(string key, object value)
    {
        _session[key] = value;
    }
}
در کلاس DefaultWebSessionProvider مستقیما از HttpContext.Current.Session برای دسترسی به سشن جاری استفاده نشده‌است. این مقدار را از سازنده‌ی خود که توسط کلاس پایه HttpSessionStateBase تامین می‌شود، دریافت خواهد کرد. این سازنده را توسط تنظیمات ابتدایی IoC Container خود وهله سازی و مقدار دهی می‌کنیم؛ زیرا HttpContext.Current.Session برای مقدار دهی، نیاز به راه اندازی یک وب سرور دارد و عملا استفاده و شبیه سازی از آن در بسیاری از آزمون‌های واحد، بسیار مشکل خواهد بود.
private static Container defaultContainer()
{
    return new Container(ioc =>
    {
        // session manager setup
        ioc.For<ISessionProvider>().Use<DefaultWebSessionProvider>();
        ioc.For<HttpSessionStateBase>()
           .Use(ctx => new HttpSessionStateWrapper(HttpContext.Current.Session)); 
 
        ioc.Policies.SetAllProperties(properties =>
        {
            properties.OfType<ISessionProvider>();
        });
    });
}
در مثال فوق یک نمونه از تنظیمات ابتدایی StructureMap را برای استفاده از مقدار HttpContext.Current.Session، جهت وهله سازی سازنده‌ی کلاس DefaultWebSessionProvider مشاهده می‌کنید.


استفاده از تامین کننده‌ی سفارشی سشن در برنامه

پس از طراحی تامین کننده‌ی سفارشی سشن و همچنین معرفی آن به IoC Container خود، اکنون استفاده‌ی از آن به سادگی ذیل است:
public class HomeController : Controller
{
    private readonly ISessionProvider _sessionProvider;
    public HomeController(ISessionProvider sessionProvider)
    {
        _sessionProvider = sessionProvider;
    }
بنابراین اگر در کلاسی، کنترلری و یا سرویسی نیاز به سشن وجود داشت، بهتر است از ISessionProvider بجای مقدار دهی و یا دسترسی مستقیم به شیء استاتیک Session استفاده کرد.
اشتراک‌ها
پلاگین jquery-svg

استفاده از تگ Object یکی از بهترین روش‌ها برای بارگذاری تصاویر svg در صفحات HTML هست  و پلاگین jquery-svg ، پلاگینی کم حجم برای اعمال استایل‌های css و اسکریپت‌های jquery به فایل SVG بارگذاری شده توسط تگ Object است.

پلاگین jquery-svg
اشتراک‌ها
آموزش برنامه نویسی به کودکان

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

آموزش برنامه نویسی به کودکان
نظرات مطالب
NOSQL قسمت سوم
سلام تشکر از مطلب بسیار مفیدتون .
می خواستم بدونم که کدام یک از روش‌ها بیشتر امتحان خودش رو توی داده‌های زیاد پس داده .و بشه راحتر باهاش کار کرد .
روش 
Document store
Key value
روش هایی دیگری رو هم توی سایت دیدم اگر امکان داره مزایا و معایب هر کدوم رو توضیح دهید ممنون.