معایب mvc

[ایمان اختیاری]

سلام.. از دوستان ازم پرسیدن معایب mvc چی هست ؟ البته به نظرم تکنولوژی مورد نظرشون بود نه asp.net mvc ..چیزی توی سایت پیدا نکردم.. می شه راهنمایی بفرمایید

[Behrouz_Rad]

ببینید اصولاً به نظر من چنین سوالی نمی تونه صحیح باشه. اوایل ظهور ASP.NET MVC، برادر Scott Gu گفته بود که "من نمیگم که کدوم به کدوم برتره و این رو خودتون متوجه میشید".
هر روز که میگذره من بیشتر مفهوم حرفی که میزنه رو متوجه میشم. به نظر من ASP.NET MVC برای پروژه های تیمی فوق العادست. اما حتماً نیاز به یک زیر ساخت و فریمورک قوی برای اون هست. در غیر اینصورت برنامه نویس مطمئناً از اون متنفر میشه.

موفق باشید.

[ایمان اختیاری]

بله فرمایش شما صحیح .. من چند مورد رو توی stack خوندم در مورد پیچیدگی و استفاده از جاوا و آژاکس .. البته دقیق متوجه منظورش نشدم.. بیشتر دنبال این هستم که معایبی ازش پیدا کنم.. موضوع تحقیقاتیه ... متشکر می شم اگه راهنمایی بفرمایید

[amir-yeketaz]

ببینید اصولاً به نظر من چنین سوالی نمی تونه صحیح باشه. اوایل ظهور ASP.NET MVC، برادر Scott Gu گفته بود که "من نمیگم که کدوم به کدوم برتره و این رو خودتون متوجه میشید".
هر روز که میگذره من بیشتر مفهوم حرفی که میزنه رو متوجه میشم. به نظر من ASP.NET MVC برای پروژه های تیمی فوق العادست. اما حتماً نیاز به یک زیر ساخت و فریمورک قوی برای اون هست. در غیر اینصورت برنامه نویس مطمئناً از اون متنفر میشه.

موفق باشید.

من دقیقا متوجه منظور شما نشدم! ... بنده میخوام برم سمت وب و با mvc شروع کنم! ... کارمم انفرادیه در رده ی اول! ... یعنی میگین mvc رو بیخیال بشم؟! ... میدونم mvc کدزنیش بیشتره و رعایت کردن یه سری قواعد باعث میشه که یه خورده کار سخت تر بشه ولی آیا این دلیل بر این میشه که من ازش متنفر بشم؟! ... والا من اون پست هایی که تو stackoverflow دیدم اکثریت میگفتن که MVC بهتره و اونو یاد بگیرین!

[Behrouz_Rad]

من دقیقا متوجه منظور شما نشدم! ... بنده میخوام برم سمت وب و با mvc شروع کنم! ... کارمم انفرادیه در رده ی اول! ... یعنی میگین mvc رو بیخیال بشم؟! ... میدونم mvc کدزنیش بیشتره و رعایت کردن یه سری قواعد باعث میشه که یه خورده کار سخت تر بشه ولی آیا این دلیل بر این میشه که من ازش متنفر بشم؟! ... والا من اون پست هایی که تو stackoverflow دیدم اکثریت میگفتن که MVC بهتره و اونو یاد بگیرین!

