وحید نصیری وحید نصیری
مطالب
سازماندهی برنامه‌های Angular توسط ماژول‌ها
یک برنامه‌ی Angular، از گروهی از کامپوننت‌ها تشکیل می‌شود؛ برای مثال یک کامپوننت App وجود دارد که آن نیز از تعدادی کامپوننت مختلف تشکیل می‌شود. ماژول‌ها کار سازماندهی و بسته بندی این کامپوننت‌ها را انجام می‌دهند و با بزرگتر شدن برنامه می‌توان قسمت‌های مختلف را در ماژول‌های متفاوتی قرار داد. مزایای این روش به شرح زیر هستند:
- بهبود کپسوله سازی قسمت‌های مختلف برنامه با بسته بندی آن‌ها در ماژول‌های متفاوت
- فراهم آوردن امکان lazy loading و بهبود کارآیی برنامه


انواع ماژول‌های توصیه شده‌ی در برنامه‌های Angular

منهای App Module پیش‌فرض یک برنامه‌های Angular، ایجاد سه نوع ماژول دیگر نیز در جهت سازماندهی اینگونه برنامه‌ها توصیه می‌شوند:
- Core Module
هدف از آن فراهم آوردن سرویس‌های Singleton اشتراکی بین کامپوننت‌ها و ماژول‌های مختلف برنامه است. علت این‌جا است که سیستم تزریق وابستگی‌های Angular، به ازای هر ماژولی که Lazy loaded باشد، سرویس تزریقی در آن‌ها را مجددا وهله سازی می‌کند. به همین جهت نیاز است تک ماژول اختصاصی را برای مدیریت سرویس‌هایی که نیازی است تنها یکبار در طول عمر برنامه وهله سازی شوند، تدارک ببینیم و Core Module مکان مناسبی برای این‌کار است.
همچنین Code Module باید شامل کامپوننت‌هایی در سطح برنامه باشد. دراینجا منظور از «در سطح برنامه»، کامپوننت‌هایی که قرار است در بین تمام ماژول‌ها به اشتراک گذاشته شوند، نیست. منظور تنها کامپوننت‌هایی هستند که در App Component اصلی برنامه قرار است استفاده شوند؛ مانند منوی راهبری بالای سایت.

- Shared Module
هدف از آن مدیریت و بسته بندی کامپوننت‌ها، دایرکتیوها و Pipes اشتراکی بین تمام اجزای برنامه است. برای مثال کامپوننت «لطفا منتظر بمانید ...» اگر قرار است در تمام قسمت‌های برنامه استفاده شود، نیاز است در Shared Module تعریف شود. از این جهت که در یک برنامه‌ی Angular نمی‌توان یک کامپوننت را بین دو ماژول مختلف به اشتراک گذاشت. به همین جهت نیاز است یک مکان مرکزی برای تعریف این کامپوننت‌های اشتراکی ایجاد شود و سپس این تک ماژول را در قسمت‌های مختلف برنامه، بدون مشکل مورد استفاده قرار داد.

- Feature Module
این ماژول‌ها به ازای هر ویژگی برنامه ایجاد شده و کامپوننت‌ها، سرویس‌ها، دایرکتیوها و Pipes اختصاصی آن ویژگی را بسته بندی می‌کنند.


ایجاد Core Module

فرض کنید می‌خواهید اطلاعات کاربر جاری لاگین شده را در طول عمر برنامه نگهداری کنید و از آن در تمام قسمت‌های برنامه استفاده نمائید. یک چنین سرویسی نیاز است دارای طول عمر Singleton باشد و تنها یکبار وهله سازی شود تا اطلاعات کاربر جاری از دست نرود. به همین جهت بهترین مکان تعریف این سرویس، در Core Module است.
برای این منظور در ساختار برنامه‌ی خود، پوشه‌ی جدید src\app\core را ایجاد می‌کنیم. سپس فایل core.module.ts را به صورت ذیل در آن تعریف خواهیم کرد:
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';

import { UserRepositoryService } from './user-repository.service';
import { NavBarComponent } from './nav-bar.component';
import { AccountMenuComponent } from './account-menu.component';

@NgModule({
  imports: [ CommonModule, RouterModule ],
  exports: [ NavBarComponent, AccountMenuComponent ],
  declarations: [ NavBarComponent, AccountMenuComponent ],
  providers: [ UserRepositoryService ]
})
export class CoreModule { };
 - CoreModule در ابتدا تنها CommonModule و RouterModule را در صورت نیاز import می‌کند.
 - سپس سرویس‌های اشتراکی و Singleton برنامه در قسمت providers آن قرار می‌گیرند.
 - در اینجا همچنین دو کامپوننت منو که توسط app.component.ts مورد استفاده قرار می‌گیرند نیز import شده‌اند.
 - فایل‌های account-menu.component.ts، nav-bar.component.ts و user-repository.service.ts نیز به درون پوشه‌ی src\app\core منتقل خواهند شد (به همراه تمام فایل‌های html و css متناظر با آن‌ها).
 - اگر دقت کنید، قسمت exports این ماژول نیز مقدار دهی شده‌است. چون این کامپوننت‌ها قرار است خارج از این ماژول و در AppModule استفاده شوند، نیاز است آن‌ها را به صورت خروجی نیز معرفی کنیم.

اکنون جهت استفاده‌ی از این قابلیت‌ها، تنها کافی است تعریف CoreModule را به AppModule در فایل app.module.ts اضافه کنیم:
import { CoreModule } from "./core/core.module";

@NgModule({
  imports:      [
//...
    CoreModule,
//...
    RouterModule.forRoot(appRoutes)
  ],
//...
})
export class AppModule { }


ایجاد Shared Modules

در Shared Module اجزایی را قرار خواهیم داد که قرار است در بیش از یک ماژول مورد استفاده قرار گیرند. به همین جهت در ساختار برنامه‌ی خود، پوشه‌ی جدید src\app\shared را ایجاد می‌کنیم. سپس در آن، ماژول جدید shared.module.ts را ایجاد خواهیم کرد:
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

import { LoadingSpinnerComponent } from './loading-spinner.component';

