مطالب
بررسی Environment در Angular
در بین توسعه دهندگان، خیلی رایج است، چند نسخه از Application خود را داشته باشند که Environment‌‌های مختلفی را مورد هدف قرار می‌دهد؛ مثل development که مربوط به حالت توسعه می‌باشد و production که مربوط به حالت ارائه نهایی است. هر Environment تعدادی متغیر منحصر بفرد خود را خواهد داشت؛ مثلAPI Endpoint ،  app version  و ... . انگیولار تنظیمات Environment  را فراهم کرده است تا بتوانیم متغیر‌های منحصر بفردی را برای هر Environment، تعریف کنیم. 
اگر شما می‌خواهید به صورت خودکار یک flag را اعمال کنید، اجازه بدهید بگوییم prod-- ، در این حالت angular compiler متغیر API endpoint را با API endpoint مربوط به حالت ارائه نهایی برای شما جایگزین می‌کند. چیزی که شما نمی‌خواهید این است که به صورت دستی endpoint را قبل از build پروژه، تغییر دهید. این موضوع شانس دچار اشتباه شدن را کاهش می‌دهد.

Dealing with only 2 Environments  

به صورت پیش فرض انگیولار از دو Environment پشتیبانی می‌کند. فایل‌های Environment در دایرکتوری environment  آن قرار دارند که در مسیر زیر می‌باشد:
داخل دایرکتوری src، در ریشه WorkSpace یا پوشه پروژه شما( آشنایی با مفهوم WorkSpace  در انگیولار ). 
در داخل دایرکتوری environment، دو فایل با نام‌های environment.ts و environment.prod.ts وجود دارند. همانطور که ممکن است حدس زده باشید، فایل دوم برای حالت ارائه نهایی می‌باشد؛ در حالیکه فایل اول برای حالت توسعه است و همچنین به عنوان Environment پیش فرض نیز می‌باشد. Angular CLI compiler ، به صورت خودکار فایل اول را با فایل دوم،  هر زمان که شما build را با prod--  انجام میدهید، جایگزین می‌کند:
ng build --prod

اگر فایل environment.ts را باز کنید، خصوصیت production  به false تنظیم شده است؛ درحالیکه در environment.prod.ts خصویت production به true تنظیم شده‌است. همه متغیرها بر اساس Environment مشخصی، تفاوت ایجاد می‌کنند که به صورت مناسب باید در دو فایل قرار داده شوند:
// environment.ts environment variables
export const environment = {
  production: false,
  APIEndpoint: 'https://dev.endpoint.com'
};

// environment.prod.ts environment variables
export const environment = {
  production: true,
  APIEndpoint: 'https://prod.endpoint.com'
};
در اینجا خصوصیت APIEndpoint را داریم. در صورتیکه در حالت توسعه باشد، از آدرس https://dev.endpoint.com و در حالت ارائه نهایی از https://prod.endpoint.com استفاده خواهد کرد.

برای دستیابی به این متغیر‌ها، environment را import کرده و از آن همانند زیر استفاده می‌کنیم:
import { environment } from './../environments/environment';
که به صورت زیر از آن استفاده می‌شود:
const APIEndpoint = environment.APIEndpoint;
در ادامه، هر زمان که شما پروژه خود را بدون build , --prod کنید در متغیر APIEndpoint تعریف شده در بالا، مقدار https://dev.endpoint.com قرار خواهد گرفت که در این حالت از Environment پیش فرض استفاده می‌شود؛ در حالیکه، وقتی از prod-- استفاده می‌کنید، در متغیر APIEndpoint، مقدار https://prod.endpoint.com قرار خواهد گرفت که در این حالت از environment.prod.ts  استفاده می‌شود.

Dealing with 3 or More Environment 

این موضوع خیلی رایج است که برای Application ‌های خود، بیش از دو Environment داشته باشیم. ممکن است که شما نیاز داشته باشید به:
staging environment ،  beta environment ، production environment ، development environment  و ...  . انگیولار یک راه را برای ما فراهم کرده است که به صورت دستی Environment‌‌‌های بیشتری را که ممکن است نیاز داشته باشیم، اضافه کنیم. در اینجا ما نیاز به دو Environment دیگر به نام‌های staging و beta داریم. کار را با ایجاد کردن دو فایل دیگر در کنار environment ‌های موجود شروع می‌کنیم:
1-environment.staging.ts
2-environment.beta.ts
سپس هر کدام از آن‌ها را به صورت زیر ویرایش می‌کنیم: 
// environment.staging.ts environment variables
export const environment = {
  production: true
  APIEndpoint: "https://staging.endpoint.com"
};

