مطالب مشابه
- مطالب
استفاده از پیاده سازی Katana مربوط به استاندارد Owin در ASP.NET 4.xمطالب
استفاده از افزونههای Owin مخصوص سایر نگارشهای ASP.NET در ASP.NET Coreمطالب
ASP.NET MVC #23مطالب
معرفی ASP.NET Identityمطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 1 - NET Core. چیست؟نظرات مطالب
Owin چیست ؟ قسمت اولنظرات مطالب
Owin چیست ؟ قسمت اولنظرات مطالب
Owin چیست ؟ قسمت اولنظرات مطالب
Owin چیست ؟ قسمت اولنظرات مطالب
Owin چیست ؟ قسمت اول
#
۱۰ سال و ۷ ماه قبل، شنبه ۳ اسفند ۱۳۹۲، ساعت ۱۴:۲۱سلامممنون بابت مطلب مفیدتون.
بدون وابستگی به IIS یعنی هر web server ی که OWIN را پیاده سازی کند امکان اجرای برنامه هایی که مثلا با asp.net mvc نوشته شدن رو خواهند داشت؟همین که مثلا با asp.net mvc برنامه نوشته شده به معنی این هست که برنامه بر اساس استاندارد OWIN هست؟ یا کارهایی برای این منظور باید انجام داد؟#
۱۰ سال و ۷ ماه قبل، شنبه ۳ اسفند ۱۳۹۲، ساعت ۱۵:۱۸بدون وابستگی به IIS بعنی شما امکان هاست کردن سرویسهای Web APi رو به صورت Windows Service یا پروژه Console هم خواهید داشت.
به صورت پیش فرض یک پروژه MVC بدون وابستگی به Owin پیاده سازی میشود و برای این منظور میتوانید یکی از موارد زیر را انجام دهید:
»امکان هاست سرویسها روی IIS. در این صورت Owin فقط به صورت یک Middleware عمل خواهد نمود و در این حالت دیگر نیاز به نوشتن HttpModuleها نخواهید داشت. البته این روش به System.Web وابستگی دارد(Microsoft.Owin.Host.SystemWeb )
»استفاده از OwinHost.Exe که در واقع بک پیاده سازی دیگر برای Owin است و عملیات bootstrapping را بر عهده خواهد داشت. در نتیجه شما فقط موارد مربوط به middleWare در application انجام خواهید داد.
»استفاده از Owin Self Hosting برای هاست سرویسها در قالب برنامه Console یا Windows Service
(Microsoft.Owin.Host.HttpListener )#
۱۰ سال و ۷ ماه قبل، شنبه ۳ اسفند ۱۳۹۲، ساعت ۲۲:۵۶ممنون از پاسختون، البته این رو در نظر داشته باشید که استفاده از IIS به همراه Owin لزوما به پیاده سازی Katana یا همان Microsoft.Owin.Host.SystemWeb وابسته نیست، در این حالت شما هیچ گونه بهبود سرعتی رو مشاهده نخواهید کرد و حتی به علت اضافه شدن Owin Middleware بر روی ASP.NET حتی کندتر هم خواهید شد، این حالت فقط برای پروژه هایی توصیه میشود که با استفاده از مواردی مانند Moduleهای ASP.NET و یا Web form به ASP.NET وابسته اند. برای پروژههای جدید استفاده از Helios که نه به System.Web احتیاجی دارد و نه به Owin.Host.SystemWeb توصیه میشود، به همراه Web API ، SignalR و MVC، که به نظر من این ۳ آنقدر کامل و کافی هستند که لزومی به استفاده از ASP.NET System.Web.dll و پیاده سازی Owin مربوطه ای که نام بردید نباشد، تا بتوان بیشتر از مزایای Owin به خصوص کارامدی بیشتر برنامهها بهره برد
#
۱۰ سال و ۷ ماه قبل، یکشنبه ۴ اسفند ۱۳۹۲، ساعت ۰۱:۲۵ممنونم.
در حال حاضر من استفاده از helios رو پیشنهاد نمیکنم چون اولین محدودیتی که در helios جلب توجه میکند Minimum system requirements مورد نظر است.
برای توسعه پروژههای helios :
»Windows 8 یا Windows Server 2012
»NET Framework 4.5.1
»Visual Studio 2012 یا Visual Studio 2013
و برای Web Server نیز :
»Windows Server 2012
»NET Framework 4.5.1
»Full trust مورد نیاز است.
البته به گفته تیم توسعه پروژه helios، احتمال رفع این محدودیتها در آینده وجود دارد. در نتیجه به نظر من Microsoft.AspNet.WebApi.OwinSelfHost گزینه بهتری برای Owin Self Hosting است و از آن جا که در حالت Owin Self Hosting هیچ گونه وابستگی به IIS و البته System.Web نیز وجود ندارد در نتیجه مشکل performance نیز برطرف خواهد شد.#
۱۰ سال و ۷ ماه قبل، یکشنبه ۴ اسفند ۱۳۹۲، ساعت ۰۳:۳۲روش برنامه نویسی مایکروسافت بیش از دو سالی میشود که به این شکل شده است که هر امکان و قابلیت جدیدی بر روی آخرین نسخه NET Framework. ارائه میشود و البته سپس به نسخ قبلی نیز تعمیم مییابد، در همین جا است که میبینید اکثر امکانات Entity Framework 5 & 6 ابتدا بر روی NET Framework 4.5. ارائه شدند، و سپس بر روی 4اگر ما بخواهیم به NET Framework. به عنوان یک پیش نیاز دردسر زا نگاه کنیم، در اولین قدم خودمان را به دردسر انداخته ایم، چون نه برای Helios، بلکه برای صدها امکان دیگر مانند Data Flowهای جدید و ... نیز باید صبر کنیم، که عملا هزینه به فایده آن نمیصرفد. پس همیشه با فراغ بال از آخرین نسخه NET Framework. استقبال کنیمنکتهی دیگر را که باید مد نظر داشته باشیم، این است که مطابق با سیاست هایی که مایکروسافت جدیدا اتخاذ کرده است، دیگر نباید خیلی نگران نسخههای جدید NET Framework. باشیم، چون دیگر از آن نسخه دهیهای پشت سر هم و با حجم تغییرات بالا خبری نیست، بلکه اکثر فریم ورکهای مهم جدا از NET. ارائه و به روز رسانی میشوند.علاوه بر این، ارتقا به آخرین نسخه سیستم عامل ویندوز نیز به هیچ وجه مانند قبل ( IIS 6 به IIS 7 ) دردسر زا نیست، و خوشبختانه این ارتقا ( و یا تغییر هاست ) بدون دردسر است.به نظر من این ارتقاء را انجام دهید، چون نه فقط Helios که خیلی چیزهای دیگری را دارید از دست میدهید، مانند سرعت بالاتر توسعه برنامه بر روی Visual Studio 2013 و Windows 8.1 برای توسعه برنامههای وبی، سرعت و کارآمدی بسیار بالاتر NET Framework 4.5.1. با IIS 8.5 برای مشتریهای برنامه و ...به نظر من آنقدر این ارتقاء ارزشمند است، که ارزش Helios این میان کمتر ارزشش به چشم میآید.یکی از دلایلی که برنامههای سمت وب به سرعت بر برنامههای دسکتاپی قدیمی چیره شدند، همین است: امکان ارتقای سرورها در مدت زمان کم و به شکل مدیریت شده و با کمترین تاثیر روی مشتریهای نهایی، بارها این تصمیم را که در ابتدایش کمی سخت به نظر میآید را گرفته ام و در نهایت از مشتری تا برنامه نویس همه را راضی دیده ام، چون هیچ کسی از امکانات جدید که بدون دردسر حاصل شود بدش نمیآید، و خوشبختانه کیفیت محصولات مایکروسافت واقعا بهبود یافته و دیگر آن زمانی که از NET 2. به 3.5 میرفتیم و گرفتار چندین مشکل میشدیم گذشته است.از این نگذرید که بالاخره روزی باید این مهاجرتها را انجام دهید، پس چه بهتر که از سود آن زودتر بهره مند شوید، البته بی مهابا عمل کردن توصیه نمیشود، بد نیست زمانی شروع به ارتقاء کنید که صفحه Release Notes و سوالات موجود در سایت Stack over flow در رابطه با اشکالات رخ داده در زمان ارتقاء و Breaking Changes را از بر باشید، به این صورت عمل کنید تماما برد کرده اید.
#
۱۰ سال و ۷ ماه قبل، شنبه ۳ اسفند ۱۳۹۲، ساعت ۱۵:۴۳بله، به همین معنی استالبته دقت کنید، پیاده سازی OWIN کار ساده ای نیست، و به سرعت نمیتوان شاهد پیاده سازی آن بر روی هاستهای مختلف بود، و این پروسه با سرعت فعلی از نظر من مدتی طول خواهد کشید.برای مثال Katana که یک پیاده سازی قابل استفاده و خوب از آن به شمار میرود کار شرکت مایکروسافت است و سایر پیاده سازی Open Source سایر تیمها که بالطبع امکان مانور شرکت مایکروسافت را ندارند، کمی طول میکشد تا واقعا آماده استفاده شود.و همچنین پیاده سازیهای فعلی در قسمت هایی مانند Web Socketها و سایر مسائل پیچیده دارای ضعف هایی هستند.درست مانند استاندارد HTML 5 که بر روی مرورگرهای مختلف به میزانهای مختلفی پیاده سازی شده است.به بیان دیگر پیاده سازی OWIN صفر و صدی نیست، بلکه هر پیاده سازی ممکن است در داخل خود دارای ضعفها و یا نواقصی باشد.علاوه بر این اگر شما در کد نویسی ASP.NET MVC خود، بی جهت به امکانات پایه ASP.NET ایجاد وابستگی کنید، نیز در این عمل دچار مشکل خواهید شد، برای همین بدیهتا کاری را که میتوانید با Action Filter انجام دهید را نباید با یک Http Module انجام دهید و ...مهمترین کار طراحی برنامه هایی که مینویسید به صورت سازگار با OWIN است که در پستهای بعدی قرار است به همین قسم از مطالب بپردازیمالبته من آینده خوبی برای OWIN قائلم، و نفع آن در کوتاه مدت و بلند مدت کاملا آشکار و واضح است، کما این که در مطلب به آن اشاره شد.برای مشاهده پیاده سازیهای مختلف OWIN میتوانید به سایت owin.org مراجعه کنید.موفق و پایدار باشید
#
۹ سال و ۲ ماه قبل، چهارشنبه ۳۱ تیر ۱۳۹۴، ساعت ۲۳:۱۹به نظر شما منطقی هست که به جای اینکه برنامههای ویندوزی بنویسیم برنامه را با Asp.net MVC بنویسیم و با کنسول یا ویندوز فرم (مخفی کردن فرم) و با استفاده از Katana آن را اجرا کنیم؟#
۸ سال و ۱ ماه قبل، دوشنبه ۸ شهریور ۱۳۹۵، ساعت ۰۵:۴۷یک سوال
آیا میشه Owin رو با nodejs مقایسه کرد؟