@NgModule({
  imports: [ CommonModule ],
  declarations: [ LoadingSpinnerComponent ],
  exports: [ LoadingSpinnerComponent, CommonModule ],
  providers: [ ]
})
export class SharedModule { };
ساختار این ماژول نیز شبیه به Core Module است. ابتدای CommonModule به آن import شده‌است. سپس کامپوننت‌هایی که قرار است در بین سایر ماژول‌های سایت به اشتراک گذاشته شوند (برای مثال یک کامپوننت Loading Spinner فرضی)، در هر دو قسمت declarations و exports این ماژول اشتراکی قرار می‌گیرند. همچنین فایل loading-spinner.component.ts و تمام اجزای وابسته‌ی به آن نیز به پوشه‌ی src\app\shared منتقل می‌شوند.
از این جهت که اجزای خروجی این ماژول قرار است در Feature Moduleها استفاده شوند، CommonModule مورد استفاده‌ی در آن‌ها نیز در قسمت exports ذکر شده‌است.

اکنون جهت استفاده‌ی از این قابلیت‌ها، تنها کافی است تعریف SharedModule را به AppModule در فایل app.module.ts اضافه کنیم:
import { CoreModule } from "./core/core.module";
import { SharedModule } from "./shared/shared.module";

@NgModule({
  imports:      [
//...
    CoreModule,
    SharedModule,
//...
    RouterModule.forRoot(appRoutes)
  ],
//...
})
export class AppModule { }


ایجاد Feature Modules

این مورد نکته‌ی ویژه‌ای را به همراه ندارد و همانند ایجاد سایر ماژول‌های برنامه‌است. برای مثال ویژگی مدیریت کاربران، به همراه تمام اجزای آن درون ماژول کاربران قرار می‌گیرد و به همین ترتیب برای سایر ویژگی‌های دیگر برنامه. ایجاد و مدیریت اینگونه ماژول‌ها توسط Angular CLI بسیار ساده‌است:
> ng g m users -m app.module --routing
> ng g c users/users-list
دستور اول ایجاد ماژول جدید users، پوشه‌ی مرتبط با آن و همچنین به روز رسانی فایل app.module را به صورت خودکار انجام می‌دهد.
دستور دوم نیز کامپوننتی را به این ماژول اضافه می‌کند؛ به همراه به روز رسانی تعاریف این ماژول.

فقط در اینجا SharedModule ایی را که پیشتر اضافه کردیم، به قسمت imports آن اضافه می‌کنیم:
import { NgModule } from '@angular/core';
import { RouterModule } from '@angular/router';

import { SharedModule } from '../shared/shared.module';
import { UsersListComponent } from './users-list.component';

@NgModule({
  imports: [ RouterModule, SharedModule ],
  declarations: [ UsersListComponent ],
  exports: [  ],
  providers: [ ]
})
export class UsersModule { };
‫۶ سال و ۱۱ ماه قبل، یکشنبه ۷ آبان ۱۳۹۶، ساعت ۱۵:۵۰
وحید محمدطاهری وحید محمدطاهری
مسیرراه‌ها
ASP.NET Web API
        ‫۹ سال و ۱۱ ماه قبل، شنبه ۲۴ آبان ۱۳۹۳، ساعت ۱۵:۴۷
        وحید نصیری وحید نصیری
        مطالب
        کاهش حجم قابل ملاحظه‌ی برنامه‌های Angular با استفاده از RxJS 5.5
        Angular 5.x به همراه پشتیبانی از RxJS 5.5.x منتشر شده‌است. RxJS 5.5 نیز به همراه تغییر قابل ملاحظه‌ای در نحوه‌ی import اجزای آن توسط ویژگی جدید lettable operators است. در این مطلب نحوه‌ی ارتقاء برنامه‌های قبلی به این نگارش جدید و همچنین اثر آن‌را بر اندازه‌ی برنامه‌ی نهایی تولید شده، بررسی می‌کنیم.


        روش جدید import اجزای RxJS در نگارش 5.5 آن

        تغییرات تعاریف عملگرها:
        تا پیش از Angular 5 و RxJS 5.5 (و یا Angular CLI versions <1.5.0)، اگر نیاز به عملگری (operator/function) مانند map وجود داشت، روش import آن به صورت زیر بود:
        import 'rxjs/add/operator/map';
        اما پس از RxJS 5.5 امکان import آن‌ها با روش مخصوص ES 6 میسر شده‌است (به نام جمع operators دقت داشته باشید؛ چون مسیر rxjs/observable نیز وجود دارد):
        import { map } from 'rxjs/operators';
        بنابراین در این حالت دیگر روش import یکجای این تعاریف در فایلی مانند «rxjs-operators.ts» وجود ندارد و این تعاریف باید به ازای هر فایلی که از آن‌ها استفاده می‌کنند، مانند سایر importهای ES 6 یکبار دیگر مجددا ذکر شوند؛ مانند:
        import { map, catchError, tap } from 'rxjs/operators';
        در حالت کلی مسیر node_modules/rxjs/operators را برای یافتن متدهای جدید بررسی کنید.

        همچنین در این نگارش، Observable بجای rxjs/Rx :
        import { Observable } from 'rxjs/Rx';
        از rxjs/Observable دریافت می‌شود:
        import { Observable } from 'rxjs/Observable';
        تا بتوان از قابلیت‌های جدید آن استفاده کرد.

        تغییرات تعاریف statics:
        برای صدور خطاها بجای throw قبلی:
        import 'rxjs/add/observable/throw';

Observable.throw('error');
        خواهیم داشت:
        import { ErrorObservable } from 'rxjs/observable/ErrorObservable';

ErrorObservable.create('error');

        و برای ایجاد تایمر، بجای timer پیشین:
        import "rxjs/add/observable/timer";

const timerSource$ = Observable.timer(initialDelay);
        خواهیم داشت:
        import { timer } from 'rxjs/observable/timer';  

