تقریبا همزمان با ارائه ef و روش codefirst این بحث همیشه وجود داشته که یکسری افراد شاید به دلیل عادت های قبلی برنامه نویسی همواره به سمت لایه بندی این طراحی بر اساس الگوهای مختلف طراحی دیگر، حرکت داشته اند.
من تقریبا تمام مباحث زیر رو خوانده ام، اما هنوز متوجه نشده ام که چرا باید در یک برنامه که از EF 6.x استفاده می کنم باید بخواهم یک لایه دیگر روی آن قرار بدهم و یکبار از اول تمامی متدهای خود DbContext رو بازنویسی کنم.
(چیزی که در اینجا و اینجا گفته شده است!) و یا مجبور به پیاده سازی چنین متدهای شوم
مگر استفاده مستقیم از خود Dbcontext و متدهای اون چه مشکلی رو ایجاد می کند که باید دست به ابتکار زد و مثلا از الگوی Repository یا چیزی مثل Unitofwork استفاده کرد؟
آیا حتما باید از الگوی واحد که به نحوی که در اینجا پیاده سازی شده استفاده و خود را هم درگیر مباحث تزریق وابستگی نمود؟ با این فرض که قرار نیست بعدا از ORM دیگری استفاده نمود و فقط مبحث Unit Test مورد نظر باشد.
- Repository ها روی UnitOfWork ایده خوبی نیستند
- Repositories On Top UnitOfWork Are Not a Good Idea
- Using DbContext and DbSet instead of implementing repositories and unit of work
- Why shouldn't I use the repository pattern with Entity Framework
- Architecting in the pit of doom: The evils of the repository abstraction layer
- EF Codefirst #12
ممنون میشم دوستان به ضرورت این نوع طراحی بپردازند و تجربیات خودشون رو از استفاده از چنین الگوهایی در یک پروژه واقعی در میان بگذارند.