از پست های من در این سایت مشخصه که من زمان زیادی از عمرم رو صرف Web Forms کردم و اکنون 6 ماهی هست سرپرستی تیمی رو بر عهده دارم که با MVC کار می کنن. بنابراین فکر می کنم بتونم در مورد احساسی که در مورد هر یک از این دو در برنامه نویس پیدا میشه صحبت کنم.
شعار MVC این هست: Convention over Configuration (قرارداد بر پیکربندی اهمیت بیشتری دارد). که پیشتر زبان هایی مثل Ruby on Rails اون رو محقق کردن. در این حالت شما نمی تونید مثل Web Forms مثلاً یک GridView داشته باشید با امکانات آماده و فوق العاده ای که داره و مثلاً ویرایش و حذف درجا با امکان PostBack پیاده سازی دردسر آمیزی داره. باید بر اساس استاندارد MVC عمل کنید. مثلاً در MVC برای هر عملی مثل Edit یک View بهتره داشته باشید. نمی خوام عبارت "باید" رو استفاده کنم چون اجباری ندارید اما زمانی که با اون کار کنید شاید عبارت "باید" رو عیناً مشاهده کنید.
این جملات احساسی که "در MVC کنترل بیشتری بر خروجی دارید" و "View State ندارید" چیزهایی هستند که مثل نقل و نبات از دهان مبارک طرفداران متعصب اون به وفور می شنوید اما حقیقت این هست که مثلاً یک خروجی خوب با همکاری یک طراح و برنامه نویس خوب به وجود میاد و یک طراح و برنامه نویس بد حتی در زمان استفاده از MVC هم چیز بدی تولید می کنند.
عدم وجود ViewState موجب انجام کار بیشتری میشه. در این حالت شما دو راه دارید: 1) باید از استانداردهای MVC تبعیت کنید. مثلاً برای حذف یک رکورد کاربر رو به صفحه ای می فرستید که در اون جزئیات رکورد وجود داره و دکمه ای برای حذف. پس از حذف، کاربر مجدداً به صفحه ی لیست آیتم ها باید برگرده. 2) از AJAX استفاده کنید. چون با AJAX هیچ PostBackای وجود نداره و وضعیت کنترل حفظ میشه و میشه بدین طریق حذف درجا انجام داد.

اینها مثال بودند و به خاطر دوستمون بیشتر با دید "عیب گرایانه" مطرح شد که البته در اصل عیب نیستند و نوع معماری هستند.
ما یک زیر ساخت و فریمورک فوق العاده قوی داریم که نمونه ی عمومی اون در دنیا ندیدم. در این زیر ساخت که پوششی بر MVC هست تمامی لایه ها به طور خودکار ایجاد می شوند و برنامه نویس فقط درگیر منطق کار و سفارشی کردن Viewها میشه. بدون چنین زیر ساختی، پیاده سازی Use Caseهایی که توسط مدیر پروژه ارائه میشه و Deadlineای که برای اتمام هر یک میگذاره واقعاً غیر ممکن است.
باید تجربه ی کار با هر دو رو داشته باشید تا درک بهتری از واقعیت های هر دو پیدا کنید.

موفق باشید.

[serj1975]

MVC به عنوان یک Design Pattern مطرح در Web مدتها مطرح بوده است و Framework های زیادی در این زمینه مطرح شده است از جمله spring و struct در JAVA و Php Zend
با حضور ASP.NET و موفقیت چشمگیر آن در Rapid Development، تمایل به سمت چنین مدلی بیشتر شد و JSF و ORACLE ADF نیز در همین راستا ایجاد شدند.
با ظهور Ruby On Rails و موفقیت جشمگیر آن دوباره MVC مورد توجه عموم قرار گرفت. ASP.NET MVC نیز در همین حین ایجاد شد و در حال حاضر مورد توجه توسعه دهندگان قرار گرفته است و حمایت چشمگیری از آن میشود.
شاید اولین تفاوتی که بین ّFramework هایی مثل JSF و ASP.NET و Framework های MVC مشاهده کنید، عدم حمایت از Design View و Drag & Drop باشد، در واقع شما یک محیط RAD Development ندارید.
به عنوان پیشنهاد یک سری به Django و یا Ruby On Rails بزنید

[baracudaProject]

بهروز

http://www.codeproject.com/KB/library/MVCPlus.aspx

این رو بخون ، اگر می خواهی ام وی سی کار کنی این بهترین است ولی متاسفانه لایسنس دارد ولی تقریبا ما هیچ کدی نمی نویسیم و یکی برای شرکت گرفته ایم ، (من خصوصی برایت می فرستم ولی لایسنس نمی دانم گیر می دهد یا نه؟ )

فقط یک اشکال دارد و آن این است که امی وی سی پلاس ساختار خاصی برای توسعه دارد ولی خوب ، بعید می توانم بتوانی دستی همچین چیزی را بنویسی، ما حتی یک بار هم ریفرش نداریم در سیستم ولی با امی وسی استاندارد فرقهایی دارد...