// environment.beta.ts environment variables
export const environment = {
  production: true,
  APIEndpoint: "https://beta.endpoint.com"
};

در ادامه نیاز است در فایل angular.json، تنظیمات را تغییر دهیم ( که در ریشه Workspace  می‌باشد) . با انجام این‌کار، این امکان به Angular CLI داده خواهد شد که دو environment جدید ایجاد شده را شناسایی و در صورت نیاز از آن‌ها استفاده کند.

در ابتدا فایل angular.json را باز می‌کنیم و کلید configurations را می‌یابیم که در مسیر زیر می‌باشد:
projects -> yourappname -> architect -> build -> configurations
در اینجا به صورت پیش فرض یک کلید با نام production و تنظیمات زیر وجود دارد:
"configurations": {
   "production": {
       "fileReplacements": [
           {
              "replace": "src/environments/environment.ts",
               "with": "src/environments/environment.prod.ts"
           }
        ],
        "optimization": true,
        "outputHashing": "all",
        "sourceMap": false,
        "extractCss": true,
        "namedChunks": false,
        "aot": true,
        "extractLicenses": true,
        "vendorChunk": false,
        "buildOptimizer": true,
        "serviceWorker": true
   }
}

سپس از کلید production  و تنظمیات درون آن، یک نمونه تهیه می‌کنیم و در زیر کلید production  قرار می‌دهیم. سپس کلید production را به staging تغیر می‌دهیم. در قسمت fileReplacements مقدار کلید with را از
"with":"src/environments/environment.prod.ts"
به
"with":"src/environments/environment.staging.ts"
تغیر می‌دهیم. 
اکنون تنظیمات جدید شما برای staging environment باید به صورت زیر باشد: 
"configurations": {
   "production": {
        // ...
    },
    "staging": {
    "fileReplacements": [
     {
         "replace": "src/environments/environment.ts",
         "with": "src/environments/environment.staging.ts"
     }],
     "optimization": true,
     "outputHashing": "all",
     "sourceMap": true,
     "extractCss": false,
     "namedChunks": false,
     "aot": false,
     "extractLicenses": true,
     "vendorChunk": false,
     "buildOptimizer": true,
     "serviceWorker": true
   }
}

در ادامه همین روال را برای beta environment هم تکرار کنید.

نکته 
ممکن است شما نیاز داشته باشید تا تنظیمات بالا را به حالتی دقیق‌تر نسبت به environment مورد نظر اصلاح کنید. مثلا ممکن است نیاز داشته باشید، Service worker را در حالت staging فعال نگه دارید و در حالت beta آن را غیر فعال کنید که این تضمین می‌کند وقتی ریفرش انجام می‌شود، app ، Service worker  و منابع مربوط به آن را در مرورگر کش نکرده باشد.

Building your App 

در نهایت برای build کردن application خود با environment‌‌‌های سفارشی ایجاد شده، می‌توانید از پرچم configurations-- استفاده کنید؛ همانند زیر:
//for staging environment
ng build --configuration=staging

//for beta environment
ng build --configuration=beta

و در نهایت برای استفاده کردن از environment پیش فرض، استفاده از دستور زیر به تنهایی کافی می‌باشد:
//for production environment
ng build --prod

//for dev environment
ng build

مطالعه بیشتر جهت توزیع برنامه  : Angular CLI - ساخت و توزیع برنامه 
اکنون شما می‌توانید پروژه انگیولار خود را با هر تعداد environment ای که دوست دارید، configure کنید. 
مطالب
VS Code برای توسعه دهندگان ASP.NET Core - قسمت دوم - ایجاد و اجرای اولین برنامه
پس از معرفی ابتدایی VSCode و نصب افزونه‌ی #C در قسمت قبل، در ادامه می‌خواهیم اولین پروژه‌ی ASP.NET Core خود را در آن ایجاد کنیم.


نصب ASP.NET Core بر روی سیستم عامل‌های مختلف