const timerSource$ = timer(initialDelay);
        و به طور کلی مسیر node_modules\rxjs\observable را برای یافتن تعاریف static قبلی جستجو کنید.


        معرفی lettable operators

        Lettable Operators توابعی هستند که یک observable را دریافت و یک observable را بازگشت می‌دهند؛ به آن‌ها pipeable operators هم می‌گویند. از این جهت که در اینجا متد جدید pipe، برای ترکیب چندین تابع عملگر بر روی مقادیر observable توسط آن، ارائه شده‌است.
        مزیت این روش این است که pipeable/lettable operators، یک سری تابع محض هستند و اگر مورد استفاده قرار نگیرند، به سادگی توسط سیستم و ابزار ساخت برنامه، از فایل نهایی حذف خواهند شد؛ یا اصطلاحا tree-shakable هست. اما روش پیشین تعریف این عملگرها، tree-shakable نبوده و حتی اگر توسط برنامه مورد استفاده قرار نگیرند، در بسته‌ی نهایی تولید شده، حضور خواهند داشت. Tree-shaking به معنای پروسه‌ی حذف کدهای مرده است. روش جدید استفاده‌ی از importهای ES 6، امکان تشخیص عملگرهای استفاده نشده را توسط ابزارهایی مانند TS-Lint و تنظیمات کامپایلر TypeScript به سادگی میسر می‌کنند و به این ترتیب با حذف متدها و ماژول‌های استفاده نشده، می‌توان به حجم نهایی بسیار کمتری رسید.


        روش قبلی تعریف عملگرهای Observable، اصطلاحا Patching نامیده می‌شود. به این معنا که هر متد جدید import شده‌ی در برنامه، به Observable.prototype اصلی اضافه و وصله می‌شود. اما در این روش جدید، تنها متد وصله شده‌ی از پیش موجود، Observable.prototype.pipe است و تمام متدهای دیگر import شده، توابع محض هستند و نه وصله‌ای به Observable.prototype اصلی. زمانیکه وصله‌ای به Observable.prototype متصل می‌شود، دیگر امکان حذف آن توسط ابزارهای ساخت برنامه وجود ندارد (حتی اگر استفاده نشده باشند)؛ اما اگر این متدها به صورت خالص و مجزای از Observable.prototype ارائه شوند، امکان حذف کدهای مرده و استفاده نشده، به سادگی میسر خواهد شد؛ چون توابعی خالص و متکی به خود هستند.

        یک نمونه مثال استفاده‌ی از pipeable/lettable operators را در کد زیر مشاهده می‌کنید:
        import { from} from 'rxjs/observable/from';
import { map, scan, filter } from 'rxjs/operators';

const source$ = range(1,10);

const sumOfSquaredOddNumbers$ = source$.pipe(
   filter(n => n % 2 !== 0), 
   map(n => n * n),
   scan((acc,s) => acc + s, 0)
);
sumOfSquaredOddNumbers$.subscribe(v => console.log(v));

/*** Output ****/ 
1
10
35
84
165
        این مثال، جمع به توان 2 اعداد را در یک بازه‌ی مشخص، محاسبه می‌کند. برای این منظور ابتدا یک منبع Observable توسط متد range ایجاد شده‌است.
        در اینجا روش تعریف Observableها نیز تغییر کرده‌است و از متد of جهت کار با تعدادی ورودی مشخص و یا متد range برای کار با بازه‌ای از اعداد، استفاده می‌شود:
        import { of } from 'rxjs/observable/of';
import { from } from 'rxjs/observable/from';
import { range } from 'rxjs/observable/range';

const source$ = of(1,2,3);
const rangeSource$ = range(0,5);
        سپس توسط متد pipe، ترکیبی از متدهای RxJS را مشاهده می‌کند که بر روی منبع Observable اصلی کار می‌کنند.
        متد filter، اعداد فرد بازه را انتخاب می‌کند. متد map این اعداد انتخابی را به توان 2 می‌رساند و سپس متد scan آن‌ها را با هم جمع می‌زند و نتیجه توسط متد pipe به صورت یک Observable دیگر بازگشت داده می‌شود که می‌توان مشترک آن شد و برای مثال خروجی فوق را در console درج کرد.


        تغییر نام عملگرهای قبلی RxJS

        تا اینجا دریافتیم که هدف اصلی pipeable/lettable operators، عدم معرفی آن‌ها به صورت یک وصله‌ی جدید جدانشدنی از Observable.prototype، به صورت توابع خالص است. اکنون که این عملگرها، تبدیل به متدهای خالص و متکی به خود شده‌اند، نباید با متدهای اصلی جاوا اسکریپت تداخل نام پیدا کنند؛ به همین جهت برای ارتقاء کدهای قدیمی خود، به این تغییر نام‌ها نیاز خواهید داشت: متد do به tap تغییر نام یافته‌است. متد switch شده‌است switchAll. بجای catch اینبار catchError داریم و finally شده‌است finalize.


        مثالی از ارتقاء کدهای قدیمی به روش جدید RxJS 5.5

        اگر مثال روش قدیمی مبتنی بر وصله کردن Observable.prototype، به صورت زیر باشد:
        import { Observable } from 'rxjs/Observable';
import 'rxjs/add/operator/map';
import 'rxjs/add/operator/filter';

names = allUserData.
         map(user => user.name).
         filter(name => name);
        معادل جدید آن به این صورت تغییر می‌کند:
        import { Observable } from 'rxjs/Observable';
import { map, filter } from 'rxjs/operators';