با تشکر

[Behrouz_Rad]

بهروز

http://www.codeproject.com/KB/library/MVCPlus.aspx

این رو بخون ، اگر می خواهی ام وی سی کار کنی این بهترین است ولی متاسفانه لایسنس دارد ولی تقریبا ما هیچ کدی نمی نویسیم و یکی برای شرکت گرفته ایم ، (من خصوصی برایت می فرستم ولی لایسنس نمی دانم گیر می دهد یا نه؟ )

فقط یک اشکال دارد و آن این است که امی وی سی پلاس ساختار خاصی برای توسعه دارد ولی خوب ، بعید می توانم بتوانی دستی همچین چیزی را بنویسی، ما حتی یک بار هم ریفرش نداریم در سیستم ولی با امی وسی استاندارد فرقهایی دارد...


با تشکر
بعید می دونی که بتونیم بنویسیم؟ من نمی تونم نمونه ای از زیر ساختی که داریم نشون بدم. اما فردی که بعد از من پست داده (serj1975)، یکی از افراد اصلی در ایجاد این زیر ساخت هست. اغراق نیست که بگم نمونش رو در دنیا ندیدم. اون ابزاری که لینکش رو دادی تقریباً در برابر زیر ساخت ما هیچ هست.

موفق باشید.

[scorpion_man]

سلام
این هم یه نرم افزاری که عین یک ماکروفر برای تولید برنامه های asp عمل میکنه. من کارشو تو شرکتهای مختلف دیدم واقعا کامل هست
Iron Speed (http://www.ironspeed.com/)

[iman_ad]

استاد راد شما یک فریم ورک برای mvc نوشتید؟
می شه یکم در مورد امکاناتش توضیح بدید که ما هم ایده بگیریم.

[iman_ad]

استاد منتظر پاسخ شما هستیم

[Javad_Darvish_Amiry]

1) باید از استانداردهای MVC تبعیت کنید. مثلاً برای حذف یک رکورد کاربر رو به صفحه ای می فرستید که در اون جزئیات رکورد وجود داره و دکمه ای برای حذف. پس از حذف، کاربر مجدداً به صفحه ی لیست آیتم ها باید برگرده.
میشه بپرسم این استاندارد از کجا ظهور کرده؟
البته این جمله من در راستای جمله مبارک

