سلام من در کار با mvc تازه کارم و آموزش هایم رو از سایت آقای نصیری یاد گرفتم حالا میخوام بدونم آیا باید از DI وRepository pattern , unit Of Work در پروژه هام استفاده کنم یا خیر ؟
اگر بله که لطفا یک نمونه کا از ابتدا کار کرده باشه معرفی کنید
Printable View
سلام من در کار با mvc تازه کارم و آموزش هایم رو از سایت آقای نصیری یاد گرفتم حالا میخوام بدونم آیا باید از DI وRepository pattern , unit Of Work در پروژه هام استفاده کنم یا خیر ؟
اگر بله که لطفا یک نمونه کا از ابتدا کار کرده باشه معرفی کنید
سلام.
لوزومی بر اینکه شما هر کدوم از اینها رو انجام بدین به هیچ عنوان وجود نداره . شما لازم نیست برای انجام یک پروژه این کار ها رو انجام بدین.
اما این کارها توصیه میشه به انجام دادنش موقعی که پروژه شما بزرگه و یا اینکه می خواین به مرور زمان این پروژه رو گسترش بدین و بزرگ ترش کنین.
باز هم لزومی به انجام اینها نیست همونطور که گفتم این موارد توصیه میشه. چون کار شما رو راحت تر و برنامه رو ساخته یافته تر می کنه.
موفق باشید
سلام
DI خیلی خوب هست و اساس برنامه نویسی ماژول بیس برای .net ولی خب جاهای زیادی کاربرد داره. استفاده از اونا ضروری نیست مخصوصا برای پروژه های کوچیک چون یه مقدار زمان بر هست و زمان اجرا و تحلیل رو شاید دو برابر کنه.
اگه پروژت کوچیک نیست حتما لایه بندی شده و بر اساس DI و پترن های روز بنویس. وبسایت زیر هم اومده ساختار DI و خیلی چیزای دیگه رو پیاده سازی کرده و یک سلوشن بهت میده برای شروع کار:
http://aspnetboilerplate.com/
ممنون بابت پاسخگویی خوب شما دوست عزیزنقل قول:
نوشته شده توسط r4hgozar
بسیار ممنون و سپاس گذار از شما دوستان عزیز
پروژه من فعلا کوچیک هست اما اصولی کار کردن رو دوست دارم . متاسفانه بخاطر پیاده سازی های مختلف دچار سردر گمی شده ام .
همه ی کارها را میتوانید با استفاده از لایه ی سرویس به راحتی انجام دهید و نیازی به استفاده از Repository pattern ندارید.
وقتی ریپوزیتوری ندارید Unit of work هم ندارید.
لایه ها به این صورت هستند :
1- دیتابیس
2- EF
3- Repository - Unit of work
4- Service
5- Controller - ASPMVC
معمول این است که از لایه های 1 و 2 و 5 در بسیاری از پروژه های ساده و کوچک (تمرینی ، آموزشی ) استفاده میشود.
در پروژه های بزرگتر یک لایه Service اضافه میشود تا کدهای مربوط به مدیریت و ذخیره سازی اطلاعات و محاسبات تجاری از پروژه ی وب جدا شود (از کنترلر ASP)
این جدا سازی کمک میکند کدهای درون کنترلر خوانا تر باشند و عیب یابی آن ساده تر باشد . در واقع درون کنترلرها فقط باید دستورات مربوط به وب + سرویس قرار بگیرد.
حالا برای اینکه بتوانید این لایه هارا به هم وصل کنید باید از یک DI استفاده کنید.
هدف از ایجاد هر لایه اضافه کردن یک درجه ی ازادی به سیستم است. این درجه ی آزادی کمک میکند وابستگی شما به لایه پایینتر کمتر شود.
یک درجه ی آزادی مثل یک مفصل در استخوان عمل میکند. استخوانی که مفصل ندارد خم نمیشود ، میشکند.
مثلا در لایه ی 2 استفاده از EF وابستگی شما را به نوع دیتابیس از بین میبرد. شما میتوانید بجای SQL Server از MySQL ، sqlite و ... استفاده کنید.
فقط کافی است که ConnectionString رو تغییر بدید تا نوع دیتابیس تغییر کند. (خم کردن)
در حالی که بدون EF اگر شما قصد داشتید دیتابیس را تغییر دهید باید تمامی کدهایی که دیتابیس را مدیریت میکند باز نویسی می کردید. (شکستن)
اضافه کردن لایه ی Repository وابستگی شما را به EF از بین میبرد. مثلا میتوانید بجای EF از NHibernate استفاده کنید .
ضمن اینکه امکان تست دیتابیس به صورت مجزا ممکن میشود. تغییرات در دیتابیس مستقیما روی کدها شما تاثیر نمیگذارد.
مثلا ممکن است یکی از ستونهای جدول را حذف کنید.
چون لایه ی سرویس دیتابیس را نمی بیند متوجه این تغییر نمیشود و کدهای شما بدون مشکل بیلد میشوند.
این قضیه در پروژه های بزرگ که تیمهای جداگانه روی قسمتهای مختلف پروژه کار می کنند بسیار کاربر دارد.
وقتی از Repository استفاده میکنید حافظه ی موقت EF را از بین میبرید. به معنی که EF از وضعیت قبلی خود آگاه نیست و هر بار باید دوباره اطلاعات را بخواند. اینجاست که مفهوم Unit of work نیاز میشود. مثلا در تراکنش بانکی لازم است واریز کنند و برداشت کننده هر دو رکورد ثبت داشته باشند تا تراکنش موفق اعلام شود. اگر از اولی برداشته شود ولی به دومی واریز نشود تراکنش مردود است.
قابلیت استفاده از Transaction در EF وجود دارد ولی با آمدن Repository دیگر کار نمیکند.
این موارد رو در کد نویسی به یاد داشته باشید :
1- پروژه ای وجود ندارد که صد در صد اصولی پیاده شده باشد.
2- اصول و قونین هم صد در صد درست و بی نقص نیستند
3- همه ی اصول و قوانین تغییر میکنند.
4- هرچقدر از عمر یک پروژه میگذرد اصول و قوانین بیشتری در آن شکسته میشود.
5- عمر پروژه های نرم افزاری اونقدر نیست که عمرتون رو برای نوشتن نسخه ی کامل و بی نقص اون پروژه تلف کنید.
با توجه به موارد بالا فقط به اندازه ای که لازم دارید کد بنویسید و بیش از حد درگیر اصول و قوانین نشوید.
نقل قول:
نوشته شده توسط hakim22
بسیار کامل و زیبا جواب من رو دادید واینکه "5- عمر پروژه های نرم افزاری اونقدر نیست که عمرتون رو برای نوشتن نسخه ی کامل و بی نقص اون پروژه تلف کنید." خیلی نصیحت بدرد بخوری برای من بود مرسی
البته که وقتی پروژه ها رو سمبل کنیم عمرشون کم میشه ! آمازون، دیجی کالا، فیس بوک و ... یعنی تصور میکنید عمر اینا تموم میشه به این زودی ها ؟!نقل قول:
عمر پروژه های نرم افزاری اونقدر نیست که عمرتون رو برای نوشتن نسخه ی کامل و بی نقص اون پروژه تلف کنید.
عمر سایتهایی مثل آمازون و فیس بوک و ... به این زودی ها تموم نمیشه ،نقل قول:
نوشته شده توسط Hajivandian
اما مسلما کدی که برای نوشتن اونها استفاده شده بارها باز نویسی شده .
سایت فیس بوک الان روی کدی که زاکربرگ در سال 2003 در دوران دانشجویی نوشته کار نمی کنه.
فیس بوک با PHP پیاده شده . اما PHP که در حال حاضر مورد استفاده ی این شرکت است با نسخه ی که برنامه نویسان از سایت PHP دانلود میکنند کاملا متفاوت است.
با توجه به درآمد زیاد این سایت یک تیم اختصاصی در اختیار دارد که با باز نویسی قسمتهای زیادی از PHP یک نسخه ی اختصاصی جدید تهیه کرده است و فیس بوک روی آن سوار است.
در سایتهایی که عنوان کردید تنها چیزی که ثابت مانده ایده است و کدها و تکنولوژی های پشت آن بارها و بارها تغییر کرده اند.
مثلا سایت netflix قبلا از Silverlight برای نمایش ویدیوی استفاده میکرد.در حال حاضر این تکنولوژی جایش را به HTML5 داده است.
حتی محصولاتی که مایکروسافت ارائه میدهد نیازمند نسخه های جدید ، بروز رسانی و حتی باز نویسی مجدد است. وقتی چند سال پیش بخشی از سورس کد ویندوز XP (که یکی از محبوب ترین و پر استفاده ترین سیستم عاملهای تاریخ است) لو رفت برنامه نویسان از میزان کدهای بدی که در آن بود (سمبل کردن ها) حیرت کردند.
خیلی از سایتهایی که محبوب شده اند کارشان را با Ruby On Rails که یک فریم ورک تولید سریع وبسایت هست آغاز کرده اند.
تویتر ، اینتساگرم ، کوپون و ... زمان ارائه ی نسخه ی اولیه ی هیچکدام از این پروژه ها بیشتر از یک ماه نبوده .
همه چیز با کد سازها و ابزار آماده انجام شده و تحویل شده است.
بعد از اینکه موفقیت نسبی بدست آوردند با درآمد حاصل شده از نسخه ی اولیه برای نسخه های سرمایه گذاری کرده اند.
اگر قرار بود تمامی امکانات و قابلیت های امروزشان را روز اول پیاده سازی کرده و بعد شروع کنند ریسک بزرگی بود. ممکن بود بعد از سرمایه کذاری و صرف وفت زیاد کاربرها آز آن استقبال نکنند و چیزی جز ضرر حاصل نمیشد.
نباید بیش از حد به آینده ی پروژه فکر کرد.این به معنی سمبل کردن نیست بیشتر به معنی بهینه کار کردن است.
اگر کسی مزایا و معایب استفاده از یک روش را نمی داند حتما به آن نیاز پیدا نکرده و دلیلی هم ندارد تا وقتی به مشکل نخورده به دنبال پیاده سازی آن برود.
چون این روشها زیاد هستند و این اقیانوس ته ندارد.
اگر پروژه ی شما به اندازه ی کافی بزرگ باشه به لایه هایی مثل Repository نیاز پیدا میکنید. حتی چند لایه ی دیگر مانند کش و مولتی تنت , ... هم لازم است.
آیا این به این معنی است که روز اول کار باید ساختار آن ها را در پروژه پیاده کنیم ؟
این ابزارها و روشها برای کمک به نوشتن کدهای راحت تر و بهتر طراحی شده اند. اگر کسی فکر میکند با استفاده از یک روش لقمه را دور سرش میچرخواند و جز اینکه یک اصل در برنامه نویسی باشد کمکی به او نمیکند نباید از آن روش استفاده کند.
بعضی از ابزار مانند DI , AutoMapper و لایه سرویس آنقدر خاصیت دارند که در هر پروژه ای لازم هستند اما بعضی دیگر فقط باعث پیچیده شدن کد و سر درگمی برنامه نویس میشوند و فایده ی دیگری ندارند.
کدهایی که می نویسیم روزهای پنج شنبه به رای گیری پیامکی نمیرود که یکیمان حذف شود
یا به بهترین کدی که نوشته شده است نوبل کد نویسی نمیدهند و موسسه ای هم نیست که مهر استاندارد زیر آن بزند.
آنچه از درون کدها بیرون می آید اهمیت دارد.