names = allUserData.pipe(
   map(user => user.name),
   filter(name => name),
);
        زمانیکه تعریف Observable از مسیر rxjs/Observable درخواست می‌شود، به همراه عملگر وصله شده‌ی pipe نیز هست. به همین جهت نیازی به تعریف مجدد آن نیست. پس از آن متدهای map و filter، به داخل pipe منتقل می‌شوند. در این بین نیاز است تغییر نام متدها را که پیشتر نیز ذکر شد، مدنظر داشته باشید.
        به عنوان یک مثال تکمیلی، کدهای سری «احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular» جهت استفاده‌ی از pipeable/lettable operators به روز رسانی شده‌اند. لیست تغییرات آن‌ها را در اینجا می‌توانید مشاهده کنید.
        ‫۶ سال و ۸ ماه قبل، سه‌شنبه ۱۷ بهمن ۱۳۹۶، ساعت ۱۷:۵۰
        علی تنها علی تنها
        مطالب
        مقایسه پروژه های Web Site و Web Application در Visual Studio
         در ویژوال استودیو می‌توانید پروژه‌ی Web Application و یا Web Site ایجاد نمایید. شما Web Application را با گزینه‌ی New Project ایجاد و با Open Project باز می‌کنید؛ ولی Web Site را با گزینه‌ی New Web Site ایجاد و با Open Web Site باز می‌نمایید. قبل از ساخت یک پروژه‌ی جدید وب لازم است از تفاوت‌های این دو نوع، آگاهی کسب کرده و در انتخاب نوع پروژه دقت نمایید؛ چرا که تغییر و تبدیل یک نوع به نوع دیگر، علاوه بر سختی، موجب اتلاف زمان شده و پروژه را مستعد خطا خواهد کرد.

        نکته:
        برای ایجاد یک پروژه‌ی جدید مایکروسافت Web Application را به شما پیشنهاد می‌دهد. هرچند در این مبحث، مطالبی را مبنی بر فواید Web Site معرفی خواهد کرد، ولی اکثر توسعه دهندگان وب که Web Site را برگزیده اند سرانجام مضراتی از آن را می‌یابند که سنگینی آن بیشتر از فوایدش است. برای مثال تمامی خصیصه‌های (feature فیچر) ASP.net لزومآ برای وب سایت در دسترس نخواهند بود؛ مثلآ از ویژوال استودیوی 2012 به بعد، ابزاری برای تولید پروژه‌های وب وجود دارد که فقط برای Web Application در اختیار خواهد بود (برای کسب اطلاعات بیشتر می‌توانید مطلب Creating an ASP.net Web Project in Visual Studio  را مطالعه نمایید). 

        سناریو :

        سناریویی که مبنی برا انتخاب Web Application می‌باشد به شرح زیر است:
        · شما نیاز به استفاده از Edit And Continue در دیباگر ویژوال استودیو دارید.
        · تمامی کدها، فایل‌ها و کلاس‌هایی که با صفحات ASP.net مرتبط هستند، برای تست بصورت واحد و یکپارچه در نظر گرفته می‌شوند.
        · شما برای کلاس‌هایی که وابسته به صفحات هستند و همچنین برای کنترل‌ها و کلاس‌های منحصر آن باید ارجاع داشته باشید.
        · وابستگی در حالتی که چندین پروژه‌ی مرتبط به هم را دارید توسط شما مشخص می‌شود.
        · برای کل سایت در هنگام کامپایل فقط یک اسمبلی ساخته می‌شود.
        · کنترل نام اسمبلی‌ها و همچنین شمارهی ورژن ایجاد شده‌ی برای پروژه در دست شماست.
        · برای کامپایل پروژه می‌توانید MSBuild و یا Team Build را انتخاب کنید؛ برای مثال می‌توانید مراحل Prebuild یا Postbuild را مشخص کنید.
        · نیازی به قرار دادن سورس برنامه روی سرور نیست.

        سناریویی که مبنی برا انتخاب Web Site می‌باشد به شرح زیر است:
        · یک پروژه در بر دارنده‌ی  کدهای #C و هم کدهای Visual Basic می‌باشد ( درحالیکه بصورت پیشفرض در Web Application فایل پروژه بر مبنای زبان برنامه‌ی شما کامپایل می‌شود، هرچند می‌توان این حالت پیشفرض را تغییر داد؛ ولی این امر می‌تواند اندکی مشکل باشد).
        · شما می‌توانید سایت ایجاد شده را بصورت Real Time توسط FTP  باز نموده و آپدیت نمایید.
        · برای توزیع (deploy) پروژه مجبور به کامپایل صریح آن نیستید.
        · اگر پروژه را کامپایل نمایید کامپایلر به ازای هر صفحه و یا هر پوشه، یک فایل اسمبلی جداگانه خواهد ساخت.
        · برای تغییر یک فایل به تنهایی می‌توانید فقط آنرا تغییر داده و بر روی سرور قرار دهید.
        · حتی بعد از کامپایل هم می‌توانید صفحات ASP.net  را بدون نیاز به کامپایل دوباره‌ی کل سایت تغییر داده و جایگزین نمایید.
        · سورس کامل پروژه برای اجرا باید روی سرور قرار گیرد.

        تفاوت‌ها در یک نگاه:

        زمینه 
        		  پروژه‌های Web Application     پروژه‌های Web Site 
          ساختار فایل پروژه    فایل برنامه (.csproj / vbproj) دربردارنده اطلاعاتی از جمله لیست فایل‌ها و رفرنس‌ها پروژه به پروژه دیگر خواهد بود.    هیچ فایل برنامه ای وجود ندارد و تمامی فایل هایی که داخل پوشه می‌باشند جزو فایل‌های سایت شناخته می‌شوند. 
          کامپایل  · شما پروژه را در سیستم خود کامپایل می‌کنید.
        · بصورت پیشفرض کامپایل کد‌ها در یک اسمبلی قرار می‌گیرد. 
        		  · سورس کدها بصورت اتوماتیک در سرور توسط Asp.net  با اولین درخواست کامپایل میشوند.
        (البته شما می‌توانید کامپایل را در سیستم خود نیز انجام دهید)
        · بصورت پیشفرض کامپایل برای هر کلاس یک اسمبلی جدا می‌سازد. 
        فضا‌های نام  Namespace‌ها بصورت صریح در صفحات و کلاس‌ها و کنترل‌ها افزوده می‌شود.  هیچ namespace ای بصورت پیشفرض اضافه نمی‌شود (شما می‌توانید بصورت دستی آنها را اضافه کنید) 
        توزیع
        		 اسمبلی تولید شده در مرحله کامپایل را روی سرور قرار می‌دهید
        اکثر مراحل کامپایل توسط ابزارهای ارائه شده ویژوال استودیو انجام می‌شود. 
        		کل سورس پروژه روی سرور قرار میگیرد.
        اکثر مراحل کامپایل توسط ابزارهای ارائه شده ویژوال استودیو انجام می‌شود. 

        ساختار فایل پروژه:
        پروژه‌های Web Application از فایل پروژه ویژوال استودیو ( .csproj / .vbproj ) برای نگهداری اطلاعات پروژه استفاده می‌کنند. با این امکان می‌توان فایل‌هایی را که در پروژه دخیل هستند و یا باید کامپایل شوند، به تفکیک مشخص کرد.
        در مورد Web Site تمامی فایل‌هایی که در داخل پوشه‌ی برنامه قرار دارند، به صورت پیش فرض جزیی از برنامه تلقی شده و کامپایل خواهند شد و برای اینکه فایلی را بخواهید مستثنا کنید یا باید آنرا حذف کنید و یا پسوند آنرا به نامی که توسط سرور IIS قابل شناسایی نیست تغییر دهید.

        فایده‌ی فایل پروژه یعنی همان ( .csproj / .vbproj ) در Web Application :
        می‌توان فایلی را به طور موقت از برنامه حذف کرد، بدون نگرانی از آنکه فایل بصورت کلی حذف شود. چرا که فایل در ساختار برنامه باقیست. برای مثال اگر صفحه‌ای برای توزیع آماده نیست، می‌توانید به راحتی آن‌را از برنامه خارج کنید ( Exclude ) و برنامه را کامپایل نمایید و بعد از اینکه این صفحه هم آماده شد، دوباره آن را وارد پروژه نمایید ( include ) که اهمیت این امر در مواردی که از برنامه‌های کنترل سورس استفاده می‌کنید، دوچندان می‌شود.

        فایده‌ی عدم استفاده از فایل پروژه‌ی برنامه در Web Site :
        شما مجبور به کنترل و شخصی سازی ساختار فایل برنامه در ویژوال استودیو نیستید و به راحتی هر فایل یا صفحه‌ای را که می‌خواهید، با کپی کردن به پوشه و یا حذف کردن از آن توسط فایل اکسپلورر انجام می‌دهید.

        کامپایل:
        برای برنامه‌های Web Application شما بصورت معمول پروژه را Build می‌نمایید و تمامی کد‌های صفحات و همچنین کلاس‌ها به صورت یک فایل اسمبلی در پوشه‌ی bin ذخیره می‌گردد.
        برای Web Site شما مجبور به کامپایل دستی پروژه نیستید و می‌توانید از Batch-Compile استفاده کنید و همچنین به ازای هر صفحه و کلاسریال شما یک فایل اسمبلی خواهید داشت.

        مزایای کامپایل در Web Application :
        · می‌توانید از MSBuild استفاده کنید.
        · می‌توانید خصیصه‌های اسمبلی، از جمله نام و ورژن را به راحتی مدیریت نمایید.
        · کامپایل قبل از توزیع برنامه این مزیت را دارد که کاربران مجبور نیستند منتظر کامپایل برنامه در سرور باشند.
        · مدیریت دقیقی بر روی فایل‌ها و ساختار برنامه و همچنین کلاس‌ها و ارجاعات خواهید داشت.

        مزایای کامپایل در Web Site  :
        · می‌توانید هر صفحه‌ای را که نیاز دارید بدون در نظر گرفتن آماده شدن دیگر صفحات تست و اجرا نمایید.
        · آپدیت و جایگزینی فایل‌ها به راحتی صورت می‌گیرد؛ چرا که اسمبلی تمام فایل‌ها بصورت منحصر همان صفحه ایجاد خواهد شد.
        · ایجاد شدن چند اسمبلی می‌تواند در برخی پروژه‌ها به نفع برنامه بوده و performance  را بالا ببرد. برای مثال در حالتیکه یک سایت با صفحات زیاد دارید و برخی صفحات به نسبت دیگر صفحات خیلی کمتر درخواست می‌شوند.

        نکته:
        هیچ فرقی بین Web Application ,  و web Site از نظر performance  وجود ندارد مگر درحالت ذکر شده در بالا و در سایت‌های خیلی بزرگ.

        توزیع : ( Deployment )
        در web Site کل فایل‌های پروژه را بر روی سرور قرار می‌دهید؛ درحالی که در Web Application  فایل‌های برنامه بصورت اسمبلی‌ها ( .dll ) روی سرور قرار می‌گیرند. همین امر می‌تواند در برخی حالت‌ها مثلآ زمانی که از هاست share شده استفاده می‌کنید، خیال شما را از بابت سورس برنامه مطمئن سازد.
        برای Web Site نیز این مزیت وجود دارد که برای انجام تغییرات کوچک مجبور به کامپایل و آپلود دوباره‌ی کل پروژه نیستید.


        ماخذ

         
        ‫۸ سال و ۱۱ ماه قبل، جمعه ۱۳ آذر ۱۳۹۴، ساعت ۲۲:۵۵
        وحید نصیری وحید نصیری
        مطالب
        مدیریت پیشرفته‌ی حالت در React با Redux و Mobx - قسمت اول - Redux چیست؟
        Redux و Mobx، کتابخانه‌های کمکی هستند برای مدیریت حالت برنامه‌های پیچیده‌ی React. هرچند React به صورت توکار به همراه امکانات مدیریت حالت است، اما این کتابخانه‌ها مزایای ویژه‌ای را به آن اضافه می‌کنند. در این سری ابتدا کتابخانه‌ی Redux را به صورت خالص و مجزای از React بررسی می‌کنیم. از این کتابخانه در برنامه‌های Angular و Ember هم می‌توان استفاده کرد و به صورت اختصاصی برای React طراحی نشده‌است. سپس آن‌را به برنامه‌های React متصل می‌کنیم. در آخر کتابخانه‌ی محبوب دیگری را به نام Mobx بررسی می‌کنیم که برای مدیریت حالت، اصول برنامه نویسی شیءگرا و همچنین Reactive را با هم ترکیب می‌کند و این روزها در برنامه‌های React، بیشتر از Redux مورد استفاده قرار می‌گیرد.


        چرا به ابزارهای مدیریت حالت نیاز داریم؟

        به محض رد شدن از مرز پیاده سازی امکانات اولیه‌ی یک برنامه، نیاز به ابزارهای مدیریت حالت نمایان می‌شوند؛ خصوصا زمانیکه نیاز است با اطلاعات قابل توجهی سر و کار داشت. مهم‌ترین دلیل استفاده‌ی از یک ابزار مدیریت حالت، مدیریت منطق تجاری برنامه است. منطق نمایشی برنامه مرتبط است به نحوه‌ی نمایش اجزای آن در صفحه؛ مانند نمایش یک صفحه‌ی مودال، تغییر رنگ عناصر با عبور کرسر ماوس از روی آن‌ها و در کل منطقی که مرتبط و یا وابسته‌ی به هدف اصلی برنامه نیست. از سوی دیگر منطق تجاری برنامه مرتبط است با مدیریت، تغییر و ذخیره سازی اشیاء تجاری مورد نیاز آن؛ مانند اطلاعات حساب کاربری شخص و دریافت اطلاعات برنامه از یک API که مختص به برنامه‌ی خاص ما است و به همین دلیل نیاز به ابزاری برای مدیریت بهینه‌ی آن وجود دارد. برای مثال اینکه در کجا باید منطق تجاری و نمایشی را به هم متصل کرد، می‌تواند چالش بر انگیر باشد. چگونه باید اطلاعات کاربر را ذخیره کرد؟ چگونه React باید متوجه شود که اطلاعات ما تغییر کرده‌است و در نتیجه‌ی آن کامپوننتی را مجددا رندر کند؟ یک ابزار مدیریت حالت، تمام این مسایل را به نحو یک‌دستی در سراسر برنامه، مدیریت می‌کند.
        اگر از یک ابزار مدیریت حالت استفاده نکنیم، مجبور خواهیم شد تمام اطلاعات منطق تجاری را در داخل state کامپوننت‌ها ذخیره کنیم که توصیه نمی‌شود؛ چون مقیاس پذیر نیست. برای مثال فرض کنید قرار است تمام اطلاعات state را داخل یک کامپوننت ذخیره کنیم. هر زمانیکه بخواهیم این state را از طریق یک کامپوننت فرزند تغییر دهیم، نیاز خواهد بود این اطلاعات را به والد آن کامپوننت ارسال کنیم که اگر از تعداد زیادی کامپوننت تو در تو تشکیل شده باشد، زمانبر و به همراه کدهای تکراری زیادی خواهد بود. همچنین اینکار سبب رندر مجدد کل برنامه با هر تغییری در state آن می‌شود که غیرضروری بوده و کارآیی برنامه را کاهش می‌دهد. به علاوه در این بین مشخص نیست هر قسمت از state، از کدام کامپوننت تامین شده‌است. به همین جهت نیاز به روشی برای مدیریت حالت در بین کامپوننت‌های برنامه وجود دارد.


        داشتن تنها یک محل برای ذخیره سازی state در برنامه

        همانطور که در قسمت 8 ترکیب کامپوننت‌ها در سری React 16x بررسی کردیم، هر کامپوننت در React، دارای state خاص خودش است و این state از سایر کامپوننت‌ها کاملا مستقل و ایزوله‌است. این مورد با بزرگ‌تر شدن برنامه و برقراری ارتباط بین کامپوننت‌ها، مشکل ایجاد می‌کند. برای مثال اگر بخواهیم دکمه‌ای را در صفحه قرار داده و توسط این دکمه درخواست صفر شدن مقدار هر کدام از شمارشگرها را صادر کنیم، با صفر کردن value هر کدام از این کامپوننت‌ها، اتفاقی رخ نمی‌دهد. چون state محلی این کامپوننت‌ها، با سایر اجزای صفحه به اشتراک گذاشته نمی‌شود و باید آن‌را تبدیل به یک controlled component کرد، بطوریکه دارای local state خاص خودش نیست و تمام داده‌های دریافتی را از طریق this.props دریافت می‌کند و هر زمانیکه قرار است داده‌ای تغییر کند، رخ‌دادی را به والد خود صادر می‌کند. بنابراین این کامپوننت به طور کامل توسط والد آن کنترل می‌شود. تازه این روش در مورد کامپوننت‌هایی صدق می‌کند که رابطه‌ی والد و فرزندی بین آن‌ها وجود دارد. اگر چنین رابطه‌ای وجود نداشت، باید state را به یک سطح بالاتر انتقال داد. برای مثال باید state کامپوننت Counters را به والد آن که کامپوننت App است، منتقل کرد. پس از آن چون کامپوننت‌های ما، از کامپوننت App مشتق می‌شوند، اکنون می‌توان این state را به تمام فرزندان App توسط props منتقل کرد و به اشتراک گذاشت. این مورد هم مانند مثال انتقال اطلاعات کاربر لاگین شده‌ی به سیستم، به تمام زیر قسمت‌های برنامه، نیاز به ارسال اطلاعات از طریق props یک کامپوننت، به کامپوننت بعدی را دارد و به همین ترتیب برای مابقی که به props drilling مشهور است و روش پسندیده‌ای نیست.


        Redux چیست؟ ذخیره سازی کل درخت state یک برنامه، در یک محل. به این ترتیب به یک شیء جاوا اسکریپتی بزرگ خواهیم رسید که در برگیرنده‌ی تمام state برنامه‌است. یکی از مزایای آن امکان serialize و deserialize کل این شیء، به سادگی است. برای مثال توسط متد JSON.stringify می‌توان آن‌را در جائی ذخیره کرد و سپس آن‌را به صورت یک شیء جاو اسکریپتی در زمانی دیگر بازیابی کرد. یکی از مزایای آن، امکان بازیابی دقیق شرایط کاربری است که دچار مشکل شده‌است و سپس دیباگ و رفع مشکل او، در زمانی دیگر.


        تاریخچه‌ای از سیستم‌های مدیریت حالت

        همه چیز با AngularJS 1x شروع شد که از data binding دو طرفه پشتیبانی می‌کرد. هرچند این روش برای همگام نگه داشتن View و مدل برنامه، مفید است، اما در Viewهای پیچیده، برنامه را کند می‌کند. در همین زمان فیس‌بوک، روش مدیریت حالتی را به نام Flux ارائه داد که از data binding یک طرفه پشتیبانی می‌کرد. به این معنا که در این روش، همواره اطلاعات از View به مدل، جریان پیدا می‌کند. کار کردن با آن ساده‌است؛ چون نیازی نیست حدس زده شود که اکنون جریان اطلاعات از کدام سمت است. اما مشکل آن عدم هماهنگی model و view، در بعضی از حالات است. Flux از این جهت به وجود آمد که مدیریت حالت در برنامه‌های React آن زمان، پیچیده بود و مقیاس پذیری کمی داشت (پیش از ارائه‌ی Context و Hooks). در کل Flux صرفا یکسری الگوی مدیریت حالت را بیان می‌کند و یک کتابخانه‌ی مجزا نیست. بر مبنای این الگوها و قراردادها، می‌توان کتابخانه‌های مختلفی را ایجاد کرد. از این رو در سال 2015، کتابخانه‌های زیادی مانند Reflux, Flummox, MartyJS, Alt, Redux و غیره برای پیاده سازی آن پدید آمدند. در این بین، کتابخانه‌ی Redux ماندگار شد و پیروز این نبرد بود!


        توابع خالص و ناخالص (Pure & Impure Functions)

        پیش از شروع بحث، نیاز است با یک‌سری از واژه‌ها مانند توابع خالص و ناخالص آشنا شد. این نکات از این جهت مهم هستند که Redux فقط با توابع خالص کار می‌کند.
        توابع خالص: تعدادی آرگومان را دریافت کرده و بر اساس آن‌ها، مقداری را باز می‌گردانند.
        // Pure
