شما از axios در داخل کامپوننت React استفاده کردید که امکان بروزرسانی setUploadProgress در onUploadProgress میسر میشود. در صورتی که از axios در یک فایل JS مجزا استفاده کنیم، چطور میشود setUploadProgress را در کامپوننت بروزرسانی کرد؟ ممنون
درصوتیکه بخوایم سرویسها رو روی چندتا دامنه مجزا تفکیک کنیم - مثلا اطلاعات مالی روی یک بخش api1.com و اطلاعات پرسنلی روی بخش دیگه api2.com - اونوقت سناریو چطور خواهد بود ؟
جالبه یه جورایی مکمل اسمبلی Microsoft.Extensions.DependencyInjection هست. آیا از لحاظ سرعتی هم در عمل نسبت به روش افزودن دستی سرویسها سریعتر است؟ و روش پیشنهادی که سرویسهای Singleton را از سرویس هایی که باید بصورت Scoped تعریف شوند مجزا کرد، چیست؟
سلام، خسته نباشید
جناب مرادی اگر مقدور هست در یک مقاله مجزا ، راجع bit-framework ، روش نصبش، ویژگیها ، ... یه توضیحی بدید، به نظر میاد پیشنیاز این دوره باشه.
کمی بالاتر توضیح دادم «... در عمل کل برنامه و تمام افزونههای آن از یک IUnitOfWork استفاده میکنند؛ یعنی تمام آنها به تمام مدلهای اضافه شدهی به Context اصلی برنامه دسترسی دارند ...»
+ «... موجودیتهای مشترک بین افزونهها را در یک پروژهی مجزا قرار دهید؛ مانند: CommonEntities ...»
+ «... موجودیتهای مشترک بین افزونهها را در یک پروژهی مجزا قرار دهید؛ مانند: CommonEntities ...»
اگه قرار باشه یک سایت سه بخش مجزا داشته باشه که هرکدوم دارای پلاگینهای خودش باشه اونوقت باید هرکدوم IplugIn جداگانه داشته باشه؟
مثلا سه بخش Root ، User و Admin اونوقت افزونه نویسی برای این بخش ها به چه شکل خواهد بود؟
پاسخ به بازخوردهای پروژهها
دیتابیس
مشکلی مشاهده نشد.
متن خطا نشان دهنده این مورد است که کتابخانه مورد نظر در پروژه موجود نیست . این کتابخانه را به صورت مجزا از nuget نصب کنید.
توجه: ورژن پروژه را در بازخورد خود صحیح وارد کنید.
برای ری استارت کردن یک برنامهی ASP.NET حتما نیازی نیست تا IIS را متوقف و سپس راه اندازی کرد یا تنظیمات App pool برنامه را در IIS تغییر داد. روشهای دیگری نیز وجود دارند که عدم آگاهی از آنها میتواند سبب بروز مشکلات عدیدهای گردد و گاها خطایابی آنها بسیار مشکل است؛ زیرا ری استارت شدن برنامه = از دست رفتن آنی تمام سشنهای InProc تمام کاربران سایت؛ پاک شدن کش برنامه در IIS؛ از دست رفتن تمام متغیرهای استاتیک، Application State و مواردی از این دست:
- - نوشتن در پوشه bin برنامه (ایجاد فایل یا ایجاد پوشه یا تغییر نام پوشهها و مواردی از این دست). (بنابراین قرار دادن بانک اطلاعاتی برنامه در این پوشه، اشتباه بوده و به همین جهت پوشهی استاندارد App_Data طراحی شده است)
- - نوشتن در فایل web.config برنامه (به صورت دستی، حتی در حد اضافه کردن یک فاصله یا توسط خود برنامه و یا استفاده از متد File.SetLastWriteTime). در این حالت ASP.NET FileSystemWatcher بلافاصله وارد عمل شده و برنامه را ری استارت میکند. (هدف اصلی وجودی این فایل، برخورد فقط خواندنی با آن است نه ذخیره سازی تنظیمات پویای برنامه در آن. برای ذخیره سازی تنظیمات پویا، از بانک اطلاعاتی و یا یک فایل XML مجزای از وب کانفیگ استفاده کنید یا مواردی مشابه)
- - هر گونه تغییری در فایلها و یا پوشههای App_WebReferences ، App_Code ، Global.asax ، machine.config ، App_GlobalResources و App_LocalResources نیز سبب ری استارت برنامه خواهند شد.
- - با ایجاد، حذف یا تغییر نام یکی از ساب دایرکتوریهای واقع شده در ریشه برنامه. بنابراین اگر برنامهی شما به صورت پویا پوشههایی را ایجاد یا حذف میکند باید منتظر ری استارتهای پی در پی باشید (البته این مورد با از کار انداختن FileChangesMonitor مربوط به HttpRuntime قابل حل میباشد (+)، ولی همانطور که عنوان شد به صورت پیش فرض همواره فعال است)
- - فراخوانی متد System.Web.HttpRuntime.UnloadAppDomain شبیه به همان Application.Exit در برنامههای دسکتاپ است و بلافاصله سبب خاتمهی برنامه میشود. قرار دادن فایل App_Offline.htm در پوشه اصلی برنامه نیز چنین رفتاری را سبب خواهد شد. علاوه بر آن تگ httpRuntime در وب کانفیگ نیز دارای گزینهی enable است و تنظیم آن به false ، سبب خاتمهی سرویس دهی برنامه خواهد شد.
- - رسیدن به عدد numRecompilesBeforeAppRestart تعریف شده در فایل machine.config که عموما به عدد 15 تنظیم شده است. اگر تغییرات زیادی را در فایلهای (مرتبط با ASP.NET مانند aspx ، asmx و غیره) برنامه داده باشید (بیشتر از 15 مورد) و نیازی به ری کامپایل اساسی وجود داشته باشد، ASP.NET FileSystemWatcher به صورت خودکار برنامه را ری استارت خواهد کرد.
نظرات مطالب
خلاصهای کوتاه در مورد WinRT
جناب نصیری از مطلب کامل، مختصر و مفید شما ممنونم.
منم نظر خودمون رو اینجا عنوان کنم... بسیاری از مسائل از تحلیل و برداشت غلط نشئت می گیرند... تصور اینکه مایکروسافت بخواهد دات نت فریم ورک و یا زبان های دات نتی رو جمع کنه در حالیکه باید ده ها سال ازین تکنولوژی پشتیبانی ارائه کنه خیلی سخت و بعید به نظر می رسد. WinRT همانگونه که عنوان شد فقط بستر طراحی اپلیکیشن های کلاینت مبتنی بر واسط کاربری مترو بوده و هیچ ارتباطی با دات نت فریم ورک ندارد. در بحث سمت سرور دات نت فریم ورک و مباحث مربتط با آن نه تنها تضعیف نشده بلکه حرف اصلی را می زنند و پررنگتر از قبل نیز خواهند بود. این همه ورژن جدید در کنفرانیس build ارائه نشد که با ویندوز 8 جمع شه... مقاله ای در خصوص ویژگی های جدید سی شارپ رو اخیرا منتشر کردم که مطالعه ی آن نیز می تواند برای درک مطالب جدید مفید باشد.
http://www.persiadevelopers.com/articles/cs5-after-build.aspx
منم نظر خودمون رو اینجا عنوان کنم... بسیاری از مسائل از تحلیل و برداشت غلط نشئت می گیرند... تصور اینکه مایکروسافت بخواهد دات نت فریم ورک و یا زبان های دات نتی رو جمع کنه در حالیکه باید ده ها سال ازین تکنولوژی پشتیبانی ارائه کنه خیلی سخت و بعید به نظر می رسد. WinRT همانگونه که عنوان شد فقط بستر طراحی اپلیکیشن های کلاینت مبتنی بر واسط کاربری مترو بوده و هیچ ارتباطی با دات نت فریم ورک ندارد. در بحث سمت سرور دات نت فریم ورک و مباحث مربتط با آن نه تنها تضعیف نشده بلکه حرف اصلی را می زنند و پررنگتر از قبل نیز خواهند بود. این همه ورژن جدید در کنفرانیس build ارائه نشد که با ویندوز 8 جمع شه... مقاله ای در خصوص ویژگی های جدید سی شارپ رو اخیرا منتشر کردم که مطالعه ی آن نیز می تواند برای درک مطالب جدید مفید باشد.
http://www.persiadevelopers.com/articles/cs5-after-build.aspx