۶ سال و ۱۰ ماه قبل، شنبه ۴ آذر ۱۳۹۶، ساعت ۲۲:۲۴
۶ سال و ۱۰ ماه قبل، شنبه ۴ آذر ۱۳۹۶، ساعت ۱۸:۴۳
- یکبار دستور dotnet build را در ریشهی پروژهی اصلی و یکبار این دستور را در ریشهی پروژهی لایه دیتا به صورت مجزا اجرا کنید.
- از NET Core CLI. استفاده میکنید (از روش ... dotnet ef)؟ از پارامتر v- آن استفاده کنید (verbose-)
- سازندهی کلاس Context شما وابستگی خاصی دارد؟ آیا IDesignTimeDbContextFactory را برای آن مشخص کردهاید؟
- از NET Core CLI. استفاده میکنید (از روش ... dotnet ef)؟ از پارامتر v- آن استفاده کنید (verbose-)
- سازندهی کلاس Context شما وابستگی خاصی دارد؟ آیا IDesignTimeDbContextFactory را برای آن مشخص کردهاید؟
۶ سال و ۱۰ ماه قبل، شنبه ۴ آذر ۱۳۹۶، ساعت ۱۴:۲۹
- دقیقا مشابه AddHeaderAttribute مطلب جاری است (موارد تعریف و کاربرد AddHeaderAttribute را در صفحه جاری جستجو کنید ).
- یک مثال دیگر:
تعریف یک فیلتر سفارشی با دریافت دو پارامتر رشتهای و یک اینترفیس در سازندهی آن:
این اینترفیس هم به صورت زیر تعریف شدهاست:
و نحوهی تامین وابستگیهای ترزیق آن، در کلاس آغازین برنامه به صورت ذیل ثبت و معرفی شدهاست:
پس از این تنظیمات، روش فراخوانی این فیلتر به صورت ذیل است:
اکنون اگر برنامه را اجرا کنیم، با رسیدن به مسیر About، مقدار دهی صحیح پارامترهای تزریق شدهی به سازندهی فیلتر سفارشی مشخص هستند:
- یک مثال دیگر:
تعریف یک فیلتر سفارشی با دریافت دو پارامتر رشتهای و یک اینترفیس در سازندهی آن:
public class CustomActionFilterAttribute : Attribute, IActionFilter { private readonly string _param1; private readonly string _param2; private readonly IJob _job; public CustomActionFilterAttribute(string param1, string param2, IJob job) { _param1 = param1; _param2 = param2; _job = job; } public void OnActionExecuted(ActionExecutedContext context) { throw new NotImplementedException(); } public void OnActionExecuting(ActionExecutingContext context) { throw new NotImplementedException(); } }
public interface IJob { void Start(); } public class Job1 : IJob { public void Start() { } }
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IJob, Job1>();
پس از این تنظیمات، روش فراخوانی این فیلتر به صورت ذیل است:
[TypeFilter(typeof(CustomActionFilterAttribute), Arguments = new object[] { "param1Value", "param2Value" })] public IActionResult About() {
اکنون اگر برنامه را اجرا کنیم، با رسیدن به مسیر About، مقدار دهی صحیح پارامترهای تزریق شدهی به سازندهی فیلتر سفارشی مشخص هستند:
۶ سال و ۱۰ ماه قبل، سهشنبه ۳۰ آبان ۱۳۹۶، ساعت ۱۶:۴۹
چند نکتهی تکمیلی در مورد بهبود تعاریف Shared Module و Core Module
الف) چگونه از import ثانویهی Core Module در سایر ماژولها جلوگیری کنیم؟
Core Module فقط باید در AppModule برنامه import شود و نه در هیچجای دیگری. برای جلوگیری اتفاقی از این مساله میتوان سازندهای را به شکل زیر به آن اضافه کرد:
روش کار به این صورت است که خود CoreModule را به سازندهی همان کلاس تزریق میکنیم! اگر وهلهای از آن قابل دسترسی بود، یعنی Angular پیشتر این ماژول را import کردهاست. در این حالت با صدور خطایی این مشکل را گوشزد میکنیم.
از همین روش برای تشخیص singleton بودن یک سرویس نیز میتوان استفاده کرد. خودش را به خودش تزریق میکنیم! اگر تزریقی صورت گرفت، یک خطا را صادر میکنیم.
ب) چگونه از وهله سازی مجدد سرویسهای تعریف شدهی در Shared Module در سایر ماژولها جلوگیری کنیم؟
هدف از قسمت providers در Shared Module تنها ارائهی سرویسهایی جهت کامپوننتهای اشتراکی آن است؛ وگرنه سرویسهای سراسری برنامه در CoreModule تعریف میشوند و این ماژول ویژه نیز تنها یکبار و آنهم در AppModule برنامه import خواهد شد. اما در مورد Shared Module اینطور نیست و اگر این ماژول در یک lazy loaded module استفاده شود، سرویسهای آن طول عمر متفاوتی را پیدا خواهند کرد (هر lazy loaded module یک injector و یک طول عمر خاص خودش را تعریف میکند).
در این حالت برای اینکه سرویسهای Shared Module فقط در AppModule وهله سازی شوند و نه در هیچجای دیگری، روش کار به صورت ذیل است:
- ابتدا آرایهی providers را از تعاریف NgModule آن حذف میکنیم.
- سپس متد ویژهای را به نام forRoot، به کلاس آن اضافه خواهیم کرد:
متد forRoot به صورت استاتیک تعریف میشود و همچنین خروجی از نوع ModuleWithProviders دارد. توسط ModuleWithProviders سبب خواهیم شد، AppModule، این ماژول را به همراه آرایهی providers آن import کند؛ اما سایر ماژولها خیر.
سایر ماژولها چون دسترسی به آرایهی حذف شدهی providers این ماژول را ندارند، دیگر نمیتوانند سرویسهای آنرا وهله سازی کنند. اما AppModule با فراخوانی ()SharedModule.forRoot در لیست import خود، تنها یکبار سبب وهله سازی سرویسهای آن میگردد.
بنابراین در اینجا AppModule باید ()SharedModule.forRoot را import کند. سایر ماژولها فقط SharedModule را import میکنند (بدون ذکر متد forRoot). به این ترتیب سرویسهای آن تنها یکبار توسط AppModule در طول عمر برنامه به اشتراک گذاشته میشوند و در این حالت تفاوتی نمیکند که SharedModule در یک lazy loaded module استفاده شدهاست یا خیر.
روش تعریف متد forRoot توسط سیستم مسیریابی Angular نیز استفاده میشود و یک الگوی پذیرفته شده در بین توسعه دهندگان Angular است. برای مثال ()RouterModule.forRoot در AppModule تعریف میشود و ()RouterModule.forChild برای سایر ماژولها.
نمونهای از AppModule ، ShardModule و CoreModule
الف) چگونه از import ثانویهی Core Module در سایر ماژولها جلوگیری کنیم؟
Core Module فقط باید در AppModule برنامه import شود و نه در هیچجای دیگری. برای جلوگیری اتفاقی از این مساله میتوان سازندهای را به شکل زیر به آن اضافه کرد:
@NgModule({ imports: [CommonModule, RouterModule], exports: [], // components that are used in app.component.ts will be listed here. declarations: [], // components that are used in app.component.ts will be listed here. providers: [BrowserStorageService, AppConfigService] // global singleton services of the whole app will be listed here. }) export class CoreModule { constructor( @Optional() @SkipSelf() core: CoreModule) { if (core) { throw new Error("CoreModule should be imported ONLY in AppModule."); } } };
از همین روش برای تشخیص singleton بودن یک سرویس نیز میتوان استفاده کرد. خودش را به خودش تزریق میکنیم! اگر تزریقی صورت گرفت، یک خطا را صادر میکنیم.
ب) چگونه از وهله سازی مجدد سرویسهای تعریف شدهی در Shared Module در سایر ماژولها جلوگیری کنیم؟
هدف از قسمت providers در Shared Module تنها ارائهی سرویسهایی جهت کامپوننتهای اشتراکی آن است؛ وگرنه سرویسهای سراسری برنامه در CoreModule تعریف میشوند و این ماژول ویژه نیز تنها یکبار و آنهم در AppModule برنامه import خواهد شد. اما در مورد Shared Module اینطور نیست و اگر این ماژول در یک lazy loaded module استفاده شود، سرویسهای آن طول عمر متفاوتی را پیدا خواهند کرد (هر lazy loaded module یک injector و یک طول عمر خاص خودش را تعریف میکند).
در این حالت برای اینکه سرویسهای Shared Module فقط در AppModule وهله سازی شوند و نه در هیچجای دیگری، روش کار به صورت ذیل است:
- ابتدا آرایهی providers را از تعاریف NgModule آن حذف میکنیم.
- سپس متد ویژهای را به نام forRoot، به کلاس آن اضافه خواهیم کرد:
@NgModule({ imports: [CommonModule], declarations: [], // common and shared components/directives/pipes between more than one module and components will be listed here. exports: [CommonModule], // common and shared components/directives/pipes between more than one module and components will be listed here. /* No providers here! Since they’ll be already provided in AppModule. */ }) export class SharedModule { static forRoot(): ModuleWithProviders { // Forcing the whole app to use the returned providers from the AppModule only. return { ngModule: SharedModule, providers: [ /* All of your services here. It will hold the services needed by `itself`. */] }; } };
سایر ماژولها چون دسترسی به آرایهی حذف شدهی providers این ماژول را ندارند، دیگر نمیتوانند سرویسهای آنرا وهله سازی کنند. اما AppModule با فراخوانی ()SharedModule.forRoot در لیست import خود، تنها یکبار سبب وهله سازی سرویسهای آن میگردد.
بنابراین در اینجا AppModule باید ()SharedModule.forRoot را import کند. سایر ماژولها فقط SharedModule را import میکنند (بدون ذکر متد forRoot). به این ترتیب سرویسهای آن تنها یکبار توسط AppModule در طول عمر برنامه به اشتراک گذاشته میشوند و در این حالت تفاوتی نمیکند که SharedModule در یک lazy loaded module استفاده شدهاست یا خیر.
روش تعریف متد forRoot توسط سیستم مسیریابی Angular نیز استفاده میشود و یک الگوی پذیرفته شده در بین توسعه دهندگان Angular است. برای مثال ()RouterModule.forRoot در AppModule تعریف میشود و ()RouterModule.forChild برای سایر ماژولها.
نمونهای از AppModule ، ShardModule و CoreModule
۶ سال و ۱۰ ماه قبل، سهشنبه ۳۰ آبان ۱۳۹۶، ساعت ۱۴:۵۸
پیش از submit خاصیت this.fileUploader?.queue?.length را بررسی کنید. اگر مقداری داشت یعنی فایلی انتخاب شدهاست و اگر خیر، پیامی را نمایش دهید.
۶ سال و ۱۰ ماه قبل، سهشنبه ۳۰ آبان ۱۳۹۶، ساعت ۰۴:۵۶
از همان نگارش 4 آن استفاده کنید. فعلا راه حل رسمی ندارد (Owin.Security v3 برای IdentityModel v5 به روز رسانی نشده (از IdentityModel v4 آن استفاده میکند) و تداخل اسمبلیها را دارند).
- Owin.Security v3 با IdentityModel v4 سازگار است.
- Owin.Security v4 با IdentityModel v5 سازگار است.
- Owin.Security v3 با IdentityModel v4 سازگار است.
- Owin.Security v4 با IdentityModel v5 سازگار است.
۶ سال و ۱۰ ماه قبل، یکشنبه ۲۸ آبان ۱۳۹۶، ساعت ۱۴:۱۵
روش یافتن لیست بستههای سراسری نصب شده:
روش یافتن لیست بستههای سراسری نصب شدهی تاریخ مصرف گذشته:
روش به روز رسانی یک بستهی سراسری خاص:
روش به روز رسانی تمام بستههای سراسری نصب شده:
npm list -g --depth=0
روش یافتن لیست بستههای سراسری نصب شدهی تاریخ مصرف گذشته:
npm outdated -g --depth=0
روش به روز رسانی یک بستهی سراسری خاص:
npm update -g <package>
روش به روز رسانی تمام بستههای سراسری نصب شده:
npm update -g
۶ سال و ۱۰ ماه قبل، چهارشنبه ۲۴ آبان ۱۳۹۶، ساعت ۲۲:۴۳
در قسمت this.fileUploader.onSuccessItem این مورد بررسی شدهاست.
۶ سال و ۱۰ ماه قبل، چهارشنبه ۲۴ آبان ۱۳۹۶، ساعت ۱۲:۵۶
- برای گزارشگیری از وظایف موجود از لیست ScheduledTasksCoordinator.Current.ScheduledTasks استفاده کنید.
- برای حذف و خاتمهی یک Task از متد ScheduledTasksCoordinator.Current.RemoveTask(name) استفاده کنید.
- برای افزودن یک Task جدید از متدهای ScheduledTasksCoordinator.Current.AddScheduledTasks(params)/AddScheduledTask(task) استفاده کنید.
- برای حذف و خاتمهی یک Task از متد ScheduledTasksCoordinator.Current.RemoveTask(name) استفاده کنید.
- برای افزودن یک Task جدید از متدهای ScheduledTasksCoordinator.Current.AddScheduledTasks(params)/AddScheduledTask(task) استفاده کنید.
۶ سال و ۱۰ ماه قبل، سهشنبه ۲۳ آبان ۱۳۹۶، ساعت ۱۶:۰۹
علت اینجا است که [itemsPerPage] کامپوننت pagination هم باید مقدار دهی شود.