const add = (a, b) => {
  return a + b;
}
        در اینجا یک تابع خالص را مشاهده می‌کنید که a و b را دریافت کرده و بر این اساس، یک خروجی کاملا مشخص را بازگشت می‌دهد.

        توابع ناخالص: این نوع توابع سبب تغییراتی در متغیرهایی خارج از میدان دید خود می‌شوند و یا به همراه یک سری اثرات جانبی (side effects) مانند تعامل با دنیای خارج (وجود یک console.log در آن تابع و یا دریافت اطلاعاتی از یک API خارجی) هستند.
        // Impure
const b;

const add = (a) => {
  return a + b;
}
        تابع تعریف شده‌ی در اینجا ناخالص است؛ چون با اطلاعاتی خارج از میدان دید خود مانند متغیر b، تعامل دارد. این تعامل با دنیای خارج، حتی در حد نوشتن یک console.log:
        // Impure
const add = (a, b) => {
  console.log('lolololol');
  return a + b;
}
        یک تابع خالص را تبدیل به یک تابع ناخالص می‌کند و یا نمونه‌ی دیگر این تعاملات، فراخوانی سرویس‌های backend در برنامه هستند که یک تابع را ناخالص می‌کنند:
        // Impure
const add = (a, b) => {
   Api.post('/add', { a, b }, (response) => {
    // Do something.
   });
};


        روش‌هایی برای جلوگیری از تغییرات در اشیاء در جاوا اسکریپت

        ایجاد تغییرات در آرایه‌ها و اشیاء (Mutating arrays and objects) نیز ناخالصی ایجاد می‌کند؛ از این جهت که سبب تغییراتی در دنیای خارج (خارج از میدان دید تابع) می‌شویم. به همین جهت نیاز به روش‌هایی وجود دارد که از این نوع تغییرات جلوگیری کرد:
        // Copy object
