ASP.NET Web forms - داره نفس‌های آخرش رو می‌کشه!

سلام
من مدتی هست که شروع به کار با ASP.NET Web forms کردم و بنا به مطالبی که در همین سایت خوندم هفته پیش تصمیم گرفتم که شروع کنم به یاد گیری MVC اما امروز این مطلب رو خوندم و این سوال برام پیش اومد که با توجه به مطالبی که گفته شده که با لینک هایی که داده مطالبش منطقی هم به نظر میرسه آیا عاقلانه هست که شروع به یاد گیری این تکنولوژی جدید ماکروسافت بکنیم؟ از کجا معلومه چند سال دیگه این رو هم رها نکنه و سراغ یه تکنولوژی دیگه نره؟ آیا واقعا امکان پذیره آدم چند سال یه باز درگیر یادگیری یه مبحث جدید بشه؟ (مثل همین MVC، که تفاوت زیادی با Web Forms میکنه) منطقی نیست که مثلا PHP یا یه چیز دیگه رو یاد بگیریم که دیگه مجبور نباشیم انقدر از این موضوع به موضوع دیگه بریم؟

سوال من موضوع هزار بار مطرح شده PHP بهتر است یا ASP نیست لطفا از این منظر جواب ندید مسئله من در گیر بودن دائمی با ارائه تکنولوژی هایی توسط ماکروسافت هست که تفاوتهای زیادی هم با هم دارند(مثل همین Web Forms و MVC)

ممنون

اینم داستان مثل C++‎ و ویژال بیسیک و پاسکال میشه .
ولی همچنان هستند و ماندن.

سلام دوست عزیز من می خوام شروع کنم ولی نمی دونم برم سراغ mvc یا اون یکی

راستش نمی دونم چه فرقی می کنند باهم اصلا کدومشون راحت تر میشه باهاش راه اومد

1) سادگي نوشتن آزمون*هاي واحد
مهم*ترين دليل استفاده از ASP.NET MVC صرفنظر از تمام دلايل ديگر، بحث طراحي ويژه آن جهت ساده سازي تهيه آزمون*هاي واحد است. مشكل اصلي نوشتن آزمون*هاي واحد براي برنامه*هاي ASP.NET web forms، درگير شدن مستقيم با تمام جزئيات طول عمر يك صفحه است. به علاوه فايل*هاي code behind هر چند به ظاهر كدهاي منطق يك صفحه را از كدهاي HTML مانند آن جدا مي*كنند اما در عمل حاوي ارجاعات مستقيمي به تك تك عناصر بصري موجود در صفحه هستند (حس غلط جدا سازي كدها از اجزاي يك فرم). اگر قرار باشد براي اين وب فرم*ها و صفحات، آزمون واحد بنويسيم بايد علاوه بر شبيه سازي چرخه طول عمر صفحه و همچنين رخدادهاي رسيده، كار وهله سازي تك تك عناصر بصري را نيز عهده دار شويم. اينجا است كه ASP.NET web forms گزينه*ي مطلوبي براي اين منظور نخواهد بود و اگر نوشتن آزمون واحد براي آن غيرممكن نباشد، به همين دلايل آنچنان مرسوم هم نيست.
البته شايد بپرسيد كه اين مساله چه اهميتي دارد؟ امكان نوشتن ساده*تر آزمون*هاي واحد مساوي است با امكان ساده*تر اعمال تغييرات به يك پروژه بزرگ. تغييرات در پروژه*هاي بزرگي كه آزمون واحد ندارند واقعا مشكل است. يك قسمت را تغيير مي*دهيد، 10 قسمت ديگر به هم مي*ريزند. اينجا است كه مدام بايد به كارفرما گفت: «نه!»، «نميشه!» يا به عبارتي «نمي*تونم پروژه رو جمع كنم!» چون نمي*تونم سريع برآورد كنم كه اين تغييرات كدام قسمت*ها را تحت تاثير قرار مي*دهند، كجا به هم ريخت. من بايد خودم سريع بتونم مشخص كنم با اين تغيير جديد چه قسمت*هايي به هم ريخته تا اينكه دو روز بعد زنگ بزنند: «باز جايي رو تغيير دادي، يكجاي ديگر كار نمي*كنه!»