برای نصب پیشنیازهای کار با ASP.NET Core به آدرس https://www.microsoft.com/net/download/core مراجعه کرده و NET Core SDK. را دریافت و نصب کنید. پس از نصب آن جهت اطمینان از صحت انجام عملیات، دستور dotnet --version را در خط فرمان صادر کنید:
 C:\>dotnet --version
1.0.1
در اینجا SDK نصب شده، شامل هر دو نگارش 1.0 و 1,1 است. همچنین در همین صفحه‌ی دریافت فایل‌ها، علاوه بر نگارش ویندوز، نگارش‌های Mac و لینوکس آن نیز موجود هستند. بر روی هر کدام که کلیک کنید، ریز مراحل نصب هم به همراه آن‌ها وجود دارد. برای مثال نصب NET Core. بر روی Mac شامل نصب OpenSSL به صورت جداگانه است و یا نصب آن بر روی لینوکس به همراه چند دستور مختص به توزیع مورد استفاده می‌باشد که به خوبی مستند شده‌اند و نیازی به تکرار آن‌ها نیست و همواره آخرین نگارش آن‌ها بر روی سایت dot.net موجود است.


ایجاد اولین پروژه‌ی ASP.NET Core توسط NET Core SDK.

پس از نصب NET Core SDK.، به پیشنیاز دیگری برای شروع به کار با ASP.NET Core نیازی نیست. نه نیازی است تا آخرین نگارش ویژوال استودیوی کامل را نصب کنید و نه با به روز رسانی آن، نیاز است چندگیگابایت فایل به روز رسانی تکمیلی را دریافت کرد. همینقدر که این SDK نصب شود، می‌توان بلافاصله شروع به کار با این نگارش جدید کرد.
در ادامه ابتدا پوشه‌ی جدید پروژه‌ی خود را ساخته (برای مثال در مسیر D:\vs-code-examples\FirstAspNetCoreProject) و سپس از طریق خط فرمان به این پوشه وارد می‌شویم.

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

پس از وارد شدن به پوشه‌ی جدید از طریق خط فرمان، دستور dotnet new --help را صادر کنید:
D:\vs-code-examples\FirstAspNetCoreProject>dotnet new --help
Getting ready...
Template Instantiation Commands for .NET Core CLI.

Usage: dotnet new [arguments] [options]

Arguments:
  template  The template to instantiate.

Options:
  -l|--list         List templates containing the specified name.
  -lang|--language  Specifies the language of the template to create
  -n|--name         The name for the output being created. If no name is specified, the name of the current directory is used.
  -o|--output       Location to place the generated output.
  -h|--help         Displays help for this command.
  -all|--show-all   Shows all templates