const original = { a: 1, b: 2 };
const copy = Object.assign({}, original);
        برای تغییری در یک شیء، تنها کافی است خاصیتی را به آن اضافه کنیم و یا با استفاده از واژه‌ی کلیدی delete، خاصیتی را از آن حذف کنیم. به همین جهت برای اینکه تغییرات ما بر روی شیء اصلی اثری را باقی نگذارند، یکی از روش‌ها، استفاده از متد Object.assign است. کار آن، یکی کردن اشیایی است که به آن ارسال می‌شوند. به همین جهت در اینجا با یک شیء خالی، از صفر شروع می‌کنیم. سپس دومین آرگومان آن را به همان شیء مدنظر، تنظیم می‌کنیم. به این ترتیب به یک کپی از شیء اصلی می‌رسیم که دیگر به آن، اتصالی را ندارد. به همین جهت اگر بر روی این شیء کپی تغییراتی را ایجاد کنیم، به شیء اصلی کپی نمی‌شود و سبب تغییرات در آن (mutation) نخواهد شد.
        برای مثال در React، برای انجام رندر نهایی، در پشت صحنه کار مقایسه‌ی اشیاء صورت می‌گیرد. به همین جهت اگر همان شیءای را که ردیابی می‌کند تغییر دهیم، دیگر نمی‌تواند به صورت مؤثری فقط قسمت‌های تغییر کرده‌ی آن‌را تشخیص داده و کار رندر را فقط بر اساس آن‌ها انجام دهد و مجبور خواهد شد کل یک شیء را بارها و بارها رندر کند که اصلا بهینه نیست. به همین جهت، ایجاد تغییرات مستقیم در شیءای که به state آن انتساب داده می‌شود، مجاز نیست.

        متد Object.assign، چندین شیء را نیز می‌تواند با هم یکی کند و شیء جدیدی را تشکیل دهد:
        // Extend object