2) دستيابي به كنترل بيشتر بر روي اجزاي فريم ورك
در طراحي ASP.NET MVC همه*جا interface ها قابل مشاهد هستند. همين مساله به معناي افزونه پذيري اكثر قطعات تشكيل دهنده ASP.NET MVC است؛ برخلاف ASP.NET web forms. براي مثال تابحال چندين view engine، routing engine و غيره توسط برنامه نويس*هاي مستقل براي ASP.NET MVC طراحي شده*اند كه هيچكدام با ASP.NET web forms ميسر نيست. براي مثال از view engine پيش فرض آن خوشتان نمي*آيد؟ عوضش كنيد! سيستم اعتبار سنجي توكار آن*را دوست نداريد؟ آن*را با يك نمونه بهتر تعويض كنيد و الي آخر ...
به علاوه طراحي بر اساس interface ها يك مزيت ديگر را هم به همراه دارد و آن هم ساده سازي mocking (تقليد) آن*ها است جهت ساده سازي نوشتن آزمون*هاي واحد.

3) سرعت بيشتر اجرا
ASP.NET MVC يك سري از قابليت*هاي ذاتي ASP.NET web forms را مانند ViewState حذف كرده است. اگر وب را جستجو كنيد، برنامه نويس*هاي ASP.NET web forms مدام از اين مساله شكايت دارند و راه* حل*هاي مختلفي را جهت حذف يا فشرده سازي آن ارائه مي*دهند. ViewState در ابتداي امر جهت شبيه سازي محيط دسكتاپ در وب درنظر گرفته شده بود و مهاجرت ساده*تر برنامه نويس*هاي VB6 به وب، اما واقعيت اين است كه اگر يك برنامه نويس ASP.NET web forms به اندازه آن توجهي نداشته باشد، ممكن است حجم آن در يك صفحه پيچيده تا 500 كيلوبايت يا بيشتر هم برسد. همين مساله بر روي سرعت دريافت و اجرا تاثير گذار خواهد بود.

4) كنترل*هاي ASP.NET web forms آنچنان آش دهن*سوزي هم نيستند!
خوب، ViewState حذف شده، بنابراين اكثر كنترل*هاي ASP.NET web forms هم كاربرد آنچناني در ASP.NET MVC نخواهند داشت؛ اما واقعيت اين است كه اكثر اوقات اگر شروع به سفارشي سازي يك كنترل توكار ASP.NET web forms كنيد تا مطابق نيازهاي كاري شما رفتار كند، پس از مدتي به يك كنترل كاملا از نو بازنويسي شده خواهيد رسيد! بنابراين در ابتداي امر تا 80 درصد كار اينطور به نظر مي*رسد كه به عجب سرعت بالايي در توسعه دست يافته*ايم، اما هنگاميكه قرار است اين 20 درصد پاياني را پر كنيم، به اين نتيجه خواهيم رسيد كه اين كنترل*ها با اين وضع ابتدايي كه دارند قابل استفاده نيستند و نياز به دستكاري قابل ملاحظه*اي دارند تا نيازهاي واقعي كاري را برآورده كنند.