چیزهایی هستند که مثل نقل و نبات از دهان مبارک طرفداران متعصب اون به وفور می شنوید
بود. من چند ساله کد میزنم، قبلا هم با ASP.NET پروژه انجام میدادم. اما الان حدود یه سال و خورده ای هست با ASP.NET MVC کار میکنم و به جرات میگم که دیگه هیچوقت حاضر نیستم به web-form برگردم. من متعصب نیستم و طرفدار ASP.NET MVC هم نیستم. (اگه بحث طرفداری مطرح باشه و یه چرخ تو پستهای ناچیز بنده هم بزنید متوجه میشید که من از اساس با دات نت و ویندوز -به طور کلی- مشکل دارم. من طرفدار اوپن سورس هستم و برای توسعه وب چیزی رو به Rails ترجیح نمیدم. این از بحث طرفداری). اما برای کسی که میخواد توسعه وب رو بستر دات نت انجام بده، در حال حاضر چیزی جز MVC رو پیشنهاد نمیکنم (منظور ASP.NET MVC هست). چون پست در مورد معایب هست، مزایاش رو میگذرم و میرم سراغ معایبی که به ذهنم میرسه.
1- MVC یه معماری هست (بین معماری و الگو بودنش اختلاف نظر وجود داره؛ ولی عمده منابع اون رو معماری میدونن نه الگوی طراحی، در هر صورت:) یعنی کسی که میخواد MVC کار کنه، از قبل باید خیلی چیزا رو بدونه که مهمترینش معنای معماری (یا الگو) و مزایا و معایبش و روش های پیاده سازیش و اینجور بحث های زیر ساختی هست. بنابراین دیگه مثل وب-فرم ها هر کسی نمیتونه با یه دوره سی چهل ساعته دیدن و حفظ کردن خصوصیات یه سری کنترل پروژه انجام بده.
2- MVC در ذاتش برای پیاده سازی کاربردها بصورت چند لایه بوجود اومده. بنابراین کسی که میخواد بر مبنای این معماری (الگو) کاری انجام بده باید قدرت تحلیل بالایی داشته باشه و احتمالا به چیزی مثل مهندسی نرم افزار پریسمن بسنده نکرده باشه.
3- MVC (تو دات نت) با سی شارپ (یا یه زبون دات نتی دیگه) نوشته میشه. یعنی شما باید کد زدن بلد باشی. (مثلا سی شارپ). با کشیدن و رها کردن کنترل روی صفحه نمیشه وب سایت ساخت.
4- MVC برای کار تیمی طراحی شده. بواسطه اینکه لایه های مختلف برنامه کاملا از هم تفکیک شده هستند (چیزی که تو وب-فرم ها با وجود همه تلاشها محقق نشد)؛ خوب این بدیش اینجاست که اگه کسی بخواد تنها پروژه انجام بده (چیزی که عموما تو ایران رایج هست و تعداد فری لنسر ها به مراتب خیلی بیشتر از برنامه نویس های شرکتی - و تیمی - هست) باید خیلی چیزها بدونه. هر چند EF کار دیتابیس رو خیلی راحت کرده، ولی برای سمت کلاینت باید حداقل HTNL و CSS و JS رو بلد باشیم. این برای کسایی که با دیزاین ویو ویژوال استودیو صفحه چیدن، واقعا نفرت انگیزه.
5- به دلیل درگیر بودن عناصر نسبتا بیشتر برای پاسخ دهی به درخواست، نسبت به وب-فرم ها MVC خیلی کندتر اجرا میشه (تو MVC 3 با Razor این اختلاف برای تستهای استاندارد انجام شده خیلی کم شده. چیزی حدود 4100 درخواست در هر ثانیه در مقابل 4800 درخواست با وب-فرم). از طرف دیگه رعایت perf تو MVC خیلی سخت تر از وب-فرم ها هست. پیاده سازی Cache Manager پیچیده است. View ها بصورت پیشفرض کامپایل نشده هستند (هر چند میشه زمان کامپایل پروژه، ویوها رو هم کامپایل کرد اما اکثرا از این موضوع بی اطلاع هستند). دیزاین پترن ها (الگوها)ی زیادی براش وجود داره که انتخاب و تسلط و بروز بودن تو یک یا چندتا از اونها نیاز به زحمت و مطالعه مداوم داره.
6- ASP.NET MVC 3 هنوز نهایی نشده!!! (هرچند عجیبه، ولی واقعا هنوز نهایی نشده!) خوب سوال اینجاست که نسخه rel منتشر شده، MVC 4 Preview منتشر شده، پس MVC 3 کی نهایی میشه؟ این اتفاق در مورد ورژنهای قبلی MVC هم افتاده. این از معایب MVC (بطور کلی) نیست و بیشتر برمیگرده به سیاست های تجاری میکروسافت. ولی به هر حال یه واقعیته.
فعلا چیز دیگه ای به ذهنم نمیرسه، ولی اگه چیزی یادم اومد حتما اینجا میذارم. اگه هم براتون ممکنه، نتایج تحقیقتون رو (حتی خلاصه شده) همینجا بذارید تا ما هم (خودم رو عرض میکنم) استفاده کنیم. با احترام فراوان. موفق باشید.

[amir-yeketaz]

به نظر بنده که اگه یکی معماری سه لایه بلد باشه فهمیدن معماری mvc خیلی واسش آسونه ...