const original = { a: 1, b: 2 };
const extension = { c: 3 };
const extended = Object.assign({}, original, extension);
        روش دیگر ایجاد یک کپی و یا clone از یک شیء را که پیشتر در سری «React 16x» بررسی کردیم، به کمک امکانات ES-6، به صورت زیر است:
        // Copy object
const original = { a: 1, b: 2 };
const copy = { ...original };
        در اینجا نیز ابتدا یک شیء خالی را ایجاد می‌کنیم و سپس توسط spread operator، خواص شیء قبلی را درون آن باز کرده و قرار می‌دهیم. به این ترتیب به یک clone از شیء اصلی می‌رسیم. این حالت نیز از ترکیب چندین شیء با هم، پشتیبانی می‌کند:
        // Extend object
const original = { a: 1, b: 2 };
const extension = { c: 3 };
const extended = { ...original, ...extension };


        روش‌هایی برای جلوگیری از تغییرات در آرایه‌ها در جاوا اسکریپت

        متد slice آرایه‌ها نیز بدون ذکر آرگومانی، یک کپی از آرایه‌ی اصلی را ایجاد می‌کند:
        // Copy array
const original = [1, 2, 3];
const copy = [1, 2, 3].slice();
        همچنین معادل همین قطعه کد در ES-6 به همراه spread operator به صورت زیر است:
        // Copy array
const original = [1, 2, 3];
const copy = [ ...original ];
        و یا اگر بخواهیم یک کپی از چندین آرایه را ایجاد کنیم می‌توان از متد concat استفاده کرد:
        // Extend array
const original = [1, 2, 3];
const extended = original.concat(4);
const moreExtended = original.concat([4, 5]);
        متد Array.push، هرچند سبب افزوده شدن عنصری به یک آرایه می‌شود، اما یک mutation را نیز ایجاد می‌کند؛ یعنی تغییرات آن به دنیای خارج اعمال می‌گردد. اما Array.concat یک آرایه‌ی کاملا جدید را ایجاد می‌کند و همچنین امکان ترکیب آرایه‌ها را نیز به همراه دارد.
        معادل قطعه کد فوق در ES-6 و به همراه spread operator آن به صورت زیر است:
        // Extend array