Templates                 Short Name      Language      Tags
----------------------------------------------------------------------
Console Application       console         [C#], F#      Common/Console
Class library             classlib        [C#], F#      Common/Library
Unit Test Project         mstest          [C#], F#      Test/MSTest
xUnit Test Project        xunit           [C#], F#      Test/xUnit
ASP.NET Core Empty        web             [C#]          Web/Empty
ASP.NET Core Web App      mvc             [C#], F#      Web/MVC
ASP.NET Core Web API      webapi          [C#]          Web/WebAPI
Solution File             sln                           Solution

Examples:
    dotnet new mvc --auth None --framework netcoreapp1.1
    dotnet new xunit --framework netcoreapp1.1
    dotnet new --help
همانطور که مشاهده می‌کنید، اینبار بجای انتخاب گزینه‌های مختلف از صفحه دیالوگ new project template داخل ویژوال استودیوی کامل، تمام این قالب‌ها از طریق خط فرمان در اختیار ما هستند. برای مثال می‌توان یک برنامه کنسول و یا یک کتابخانه‌ی جدید را ایجاد کرد.
در ادامه دستور ذیل را صادر کنید:
 D:\vs-code-examples\FirstAspNetCoreProject>dotnet new mvc --auth None
به این ترتیب یک پروژه‌ی جدید ASP.NET Core، بدون تنظیمات اعتبارسنجی و ASP.NET Core Identity، در کسری از ثانیه ایجاد خواهد شد.


سپس جهت گشودن این پروژه در VSCode تنها کافی است دستور ذیل را صادر کنیم:
 D:\vs-code-examples\FirstAspNetCoreProject>code .
در ادامه یکی از فایل‌های #C آن‌را گشوده و منتظر شوید تا کار دریافت خودکار بسته‌های مرتبط با افزونه‌ی #C ایی که در قسمت قبل نصب کردیم به پایان برسند:


اینکار یکبار باید انجام شود و پس از آن امکانات زبان #C و همچنین دیباگر NET Core. در VS Code قابل استفاده خواهند بود.
در تصویر فوق دو اخطار را هم مشاهده می‌کنید. مورد اول برای فعال سازی دیباگ و ساخت پروژه‌ی جاری است. گزینه‌ی Yes آن‌را انتخاب کنید و اخطار دوم جهت بازیابی بسته‌های نیوگت پروژه‌است که گزینه‌ی restore آن‌را انتخاب نمائید. البته کار بازیابی بسته‌ها از طریق کش موجود در سیستم به سرعت انجام خواهد شد.


گشودن کنسول از درون VS Code و اجرای برنامه‌ی ASP.NET Core

روش‌های متعددی برای گشودن کنسول خط فرمان در VS Code وجود دارند:
الف) فشردن دکمه‌های Ctrl+Shift+C
اینکار باعث می‌شود تا command prompt ویندوز از پوشه‌ی جاری به صورت مجزایی اجرا شود.
ب) فشردن دکمه‌های Ctrl+` (و یا Ctrl+ back-tick)
به این ترتیب کنسول پاورشل درون خود VS Code باز خواهد شد. اگر علاقمند نیستید تا از پاورشل استفاده کنید، می‌توانید این پیش‌فرض را به نحو ذیل بازنویسی کنید:
همانطور که در قسمت قبل نیز ذکر شد، از طریق منوی File->Preferences->Settings می‌توان به تنظیمات VS Code دسترسی یافت. پس از گشودن آن، یک سطر ذیل را به آن اضافه کنید:
 "terminal.integrated.shell.windows": "cmd.exe"
اکنون Ctrl+ back-tick را فشرده تا کنسول خط فرمان، داخل VS Code نمایان شود و سپس دستور ذیل را صادر کنید:
 D:\vs-code-examples\FirstAspNetCoreProject>dotnet run
Hosting environment: Production
Content root path: D:\vs-code-examples\FirstAspNetCoreProject
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
در اینجا دستور dotnet run سبب کامپایل و همچنین اجرای پروژه شده‌است و اکنون این برنامه‌ی وب بر روی پورت 5000 قابل دسترسی است:



ساده سازی ساخت و اجرای یک برنامه‌ی ASP.NET Core در VS Code


زمانیکه گزینه‌ی افزودن امکانات ساخت و دیباگ را انتخاب می‌کنیم (تصویر فوق)، دو فایل جدید به پوشه‌ی vscode. اضافه می‌شوند:


دراینجا فایل tasks.json، حاوی وظیفه‌ای است جهت ساخت برنامه. یعنی بجای اینکه مدام بخواهیم به خط فرمان مراجعه کرده و دستوراتی را صادر کنیم، می‌توان از وظایفی که در پشت صحنه همین فرامین را اجرا می‌کنند، استفاده کنیم؛ که نمونه‌ای از آن، به صورت پیش فرض به پروژه اضافه شده است.
برای دسترسی به آن، دکمه‌های ctrl+shift+p را فشرده و سپس در منوی ظاهر شده، واژه‌ی build را جستجو کنید:


با انتخاب این گزینه (که توسط Ctrl+Shift+B هم در دسترس است)، کار ساخت برنامه انجام شده و dll مرتبط با آن در پوشه‌ی bin تشکیل می‌شود.
 
همچنین در اینجا برای ساخت و بلافاصله نمایش آن در مرورگر پیش فرض سیستم، می‌توان مجددا دکمه‌های ctrl+shift+p را فشرد و در منوی ظاهر شده، واژه‌ی without را جستجو کرد:


با انتخاب این گزینه (که توسط Ctrl+F5 نیز در دسترس است)، برنامه ساخته شده، اجرا و نمایش داده می‌شود و برای خاتمه‌ی آن می‌توانید دکمه‌های Ctrl+C را بفشارید تا کار وب سرور موقتی آن خاتمه یابد.


در قسمت بعد مباحث دیباگ برنامه و گردش کار متداول یک پروژه‌ی ASP.NET Core را بررسی خواهیم کرد.
نظرات مطالب
روش نصب NET SDK. بر روی لینوکس Ubuntu

برای نصب از طریق دانلود فایل های دات نت به صورت آفلاین بر روی سرور بدون اینترنت میتوانید از روش زیر هم استفاده کنید.

  • ابتدا فایل های دات نت رو بسته به معماری سیستم دانلود کنید. (Arm32 | Arm32 Alpine | Arm64 | Arm64 Alpine | x64 | x64 Alpine)
  • سپس فایل دات نت رو به سرور خود منتقل کنید و از طریق دستورات زیر، خط فرمان dotnet رو به ترمینال اضافه کنید:
export DOTNET_ROOT="$HOME/yourpath/dotnet"
export PATH="$PATH:$HOME/yourpath/dotnet"

مشابه با Edit the system environment variables در ویندوز

و اکنون با نوشتن دستور dotnet --version میتوانید نگارش ورژن دات رو مشاهده کنید.

همچنین اگر نیاز به نصب tools هایی مانند ef core نیاز دارید میتوانید از دستور زیر استفاده کنید:

dotnet tool install --global dotnet-ef
export PATH="$PATH:$HOME/.dotnet/tools"

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

مطالب
استفاده از چندین Context در EF 6 Code first
در نگارش قبلی EF Code first به ازای یک پروژه تنها یک سیستم Migration قابل تعریف بود و این سیستم مهاجرت، تنها با یک DbContext کار می‌کرد. در نگارش ششم این کتابخانه، سیستم مهاجرت Code first آن از چندین DbContext، به ازای یک پروژه که به یک بانک اطلاعاتی اشاره می‌کنند، پشتیبانی می‌کند. مزیت اینکار اندکی بهبود در نگهداری تنها کلاس DbContext تعریف شده است. برای مثال می‌توان یک کلاس DbContext مخصوص قسمت ثبت نام را ایجاد کرد. یک کلاس DbContext مخصوص کلیه جداول مرتبط با مقالات را و همینطور الی آخر. نهایتا تمام این Contextها سبب ایجاد یک بانک اطلاعاتی واحد خواهند شد.
اگر در یک پروژه EF Code first چندین Context وجود داشته باشد و دستور enable-migrations را بدون پارامتری فراخوانی کنیم، پیغام خطای More than one context type was found in the assmbly xyz را دریافت خواهیم کرد.
الف) اما در EF 6 می‌توان با بکار بردن سوئیچ جدید ContextTypeName، به ازای هر Context، مهاجرت مرتبط با آن‌را تنظیم نمود:
 enable-migrations -ContextTypeName dbContextName1 -MigrationDirectory DataContexts\Name1Migrations
همچنین در اینجا نیز می‌توان با استفاده از سوئیچ MigrationDirectory، فایل‌های تولید شده را در پوشه‌های مجزایی ذخیره کرد.

ب) در مرحله بعد، نیاز به فراخوانی دستور add-migration است:
 add-migration -ConfigurationTypeName FullNameSpaceCtx1.Configuration "InitialCreate"
با اجرای دستور enable-migrations یک کلاس Configuration جهت DbContext مشخص شده، ایجاد می‌شود. سپس آدرس کامل این کلاس را به همراه ذکر دقیق فضای نام آن در اختیار دستور add-migration قرار می‌دهیم.
ذکر کامل فضای نام، از این جهت مهم است که کلاس Configuration به ازای Contextهای مختلف ایجاد شده، یک نام را خواهد داشت؛ اما در فضاهای نام متفاوتی قرار می‌گیرد.
با اجرای دستور add-migration، کدهای سی شارپ مورد نیاز جهت اعمال تغییرات بر روی ساختار بانک اطلاعاتی تولید می‌شوند. در مرحله بعد، این کدها تبدیل به دستورات SQL متناظری شده و بر روی بانک اطلاعاتی اجرا خواهند شد.
بدیهی است اگر دو Context در برنامه تعریف کرده باشید، دوبار باید دستور enable-migrations و دوبار دستور add-migration را با پارامترهای اشاره کننده به Conetxtهای مدنظر اجرا کرد.

ج) سپس برای اعمال این تغییرات، باید دستور update-database را اجرا کرد.
 update-database  -ConfigurationTypeName FullNameSpaceCtx1.Configuration
اینبار دستور update-database نیز بر اساس نام کامل کلاس Configuration مدنظر باید اجرا گردد و به ازای هر Context موجود، یکبار نیاز است اجرا گردد.
نهایتا اگر به بانک اطلاعاتی مراجعه کنید، تمام جداول و تعاریف را یکجا در همان بانک اطلاعاتی می‌توانید مشاهده نمائید.


داشتن چندین Context در برنامه و مدیریت تراکنش‌ها

در EF، هر DbContext معرف یک واحد کار است. یعنی تراکنش‌ها و چندین عمل متوالی مرتبط انجام شده، درون یک DbContext معنا پیدا می‌کنند. متد SaveChanges نیز بر همین اساس است که کلیه اعمال ردیابی شده در طی یک واحد کار را در طی یک تراکنش به بانک اطلاعاتی اعمال می‌کند. همچنین مباحثی مانند lazy loading نیز در طی یک Context مفهوم دارند. به علاوه دیگر امکان join نویسی بین دو Context وجود نخواهد داشت. باید اطلاعات را از یکی واکشی و سپس این اطلاعات درون حافظه‌ای را به دیگری ارسال کنید.

یک نکته
می‌توان یک DbSet را در چندین ‍Context تعریف کرد. یعنی اگر بحث join نویسی مطرح است، با تکرار تعریف DbSetها اینکار قابل انجام است اما این مساله اساس جداسازی Contextها را نیز زیر سؤال می‌برد.
 

داشتن چندین Context در برنامه و مدیریت رشته‌های اتصالی

در EF Code first روش‌های مختلفی برای تعریف رشته اتصالی به بانک اطلاعاتی وجود دارند. اگر تغییر خاصی در کلاس مشتق شده از DbContext ایجاد نکنیم، نام کلید رشته اتصالی تعریف شده در فایل کانفیگ باید به نام کامل کلاس Context برنامه اشاره کند. اما با داشتن چندین Context به ازای یک دیتابیس می‌توان از روش ذیل استفاده کرد:

  public class Ctx1 : DbContext
    {
        public Ctx1()
            : base("DefaultConnection")
        {
            //Database.Log = sql => Debug.Write(sql);
        }
    }

  public class Ctx2 : DbContext
    {
        public Ctx2()
            : base("DefaultConnection")
        {
            //Database.Log = sql => Debug.Write(sql);
        }
    }

  <connectionStrings>
    <add name="DefaultConnection" connectionString="…." providerName="System.Data.SqlClient" />
  </connectionStrings>
در اینجا در سازنده کلاس‌های Context تعریف شده، نام کلید رشته اتصالی موجود در فایل کانفیگ برنامه ذکر شده است. به این ترتیب این دو Context به یک بانک اطلاعاتی اشاره خواهند کرد.


چه زمانی بهتر است از چندین Context در برنامه استفاده کرد؟
عموما در طراحی‌های سازمانی SQL Server، تمام جداول از schema مدیریتی به نام dbo استفاده نمی‌کنند. جداول فروش از schema خاص خود و جداول کاربران از schema دیگری استفاده خواهند کرد. با استفاده از چندین Context می‌توان به ازای هر کدام از schemaهای متفاوت موجود، «یک ناحیه ایزوله» را ایجاد و مدیریت کرد.
  public class Ctx2 : DbContext
    {
        public Ctx2()
            : base("DefaultConnection")
        {
            //Database.Log = sql => Debug.Write(sql);
        }

         protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.HasDefaultSchema("sales");
            base.OnModelCreating(modelBuilder);
        }
    }
در این حالت در EF 6 می‌توان DefaultSchema کلی یک Context را در متد بازنویسی شده OnModelCreating به نحو فوق تعریف و مدیریت کرد. در این مثال به صورت خودکار کلیه DbSetهای Ctx2 از schema ایی به نام sales استفاده می‌کنند.
بازخوردهای دوره
انتقال خودکار Data Annotations از مدل‌ها به ViewModelهای ASP.NET MVC به کمک AutoMapper
همینطور هست. علت آن‌را در نظرات مطلب تزریق وابستگی‌های AutoMapper توضیح دادم:
«کاری که در اینجا انجام شده، ایجاد یک Mapping Engine سفارشی هست که با Mapping Engine اصلی استاتیک یکی نیست. به همین جهت برای نمونه متد Project آرگومان (Project(_mappingEngine هم دارد. اگر قید نشود، یعنی قرار است از موتور نگاشت استاتیک سراسری پیش فرض آن استفاده شود. »
در مثال فوق هم Mapper.Engine.ConfigurationProvider از همان موتور نگاشت استاتیک سراسری استفاده شده‌است (در متد Application_Start برنامه). این مورد را باید با یک وهله‌ی IConfigurationProvider تامین شده‌ی توسط IoC Container، جایگزین کنید؛ مثلا:
SmObjectFactory.Container.GetInstance<IConfigurationProvider>()
بازخوردهای دوره
تزریق وابستگی‌ها
- خیر. در حالت setter هم IoC Container (حین استفاده از ابزارهای متداول تزریق وابستگی‌ها) تمام وابستگی‌ها را در حین وهله سازی کلاس ایجاد می‌کند (چه استفاده شوند یا خیر؛ چون اگر اینکار را انجام ندهد استفاده کننده خطای null reference exception را حتما دریافت خواهد کرد. از این جهت که فقط در حالت استفاده از کلاس‌های Lazy است که یک محصور کننده، ارجاع واقعی به شیء را مدیریت می‌کند و به تاخیر می‌اندازد). در حالت به تاخیر افتاده، یک وابستگی فقط زمانی وهله سازی می‌شود که ارجاعی به آن در مسیر منطقی اجرای برنامه وجود داشته باشد؛ در غیراینصورت از وهله سازی آن وابستگی استفاده نشده، صرفنظر خواهد شد.
- برای آزمایش این مساله یک break point را در سازنده کلاس‌های مورد استفاده قرار دهید.
نظرات مطالب
EF Code First #12
مزیت این روش، استفاده از یک IoC Container برای مدیریت طول عمر DbContext در طول یک درخواست است.
در برنامه‌های وب، کار صرفا به یک کلیک ساده ختم نمی‌شود که در همان لحظه، یک Context آغاز و پایان یابد. در طی یک درخواست وب، قسمتی از صفحه لیست گروه‌ها، قسمتی دیگر لیست نویسندگان، قسمتی دیگر گزارش درصد استفاده از مرورگرها و قسمتی دیگر لیست آخرین مطالب را نمایش می‌دهد. تمام این‌ها هم در طی یک درخواست رخ می‌دهند و هرکدام، ماژول ماژول طراحی شده‌اند و از هم جدا.
اینجا است که ارزش استفاده از قابلیت‌های مدیریت طول عمر IoC containers برای به اشتراک گذاری یک DbContext در طی یک درخواست بهتر مشخص می‌شود. به این ترتیب می‌شود به سرباری کم و سرعتی بالا دست یافت چون مدام به ازای قسمت‌های مختلف برنامه Context ایجاد و تخریب نمی‌شود.
بازخوردهای دوره
استفاده از StructureMap به عنوان یک IoC Container
در انجمن آن بیشتر بحث شده؛ در اینجا
در نگارش بعدی، ObjectFactory استاتیک حذف می‌شود. بجای آن باید بنویسید:
var container = new Container(x => {
// تنظیمات در اینجا
});
و بعد مثلا:
var controller = container.GetInstance(controllerType) as SomeType;
در جاهائیکه مستقیما با ObjectFactory کار می‌کردید، بهتر است IContainer آن‌را مورد استفاده قرار دهید:
public class MyController
{
    public MyController(IContainer container)
    {
    }
}
نظرات مطالب
تزریق مستقیم وابستگی‌ها در Action Method ها و Handler Method های ASP.NET Core
بهتر است سه قسمت اول مرتبط با دوره «بررسی مفاهیم معکوس سازی وابستگی‌ها و ابزارهای مرتبط با آن» را مطالعه کنید.
1) Dependency inversion principle یا DIP (اصل معکوس سازی وابستگی‌ها)
DIP یکی از اصول طراحی نرم افزار است و D آن همان D معروف SOLID است (اصول پذیرفته شده شیءگرایی).
2) Inversion of Control یا IOC (معکوس سازی کنترل)
الگویی است که نحوه پیاده سازی DIP را بیان می‌کند.
3) Dependency injection یا DI (تزریق وابستگی‌ها)
یکی از روش‌های پیاده سازی IOC است.
4) IOC container
به فریم ورک‌هایی که کار DI را انجام می‌دهند گفته می‌شود.