5) كنترل كامل بر روي HTML نهايي توليدي
اگر علاقمند به كار با jQuery باشيد، مدام نياز خواهيد تا با ID كنترل*ها و عناصر صفحه كار كنيد. پيشتر ASP.NET web forms اين ID را يك طرفه و به صورت مقدار منحصربفردي توليد مي*كرد كه جهت كار با فريم ورك*هاي جاوا اسكريپتي عموما مشكل ساز بود. البته ASP.NET web forms در نگارش*هاي جديد خود مشكل عدم امكان مقدار دهي ClientId سفارشي را براي كنترل*هاي وب خود برطرف كرده است و اين مورد را مي*توان دستي هم تنظيم كرد ولي در كل باز هم آنچنان كنترلي رو خروجي HTML نهايي كنترل*هاي توليدي نيست مگر اينكه مانند مورد چهارم ياد شده يك كنترل را از صفر بازنويسي كنيد!
همچنين اگر باز هم بيشتر با jQuery و ASP.NET web forms كار كرده باشيد مي*دانيد كه jQuery آنچنان سنخيتي با ViewState و Postback وب فرم*ها ندارد و همين مساله عموما مشكل*زا است. علاوه بر آن اخيرا مايكروسافت توسعه ASP.NET Ajax خود را تقريبا در حالت تعليق و واگذار شده به شركت*هاي ثالث درآورده است و توصيه آن*ها استفاده از jQuery Ajax است. اينجا است كه مدل ASP.NET MVC سازگاري كاملي را با jQuery Ajax دارد هم از لحاظ نبود ViewState و هم از جنبه*ي كنترل كامل بر روي markup نهايي توليدي.
يا براي مثال خروجي پيش فرض يك GridView، جدول HTML ايي است كه اين روزها همه*جا عليه آن صحبت مي*شود. البته يك سري آداپتور CSS friendly براي اكثر اين كنترل*ها موجود است و ... باز هم دستكاري بيش از حد كنترل*هاي پيش فرض جهت رسيدن به خروجي دلخواه. تمام اين*ها را در ASP.NET MVC مي*شود با معادل*هاي بسيار باكيفيت افزونه*هاي jQuery جايگزين كرد و از همه مهم*تر چون ViewState و مفاهيمي مانند PostBack حذف شده، استفاده از اين افزونه*ها مشكل ساز نخواهد بود.

6) استفاده از امكانات جديد زبان*هاي دات نتي
طراحي اصلي ASP.NET web forms مربوط است به دوران دات نت يك؛ زمانيكه نه Generics وجود داشت، نه LINQ و نه آنچنان مباحث TDD يا استفاده از ORMs متداول بود. براي مثال شايد ايجاد يك strongly typed web form الان كمي دور از ذهن به نظر برسد، زمانيكه اصل آن بر مبناي بكارگيري گسترده datatable و dataset بوده است (با توجه به امكانات زبان*هاي دات نتي در آن دوران). بنابراين اگر علاقمند هستيد كه اين امكانات جديد را بكاربگيريد، ASP.NET MVC براي استفاده از آن*ها طراحي شده است!

7) از ASP.NET web forms ساده*تر است
طراحي ASP.NET MVC بر اساس ايده Convention over configuration است. به اين معنا كه اجزاي آن بر اساس يك سري قرار داد در كنار هم مشغول به كار هستند. مشخص است View بايد كجا باشد، نام كنترلرها چگونه بايد تعيين شوند و قرار داد مرتبط به آن چيست، مدل بايد كجا قرار گيرد، قرار داد پردازش آدرس*هاي صفحات سايت به چه نحوي است و الي آخر. خلاصه در بدو امر با يك فريم ورك حساب شده كه شما را در مورد نحوه استفاده صحيح از آن راهنمايي مي*كند، مواجه هستيد.
به همين ترتيب هر پروژه MVC ديگري را هم كه مشاهده كنيد، سريع مي*توانيد تشخيص دهد قراردادهاي بكارگرفته شده در آن چيست. بنابراين اگر قرار است ASP.NET را امروز شروع كنيد و هيچ سابقه*اي هم از وب فرم*ها نداريد، يك راست با ASP.NET MVC شروع كنيد.

8) محدود به پياده سازي مايكروسافت نيست
پياده سازي*هاي مستقلي هم از ASP.NET MVC توسط اشخاص و گروه*هاي خارج از مايكروسافت وجود دارد: ^، ^، ^، ^ و ...


