نیازی نیست. چون طول عمر کل این ماژول دقیقا معادل طول عمر برنامه‌ی وب است. خاتمه‌ی آن هم به صورت خودکار با از حافظه خارج کردن AppDomain برنامه توسط IIS انجام می‌شود. تا زمانیکه برنامه در حال اجرا است این ماژول هم به همین ترتیب. هر زمان که IIS تصمیم به خاتمه‌ی برنامه گرفت، نه این ماژول، هیچ ماژول دیگری هم فرصت مقاومت پیدا نمی‌کند و راسا به همراه AppDomain جاری خاتمه می‌یابد.
سلام
ممنون بابت مطلب مفیدتون.
بدون وابستگی به IIS یعنی هر web server ی که OWIN را پیاده سازی کند امکان اجرای برنامه هایی که مثلا با asp.net mvc نوشته شدن رو خواهند داشت؟
همین که مثلا با asp.net mvc برنامه نوشته شده به معنی این هست که برنامه بر اساس استاندارد OWIN هست؟ یا کارهایی برای این منظور باید انجام داد؟
با سلام؛ یک مشکل برای من پیش میاد. من از هیچ کشی استفاده نمیکنم اما صفحات کاملا کش میشه. حتی نام کنترلر و ویو‌ها رو هم عوض میکنم که برنامه ارور بده اما برنامه باز هم اجرا میشه. با تغییر MapRoute باز هم برنامه از کش خارج نمیشه.
میشه لطفا راهنمایی کنید ؟
میشه لطفا راهنمایی کنید ؟
وقتی در مثال بالا در ابتدا یک کنترلر دیگه را اجرا کنیم مثلا در ابتدا کنترلر Login برنامه اجرا بشه و سپس کنترلر بالا (Home/EmployeeInfoData) را درخواست کنیم برنامه دچار مشکل میشه و با صفحه سفید مواجه هستیم! یعنی اگه در routes.MapRoute برنامه نام کنترلر دیگه ای باشه و سپس کنترلر بالا را فراخانی بشه هیچ مقداری نمایش داده نمیشه
نوشتن یک برنامه enterprise با استفاده از سیلورلایت سریعتر و راحت‌تر است یا mvc؟
با توجه به عدم ارایه سیلورلایت ۶ آیا نوشتن چنین برنامه هایی که حداقل دارای طول عمری 10 ساله هستند کار عاقلانه ای است؟ یا به طور کلی بهتره بپرسم آیا در حال حاضر گزینه دیگری به جز سیلورلایت برای نوشتن یک برنامه Lob وجود دارد؟منهای تمام مباحثی که عنوان شد، یکی دیگر از مزایای استفاده از لایه سرویس، جدا سازی منطقی قسمت‌های مختلف برنامه از هم است. به این ترتیب الان شما دقیقا می‌دونید اعمال کار با یک موجودیت دقیقا در کدام کلاس قرار گرفته و مرتبا در قسمت‌های مختلف برنامه پراکنده و تکرار نشده. اگر مشکلی وجود داشته باشد، در یکجا باید اصلاح شده و اثرش به صورت خودکار به تمام برنامه اعمال می‌شود.
سلام؛
من از وهله سازی نوع HybridHttpOrThreadLocalScoped در یک برنامه ویندوزی استفاده کردم.اما فکر میکنم چون حالت ThreadLocal رو برای این حالت انتخاب میکنه ، وهله مربوط به اشیاء ساخته شده تا زمان بستن برنامه در حافظه باقی بمونه.از این رو فکر میکنم چون وهله ساخته شده از بین نمیره ، کانکشن به DataBase تا زمان بسته شدن برنامه باز بمونه.
من از وهله سازی نوع HybridHttpOrThreadLocalScoped در یک برنامه ویندوزی استفاده کردم.اما فکر میکنم چون حالت ThreadLocal رو برای این حالت انتخاب میکنه ، وهله مربوط به اشیاء ساخته شده تا زمان بستن برنامه در حافظه باقی بمونه.از این رو فکر میکنم چون وهله ساخته شده از بین نمیره ، کانکشن به DataBase تا زمان بسته شدن برنامه باز بمونه.
در مورد CHM پیشتر مطلب نوشتم:(+)
برای استفاده از آن در یک برنامه مستقل، تمام این‌کارها از طریق خط فرمان این برنامه (html help workshop) هم قابل انجام است. فقط فایل‌های پروژه و ایندکس و غیره آن‌را برنامه شما باید تولید کرده و به صورت پارامتر خط فرمان به آن ارسال کند.
برای استفاده از آن در یک برنامه مستقل، تمام این‌کارها از طریق خط فرمان این برنامه (html help workshop) هم قابل انجام است. فقط فایل‌های پروژه و ایندکس و غیره آن‌را برنامه شما باید تولید کرده و به صورت پارامتر خط فرمان به آن ارسال کند.
تقسیم کار بصورت وظیفه‌ای و سپردن یک قسمت از منطق برنامه به یک نفر و پیاده سازی همه لایه ها توسط او
اعضاء با تخصص‌های خاص و تقسیم افراد بین لایه‌ها (برنامه نویس backend،برنامه نویس ui و ...)
روش ترکیبی و سفارشی شده (لطفا در نظرات توضیح دهید)
اعضاء با تخصص‌های خاص و تقسیم افراد بین لایه‌ها (برنامه نویس backend،برنامه نویس ui و ...)
روش ترکیبی و سفارشی شده (لطفا در نظرات توضیح دهید)
یک نکته‌ی تکمیلی: روشی برای عدم استفاده از Razor Pages جهت لاگین کاربران در برنامه‌های Blazor Server
در این سری، از razor pages به همراه قالب پیش‌فرض ASP.NET Core Identity، جهت پیاده سازی ورود کاربران به سیستم، استفاده شده‌است. یعنی کاربر یکبار از فضای Blazor Server خارج شده و وارد یک برنامه‌ی ASP.NET Core Razor Pages معمولی می‌شود؛ لاگین می‌کند (در یک ناحیه‌ی مخصوص razor pages) و سپس مجددا وارد قسمت Blazor Server می‌شود که ... تجربه‌ی کاربری مطلوبی را به همراه ندارد. علت این خروج و ورود را هم در این مطلب می‌توانید مطالعه کنید: «دستیابی به HttpContext در Blazor Server». هدف این بوده که بتوان با استفاده از HttpContext مهیای در razor pages (و نه توسط اتصال web socket یک برنامه‌ی blazor server)، کوکی‌های پس از لاگین موفق را به سمت مرورگر ارسال و ثبت کرد و درگیر مشکلات به همراه دسترسی به HttpContext در برنامه‌های Blazor server نشد.
راه دیگری هم برای مواجه شدن با این مشکل وجود دارد: حذف قسمت razor pages؛ حذف نیاز به خروج و ورود از برنامه‌ی blazor server و ... استفاده از ProtectedBrowserStorage که اکنون جزئی از blazor server استاندارد است؛ جهت ثبت اطلاعات user claims و عدم استفاده از کوکی‌ها که نیاز به دسترسی به HttpContext را دارند. اگر علاقمند به مشاهده‌ی یک مثال کامل در این زمینه هستید، می‌توانید به پروژه‌ی « BlazorServerAuthenticationAndAuthorization » مراجعه کنید. در اینجا یک CustomAuthenticationStateProvider را به کمک ProtectedSessionStorage طراحی و استفاده کرده تا نیاز به کار با کوکی‌ها برطرف شود و دیگر نیازی به استفاده از razor pages نباشد. البته باید دقت داشت که SessionStorage محدود به tab جاری است و اگر نیاز است اطلاعات آن در تمام برگه‌های باز شده در دسترس باشد، بهتر است از ProtectedLocalStorage استفاده کرد. همچنین باید دقت داشت که چون این protected storageها برای رمزنگاری خودکار اطلاعات از ASP.NET Core data protection API استفاده می‌کنند، نکات مطلب « غیرمعتبر شدن کوکی‌های برنامه‌های ASP.NET Core هاست شده‌ی در IIS پس از ری‌استارت آن » نیز در مورد آن‌ها صادق است.