در یک سلسله مقالات نه چندان بلند ، به بررسی مفهوم Repository Pattern و طریقه استفاده از آن خواهیم پرداخت . در این مجموعه باید یاد بگیرید اصلن Repository چیست ، چرا به آن نیاز داریم و چگونه آنرا در یک پروژه MVC Template می توان در اختیار داشت .
بسمه تعالی
بررسی منطق Repository Pattern و شکل پیاده سازی آن در یک پروژه ASP.NET MVC - قسمت اول
در یک سلسله مقالات نه چندان بلند ، به بررسی مفهوم Repository Pattern و طریقه استفاده از آن خواهیم پرداخت . در این مجموعه باید یاد بگیرید اصلن Repository چیست ، چرا به آن نیاز داریم و چگونه آنرا در یک پروژه MVC Template می توان در اختیار داشت .
نکته : دوستانی با من تماس داشته و در مورد WebForm درخواست مطلب مینمایند . با عرض معذرت باید عرض کنم ، خداحافظ WebForm . وقت خود را با آن تلف نکنید . تمامی مثالهای ما در MVC خواهد بود .
در این مجموعه من قصد ایجاد یک پروژه بزرگ در بستر MVC و Entity Frame Work را ندارم ، ولی موتور شما را برای ایجاد چنین سیستمی روشن میکنم.
در اینترنت صدها مقاله و ... در مورد Repository Pattern داریم و 90% آنها مطالبی حتی عکس همدیگر ارائه میکنند و تازه خواننده را گیج هم میکنند .در این مجموعه ابهامات این روش از ارتباط با دیتابیس را برطرف میکنیم و از آن در عمل استفاده میکنیم.
Repository Pattern اصلن چیست ؟
جواب : سخنان بزرگان .
در عمل Repository یک واسطه است بین Domain و لایه ای که سبب آن المانهای دیتابیس مانند جداول به وسیله آن در محیط کدنویسی شناخته شده اند و مانند یک مجموعه از Domain Object ها عمل میکند.
خوب ظاهرن بعد از توضیح تازه مفهوم پیچیده تر و ناشناخته تر شد . برای حل این مشکل باید نگاهی به مزایای Repository بپردازیم .
1- Repository مانع تکرار در نوشتن Logic پروژه و Query ها خواهد شد.
فرض کنید به لیستی از داده ها ولی فقط 10 تای اول آن لازم نیاز دارید و اینکار در N جای پروژه باید تکرارشود و مورد نیاز است . مثلن چیزی شبیه این .
خوب حالا همین کد را با Repository ببینید .
این شکل فقط 2 پارامتر دارد . Category مورد نظر و تعداد رکوردها .
2- به حداقل رساندن وابستگی لایه دیتا به تکنولوژیها.
در توضیح قسمت 2 باید گفت که اگر خواستید از تکنولوژی ارتباط با دیتابیس مستقل باشید ، از Repository استفاده کنید . مثلن فرض کنید یک جایی لازم شد کلن به Oracle منتقل شوید ، درست است که پروژه منفجر میشود و برای هماهنگ شدن با آن دردسرها بکشید ، ولی با وجود Repository ، این کار حداقل ممکن است . یا فرض کنید یک ورژن جدید از یک تکنولوژی به بازار آمد . خوب با وجود Repository با اندک تغییرات در چند کلاس میتوان شکل صدا زدن Query ها و ... را عوض کرد، ولی بدنه Repository که اکثرا بر اساس Reflection هم هست ، باقی می ماند و این یعنی حفظ 60 درصد لایه دیتا و ....
به تصویر زیر دقت کنید .
ماکروسافت هر 2 سال یک فیلم جدید در آورد یا یک یا چند Update ارائه کرد یا یک تکنولوژی بی طرفدار و درب و داغان را بهبود بخشید و اگر شما بخواهید پا به پای آن بروید ، بدون یک ماهیت منطبق بر Repository یا چیزی شبیه به آن ، رسمن باید پروژه ها را از صفر هم نه ، از زیر صفر دوباره شروع کنید .
ساده تر شدن Unit Testing
این بخش را فعلن نمی توان زیاد شرح داد و ضمنن در حال حاضر نمیتوان ادعا کرد که بدون Repository روال Unit Test کردن مشکل تر خواهد بود ، ولی به دلیل تکه تکه شدن و ماژولار تر شدن لایه ها با استفاده از Repository ، می توان گفت اندکی روالها ساده تر خواهد بود.
خوب همین 3 دلیل فعلن کافی است . برویم ببینیم در کل یک Repository چه اجزایی دارد.
یک Repository حاوی یکسری متد ساده در غالب یک InterFace یا کلاس خواهد بود .
خوب پس Upate کجاست ؟. مگر نباید یک چنین حالتی در Update داشته باشیم ؟.
جواب : نخیر نباید داشته باشیم . Repository با دیتابیس رابطه به آن صورت ندارد. حتی بعضی به دنبال Saveمتد هم برای ذخیره سازی میگردند و اینجاست که بین Developer ها اختلاف می افتد ، ولی من به شما میگویم که Repository متد Save یا Update ندارد.
سوال : پس برای ذخیره سازی داده ها چه کنیم ؟ اگر Repository یک مجموعه از Object های صرفا درون Memory است ، پس تشخیص و ذخیره تغییرات چگونه خواهد بود ؟
باید گفت ، Unit Of Work به صورت کامل دقیق وظیفه تشخیص و اعمال تغییرات را بر عهده دارد. حتی بعضی نظرات می گوید که خود Entity FrameWork یک نوع پیاده سازی Unit of Work است و دیگر دلیل به دوباره کاری نیست . ولی مساله امکان تعدد Repository هاست و آنجاست که باید SaveChanges خارج از Repository باشد .
خوب می توان گفت که Entity FrameWork هم به شکلی یک Repository است ، ولی مشکل اینجاست که اگر قرار شد پروژه را کلن تغییر داده و به جای EF از ADO.NET و Stored Procedure ها استفاده کنیم ، رسمن پروژه منهدم میشود . اینجاست که وجود Repository همه چیز را مستقل از یکدیگر خواهد نمود. ضمن اینکه دقت کنید که The Architecture should be independent of frameworks این چیزی است که بزرگان حوزه نرم افزار بر روی آن تاکید دارند. معماری شما باید به هیچ فریم ورکی بستگی نداشته باشد .
خوب حرف و توجیه به نظر من دیگر کافی است . باید برای اجرا و کار به صورت عملی آماده شد . در قسمت بعدی به بررسی دقیق اجزای درون Repository پرداخته و سپس پیاده سازی آنرا به صورت عملی آغاز خواهیم کرد.