درسته که ویژوال بازی (Drag&Drop) در فریمورک asp.net mvc وجود نداره(هر چند که به نظر میاد از mvc 4 به بعد یه چیزایی اضافه میشه!) ولی یه سری ویژگی ها مثه scaffolding هست که کدهای CRUD رو براتون میزنه و همچنین پکیج هایی که از طریق Nuget قابل دسترسه مثه mvcScaffolding (http://blog.stevensanderson.com/2011/01/13/scaffold-your-aspnet-mvc-3-project-with-the-mvcscaffolding-package/) که کلی کد واستون میزنه که حالشو ببرین:دی

شاید عیب mvc این باشه که نیاز به یادگیری زیادی داره و دوره ی بلند مدت واسه یادگیریش لازمه!!! ولی چیزی که هست اینه که شما با یاد گرفتن mvc و کار با asp.net mvc به تقویت قوه ی تحلیلتون و همین طور فهم بیشتر شی گرایی و الگوهای طراحی و کاربردشون (مثه dependency injection) کمک شایانی میکنه ...

[اوبالیت به بو]

سلام

من تا به حال اصلا با MVC کار نکردم. حالا یه سوال برام پیش اومده و اون هم اینه که بهتر نیست به جای سرمایه گذاری رو MVC بیایم روی Sharepoint کار بکنیم؟

[ricky22]

سلام

من تا به حال اصلا با MVC کار نکردم. حالا یه سوال برام پیش اومده و اون هم اینه که بهتر نیست به جای سرمایه گذاری رو MVC بیایم روی Sharepoint کار بکنیم؟
سلام.
ASP.NET MVC و Sharepoint منافاتی با هم ندارند !
به نظر من اصلا نمیشه مقایسه کرد.

[Javad_Darvish_Amiry]

به نظر بنده که اگه یکی معماری سه لایه بلد باشه فهمیدن معماری mvc خیلی واسش آسونه ...
خوب منم همینو میگم. باید معماری بدونی، و دیگه بنایی کارتو راه نمیندازه.

درسته که ویژوال بازی (Drag&Drop) در فریمورک asp.net mvc وجود نداره(هر چند که به نظر میاد از mvc 4 به بعد یه چیزایی اضافه میشه!) ولی یه سری ویژگی ها مثه scaffolding هست که کدهای CRUD رو براتون میزنه و همچنین پکیج هایی که از طریق Nuget قابل دسترسه مثه mvcScaffolding که کلی کد واستون میزنه که حالشو ببرین:دی
با این وجود، باید کدر باشی؛ همون CRUD هم که میزنه، باید بدونی چی زده. موضوع اینه که تو MVC (منظورم ASP.NET MVC هست) جریان حرکت از سمت چگونه نوشتن به چه نوشتن اولا تو یه مسیر درست افتاده و ثانیا شتاب خیلی بالایی داره. این اصلا منافات نداره با این که باید یه کدر قوی بود. به قول اوبی فرناندز، اگه برای این اومدین به سراغ Rails که یاد بگیرید کارها چطور انجام میشن، اشتباه اومدین؛ تو ریلز باید بدونید که کارها چرا اینطور انجام میشن، چون اکثر کارها خودشون انجام میشن!!! به نظر من این قانون برای ریلز نیست و کلا تو معماری (الگو) MVC (در حالت کلی و فارغ از زبان و بستر) صحت داره. اسکلت ها کارهای زیادی انجام میدن، اما در راستای حرکت از چگونه به چه؛ و نه (مثل وب-فرم ها) که باعث بوجود اومدن یک سری تصورات و برداشت های کاملا غلط و سطحی میشد و نتیجتا یه سری برنامه نویس سطحی داشتیم که بزرگترین افتخار و مهارتشون تو نوشتن کنترل های سمت سرور و HttpModule و HttpHandler بود. نتیجتا (برای خود من حداقل) تو MVC زحمت و حجم مطلب و عمق مطلب برای یادگیری زیاده، اما وقتی یاد گرفتی، سرعت اجرای پروژه بینهایت بالا میره. یعنی واقعا قابل مقایسه با وب-فرم ها نیست. پروژه ای که تو وب-فرم مثلا تو دو هفته میزدم، الان تو سه یا چهار روز میزنم. و الخ.

شاید عیب mvc این باشه که نیاز به یادگیری زیادی داره و دوره ی بلند مدت واسه یادگیریش لازمه!!! ولی چیزی که هست اینه که شما با یاد گرفتن mvc و کار با asp.net mvc به تقویت قوه ی تحلیلتون و همین طور فهم بیشتر شی گرایی و الگوهای طراحی و کاربردشون (مثه dependency injection) کمک شایانی میکنه
دقیقا!

ASP.NET MVC و Sharepoint منافاتی با هم ندارند !
به نظر من اصلا نمیشه مقایسه کرد.
دقیقا! هر کسی را بهر کاری ساختند.

اما، یه چیزی یادمون رفت؛ این تاپیک درباره معایب MVC هست :دی

[Behrouz_Rad]

میشه بپرسم این استاندارد از کجا ظهور کرده؟

من دو سناریو مطرح می کنم. برای اونها Solution بده.

1) من یک Dashboard دارم که گزارش جامعی از وضعیت سیستم به من میده. سیستم من باید از Progressive enhancement که امروزه برنامه های وب مدرن اون رو رعایت می کنند پشتیبانی کنه.