و در پايان يكي ديگر از دلايل سوئيچ به ASP.NET MVC ، «ياد گرفتن يك چيز جديد است» يا به عبارتي فرا گرفتن يك روش ديگر براي حل مسايل، هيچگاه ضرري را به همراه نخواهد داشت كه هيچ، بلكه باعث بازتر شدن ميدان ديد نيز خواهد گرديد.

سلام ضمن تشکر از جناب عارف که توضیح جالبی ارائه کرده اند به نظر من هم هرچقدر بیشتر یاد بگیری فکرت ذهنت بارور میشه میتونی در کارهات راحت تر به نتیجه برسی چون زمینه داری مثل یک مبتدی که برات سخت نیست حتما یاد بگیر ضرر نمیکنی
موفق باشید

ممنون از دوستان بابت جوابها، همچنین آقای arefba گرچه من این مطلب رو قبلا اینجا خونده بودم اما گویا من درست سوالم رو مطرح نکردم و برداشت دوستان چیزی متفاوت از سوال مد نظر من بوده.
سوال من این نیست که از web forms به MVC بریم یا نه مسئله من اینه که ماکروسافت هر چند وقت یه بار تکنولوژی رو که ارائه داده رها میکنه و یه تکنولوژی جدید میده که نیاز به وقت زیادی برای یادگیری داره (حتی با داشتن اطلاعات از بقیه تکنولوژی ها) فرض کنید ما رفتیم سراغ MVC و 4 سال دیگه وقتی تجربه لازم رو کسب کردیم و با بعضی مشکلات که برای حلش جوابی در کتاب ها نیست و تجربه کردن تنها راه آشنا شدن با اوناست کنار اومدی و اون موقع با یه تکنولوژی جدید روبرو خواهی بود و همه چیز از اول .
میخاستم بدونم منطقی هستش ما اینجوری دنبال این روند راه بیوفتیم و هر چند سال یه بار با یه موضوع که کلی مطلب جدید داره مواجه باشیم یا نه یه بار برای همیشه رهاش کنیم و بریم سراغ یه زبان دیگه که ثبات بیشتری داره

مثلا از همین الان با توجه به مطلبی که بالا لینک دادم زمزمه یه ASP واحد وجود داره (ادغام Web Forms و MVC)

ممنون میشم که دوستانی که تجربه دارن قدری راهنمایی کنن

ممنون

سلام دوستان
من تمام گفته هاي دوستا نرا قبول دارم وليكن نظر شما را به مطلبي جلب مي كنم::::

من يكي دو سال پيش سفري داشتم به انگليس! بر حسب اتفاقا بازديدي داشتم از يك شركت مطرح توليدكننده نرم افزار در منچستر
شركتي بود كه توليدات خوبي داشت و در سطح اروپا و افريقا هم فروش بزرگي داشت!! القصه اينكه بگيد با چه زباني توليد ميكرد؟؟؟؟ VB6!!!!!!
پس زياد نگران نباشيد
ما 100 سال ديگه هم از ASP.Net استفاده خواهيم كرد! يا علي

سلام
ما که نمی دونیم چیکار کنیم بریم سراغ MVC یا کار خودمونو ادامه بدیم ...
دوست خوبم امیر واقعاً خواستم نا امید بشم و کلاً برنامه نویسی و ... رو کنار بزارم ولی راست می گی خیلی از شرکت های بزرگ هنوز دارن با VB ور میرن پس باید نگران نباشیم
یا حق

دارید میگید انگلیس...اینجا ایران هست و شرایط کلا فرق می کنه! برای مثال پوستر زیر رو ببینید که بر اساس تحقیقی از 500 شرکت نرم افزاری کمتر از 100 نفر، برای فهمیدن درصد استفاده اونها از Toolkit های مختلف تهیه شده...بعد که دیدید با ایران مقایسه کنید.