const original = [1, 2, 3];
const extended = [ ...original, 4 ];
const moreExtended = [ ...original, ...extended, 5 ];


        مفاهیم ابتدایی Redux


        در Redux برای ایجاد تغییرات در شیء کلی state، از مفهومی به نام dispatch actions استفاده می‌شود. action در اینجا به معنای رخ‌دادن چیزی است؛ مانند کلیک بر روی یک دکمه و یا دریافت اطلاعاتی از یک API. در این حالت مقایسه‌ای بین وضعیت قبلی state و وضعیت فعلی آن صورت می‌گیرد و تغییرات مورد نیاز جهت اعمال به UI، محاسبه خواهند شد.
        اصلی‌ترین جزء Redux، تابعی است به نام Reducer. این تابع، یک تابع خالص است و دو آرگومان را دریافت می‌کند:


        تابع Reducer، بر اساس action و یا رخ‌دادی، ابتدا کل state برنامه را دریافت می‌کند و سپس خروجی آن بر اساس منطق این تابع، یک state جدید خواهد بود. اکنون که این state جدید را داریم، برنامه‌ی React ما می‌تواند به تغییرات آن گوش فرا داده و بر اساس آن، UI را به روز رسانی کند. به این ترتیب کار اصلی مدیریت state، به خارج از برنامه‌ی React منتقل می‌شود.

        در این تصویر، تابع action creator را هم ملاحظه می‌کند که کاملا اختیاری است. یک action می‌تواند یک رشته و یا یک عدد باشد. با پیچیده شدن برنامه، نیاز به ارسال یک‌سری متادیتا و یا اطلاعات بیشتری از اکشن رسیده‌است. کار action creator، ایجاد شیء action، به صورت یک دست و یکنواخت است تا دیگر نیازی به ایجاد دستی آن نباشد.


        مزایای کار با Redux

        - داشتن یک مکان مرکزی برای ذخیره سازی کلی حالت برنامه (به آن «source of truth» و یا store هم گفته می‌شود): به این ترتیب مشکل ارسال خواص در بین کامپوننت‌های عمیق و چند سطحی، برطرف شده و هر زمانیکه نیاز بود، از آن اطلاعاتی را دریافت و یا با قالب خاصی، آن‌را به روز رسانی می‌کنند.
        - رسیدن به به‌روز رسانی‌های قابل پیش بینی state: هرچند در حالت کار با Redux، یک شیء بزرگ جاوا اسکریپتی، کل state برنامه را تشکیل می‌دهد، اما امکان کار مستقیم با آن و تغییرش وجود ندارد. به همین جهت است که برای کار با آن، باید رویدادی را از طریق actionها به تابع Reducer آن تحویل داد. چون Reducer یک تابع خالص است، با دریافت یک سری ورودی مشخص، همواره یک خروجی مشخص را نیز تولید می‌کند. به همین جهت قابلیت ضبط و تکرار را پیدا می‌کند؛ همان بحث serialize و deseriliaze، توسط ابزاری مانند: logrocket. به علاوه قابلیت undo و redo را نیز می‌توان به این ترتیب پیاده سازی کرد (state جدید محاسبه شده، مشخص است، کل state قبلی را نیز داریم یا می‌توان ذخیره کرد و سپس برای undo، آن‌را جایگزین state جدید نمود). افزونه‌ی redux dev tools نیز قابلیت import و export کل state را به همراه دارد.
        - چون تابع Reducer، یک تابع خالص است و همواره خروجی‌های مشخصی را به ازای ورودی‌های مشخصی، تولید می‌کند، آزمایش کردن، پیاده سازی و حتی logging آن نیز ساده‌تر است. در این بین حتی یک افزونه‌ی مخصوص نیز برای دیباگ آن تهیه شده‌است: redux-devtools-extension. تابع خالص، تابعی است که به همراه اثرات جانبی نیست (side effects)؛ به همین جهت عملکرد آن کاملا قابل پیش بینی بوده و آزمون پذیری آن به دلیل نداشتن وابستگی‌های خارجی، بسیار بالا است.


        Context API خود React چطور؟

        در قسمت 33 سری React 16x، مفهوم React Context را بررسی کردیم. پس از معرفی آن با React 16.3، مقالات زیادی منتشر شدند که ... Redux مرده‌است (!) و یا بجای Redux از React context استفاده کنید. اما واقعیت این است که React Redux در پشت صحنه از React context استفاده می‌کند و تابع connect آن دقیقا به همین زیر ساخت متصل می‌شود.
        کار با Redux مزایایی مانند کارآیی بالاتر، با کاهش رندر‌های مجدد کامپوننت‌ها، دیباگ ساده‌تر با افزونه‌های اختصاصی و همچنین سفارشی سازی، مانند نوشتن میان‌افزارها را به همراه دارد. اما شاید واقعا نیازی به تمام این امکانات را هم نداشته باشید؛ اگر هدف، صرفا انتقال ساده‌تر اطلاعات بوده و برنامه‌ی مدنظر نیز کوچک است. React Context برخلاف Redux، نگهدارنده‌ی state نیست و بیشتر هدفش محلی برای ذخیره سازی اطلاعات مورد استفاده‌ی در چندین و چند کامپوننت تو در تو است. هرچند شبیه به Redux می‌توان اشاره‌گرهایی از متدها را به استفاده کنندگان از آن ارسال کرد تا سبب بروز رویدادها و اکشن‌هایی در کامپوننت تامین کننده‌ی Contrext شوند (یا یک کتابخانه‌ی ابتدایی شبیه به Redux را توسط آن تهیه کرد). بنابراین برای انتخاب بین React Context و Redux باید به اندازه‌ی برنامه، تعداد نفرات تیم، آشنایی آن‌ها با مفاهیم Redux دقت داشت.
        ‫۴ سال و ۹ ماه قبل، شنبه ۱۴ دی ۱۳۹۸، ساعت ۱۱:۳۵
        وحید نصیری وحید نصیری
        نظرات مطالب
        یکپارچه سازی Angular CLI و ASP.NET Core در VS 2017
        برای تکرار مجدد: ساختار مدیریت پروژه‌های قدیمی MVC 5 در VS مانند پروژه‌های VSCode یا ASP.NET Core (در همان VS با همان نگارش) نیستند. یعنی هرفایلی که در فایل csproj ارجاعی نداشته باشد، در IDE نمایش داده نمی‌شود (اما در پروژه‌های VSCode و یا پروژه‌های جدید ASP.NET Core، به محض اضافه شدن یک فایل جدید به پوشه‌ی پروژه، این فایل در IDE هم نمایان می‌شود). بنابراین روی دکمه‌ی show all files در solution explorer کلیک کنید و فایل‌های جدید را include کنید (مانند قبل و تمام پروژه‌های دیگری از این دست).


        یک نکته: علت اینکه پروژه‌های ASP.NET Core به این صورت پویا عمل می‌کنند، وجود NET Core CLI. هست. این CLI هم شبیه به Angular-CLI یک ابزار خط فرمان است که کار ایجاد یک پروژه‌ی جدید تا ساخت و توزیع برنامه را مدیریت می‌کند و در حقیقت VS فقط این فرامین خط فرمان را در پشت صحنه اجرا می‌کند. بنابراین بهتر است از ساختار پروژه‌ای استفاده کنید که اساسا برای ابزارهای CLI طراحی شده‌است.

        ‫۷ سال و ۵ ماه قبل، یکشنبه ۷ خرداد ۱۳۹۶، ساعت ۱۴:۱۷