2) یک سیستم Security Management داریم. قرار هست که سطح دسترسی بر اساس اعمال CRUD برای این سیستم تعیین بشه.

منتظر پیشنهاداتت هستم.

[Javad_Darvish_Amiry]

پاسخ:

برای اونها Solution بده.
صحبت در مورد استاندارد MVC هست نه راه حل!
اگه راه حل میخواید، میتونیم یه جلسه بذاریم، گفتگو میکنیم، اگه به توافق رسیدیم قرارداد میبندیم، و بعدش برای ارائه راه حل در خدمتتون هستم. موید باشید.

*** آپدیت ***
ضمنا من کارگاه های یک روزه هم گاهی برگزار میکنم؛ که دوستانی که راهشون دوره بدون اینکه متقبل هزینه های اقامت بشن، بتونن از مباحث استفاده کنن؛
روش دیگه هم اینه که سوال رو درست مطرح کنید تا پاسخ درست هم بگیرید؛ موید باشید.

[Behrouz_Rad]

صحبت در مورد استاندارد MVC هست نه راه حل!

ASP.NET MVC به طور پیش فرض Viewهایی رو تولید می کنه. این ها قراردادها یا بهتر بگیم استانداردهایی هست که اون به شما پیشنهاد میده. همون طور که می دونی یکی از این Viewها Edit نام داره.
با این فرض من دو سوال مطرح کردم که دلیل خودم رو برای استاندارد دونستن این روش داشتن View برای اعمال CRUD در ASP.NET MVC بیان کنم.

بحث جلسه و قرارداد نمی دونم چه چیزی هست که میان آوردی. من برای دو سناریوی مطرح شده بستری رو پیاده سازی کردم و تمامی سیستم های ما به خوبی دارن به کار خودشون ادامه میدن. نه کار من لنگ پاسخ شما هست و نه قرار هست در انجمنی آزاد پولی برای پاسخ به سوالی داده بشه.

موفق باشید.

[Javad_Darvish_Amiry]

این ها قراردادها یا بهتر بگیم استانداردهایی هست که اون به شما پیشنهاد میده.
این اتفاقا نه قرارداد هست و نه استاندارد؛ بلکه همونطور که خودتون گفتید یه پیشنهاد هست؛ وقتی صحبت از استاندارد میکنید، یعنی باید مرجعی اون رو به عنوان یک جزء استاندارد از موضوع مورد بحث تایید و تعیین کرده باشه؛ صرف این که ویژوال استودیو کدی یا فایلی ایجاد کنه یا کاری رو از روش خاصی انجام بده، معنای استاندارد رو ایجاد نمیکنه؛ اگه به پست اول خودتون مراجعه کنید متوجه تفاوت بیان و لاجرم تفاوت معنا میشید؛ در مورد MVC خود میکروسافت هم هیچ نقشی توی تعیین استاندارد نداشته، چه برسه به ویژوال استودیو که ما بخوایم از توش استاندارد بکشیم بیرون. از طرف دیگه خیلی موضوعات دیگه هستند که اولویت دارن برای استاندارد شدن. مثل Repository Pattern و TDD و Dependency Injection که تقریبا ناگزیند!!! چطور اونها رو بعنوان استاندارد در نظر نمیگیریم و کد تولیدی ویژوال استودیو میشه استاندارد؟ (البته برداشت اشتباه نشه؛ قصدم صرفا بحثه، نه جدل. باز هم عرض میکنم به پست اولتون مراجعه کنید متوجه میشید دلیل اصرار من چیه).
اما راجع به بخش دوم، قبلا توی دو تا پست قبلی دلیل اون نوشتار و لحن گفتار رو عرض کردم و توضیح اضافه تری ندارم. میتونید پستهای خودتون رو ویرایش کنید که طبیعتا من هم پستهای خودمو ویرایش خواهم کرد؛
***
پاورقی -بیرون از بحث، ولی مفید-
چند وقت پیش دوست عزیزم ricky22 لینک یه مقاله ای رو برام فرستاد تحت عنوان: چرا برنامه نویسان دات نت باید نگاهی به ریلز داشته باشند با یه جمله خیلی عمیق: من روزها برنامه نویس دات نت و شبها برنامه نویس روبی هستم؛ روبی مفرح است و در ضمن از من یک برنامه نویس دات نت بهتر میسازد. دستکم تجربه ای که خود من داشتم این حرف رو تایید میکنه؛ دوستانی که قصد دارن با ASP.NET MVC ادامه بدن، پرداختن به روبی و مخصوصا ریلز کمک شایانی تو درک مفاهیم بهشون میکنه؛ عملا خیلی چیزها وجود داره که روبی و ریلز با سرعت بالایی شما رو به اونجا میرسونند؛ اگه فرصتش رو پیدا کردید، از دستش ندین.
موید باشید.

[Behrouz_Rad]

این اتفاقا نه قرارداد هست و نه استاندارد؛ بلکه همونطور که خودتون گفتید یه پیشنهاد هست؛ وقتی صحبت از استاندارد میکنید، یعنی باید مرجعی اون رو به عنوان یک جزء استاندارد از موضوع مورد بحث تایید و تعیین کرده باشه؛

استاندارد به چه سبکی تولید میشه؟ فردی پیشنهادی رو مطرح می کنه. دیگران بررسی می کنند و در صورت مناسب بودن اون، مورد پذیرش یک جامعه قرار می گیره. این جامعه به چه شکل تعریف میشه؟ آیا کسی که محیط VS رو باز می کنه و بر روی فرم یک دکمه قرار میده رو میشه جزء این جامعه حساب کرد؟ مطمئناً سلایق و دانش افراد در هر موردی متفاوت هست. من از TDD استفاده می کنم. تو هم استفاده می کنی؟ خیلی هم خوب! پس من و تو می دونیم که استاندارد تولید یک برنامه ی خوب و با کیفیت بر حسب تفکر Agile استفاده از TDD هست. این یک استاندارد برای تولید یک محصول با کیفیت هست.

مثلاً برادر استفان والتر که در مایکروسافت کار می کنه میگه:

Adopting naming conventions makes your code easier to read for other developers and your future self. Naming conventions also saves you time so that you can prevent endless debates about the “right” way to name something. In this tip, I recommend standard names for ASP.NET MVC controller actions.

http://stephenwalther.com/blog/archive/2008/06/27/asp-net-mvc-tip-11-use-standard-controller-action-names.aspx

اجباری در مورد پذیرش یک استاندارد وجود نداره. این استانداردی که در موردش صحبت می کنیم چون هیچ وقت نمی تونه نظریات همه ی افراد از جمله تو رو بر آورده کنه، هیچگاه به عنوان یک اجبار مطرح نمیشه. در همین راستا همان برادر میگه که:

Proposing naming conventions is always risky because developers have such strong personal opinions on the right ways to name things. However, I hope this tip can act as a starting point for whatever naming conventions that you develop.

این خوبه که Generic Repository Pattern رو همه استفاده کنند، این خوبه که همه از Dependency Injection استفاده کنند. اینها استانداردهایی برای تولید یک نرم افزار با کیفیت هستند. اما واقعیت این هست که خیلی ها از اینها تبعیت نمی کنند. روش های "بساز و بندازی" فراوانی وجود داره که افراد به اونها روی میارن.

موفق باشید.

[Javad_Darvish_Amiry]

فکر میکنم یک بار باید صراحتا شما رو ارجاع بدم به پست اولتون:


در این حالت شما دو راه دارید: 1) باید از استانداردهای MVC تبعیت کنید. مثلاً برای حذف یک رکورد کاربر رو به صفحه ای می فرستید که در اون جزئیات رکورد وجود داره و دکمه ای برای حذف. پس از حذف، کاربر مجدداً به صفحه ی لیست آیتم ها باید برگرده. 2) از AJAX استفاده کنید. چون با AJAX هیچ PostBackای وجود نداره و وضعیت کنترل حفظ میشه و میشه بدین طریق حذف درجا انجام داد.

شما در نکته 1، یک استاندارد برای MVC مطرح کردید، که این اصلا استانداردی برای MVC نیست -تا جاییکه من میدونم و عرض کردم از کجاست؟ یعنی اگه مرجعی سراغ دارید بفرمایید. من هم میرم مطالعه میکنم، و هیچ مشکلی نیست-؛ و تنها یک پیشنهاد هست؛ حق با شماست، استانداردها اول پیشنهاد میشن و بعد مورد توجه قرار میگیرند و پس از بررسی از سوی جوامعی که حکم مرجعیت رو دارند، به عنوان استاندارد مطرح میشن؛ اما این اتفاق هنوز در مورد مثال فوق صدق پیدا نکرده (و به شخصه هم بعید میدونم هیچوقت این اتفاق بیفته؛ چون اگه میکروسافت بتونه REST رو به شکل موفقیت آمیزی وارد MVC کنه، عملا این پیشنهاد تغییر خواهد کرد، و پیشنهاد بر مبنای REST مطرح خواهد شد؛ که البته باز هم تو اون شرایط اون استانداردِ REST هست که داره پیاده میشه نه استاندارد MVC -نظر شخصی-). نکته بعدی اینه که (و البته نکته ای که باعث این بحث شد) به نظر شما برای عمل مورد نظرتون (حذف یک رکورد) دو راه بیشتر نیست (در این حالت شما دو راه دارید:). خوب دو تا وضعیت بیشتر نداریم، یا شما میدونید این جملتون اشتباهه یا نمیدونید؛ اگه میدونید، پس چرا بجای ویرایش پست، یحث رو به خیلی مسائل دیگه میکشونید (بحث حالا جالب و مفید شد، هیچ مخالفتی ندارم، کما این که پست آخرتون رو در ادامه جداگانه پاسخ میدم و تشکر میکنم بابت اون پست؛ اما این تاثیری در این واقعیت نداره که 1- این بحث اصلا موضوع این تاپیک نیست، 2- تمام نکاتی که شما تو پستها مطرح کردین تنها بیراهه رفتن و به انحراف کشوندن ذهن از مسیر اصلی هست؛ چون استاندارد بودن TDD دلیل بر این نمیشه که راههای شما در مورد حذف رکورد هم استاندارد باشه!) (ادامه:) اگه هم نمیدونید (همونطور که تو دو تا پست قبلی گفتم) میتونید بپرسید و جواب بگیرید (سوء تعبیر پیش نیاد؛ به منطق مکالمه دقت بفرمایید). جمله آغازین من (میشه بپرسم این استاندارد از کجا ظهور کرده؟) همونطور که اشاره کردم در راستا و با لحن جمله ای از شما بود (و این لحن اگه بده برای همه بده و اگه خوبه برای همه خوبه).

با بقیه بحثتون تو پست آخر موافقم (و گفتم که خوب و مفیده). فقط یه اصلاحیه روی اصطلاح Generic Repository Pattern دارم. من عرض کردم Repository Pattern و کلمه Generic رو شما اضافه کردید. درسته یا نادرسته به پای شما. (بنده تا به حال GRP نه دیدم نه شنیدم نه خوندم (در ادامه عرض میکنم چرا). بلکه چیزی که من میشناسم generic implementation of Repository Pattern هست. عرض کردم که فردا دوستان از چشم من نبینند (;
موید باشید.

***پاورقی***

نظریات همه ی افراد از جمله تو رو بر آورده
«تو» در این جمله به معنای «شما» می باشد (;