- مباحث الگوی مخزن، در حالت کلی درست هستند؛ یک بحث انتزاعی، بدون درنظر گرفتن فناوری پیاده سازی کنندهی آن.
- در مورد EF به خصوص (در این مطلب)، DbSet و DbContext آن پیاده سازی کنندهی الگوهای Repository و Uow هستند ( و منکر آن نیستند ). به همین جهت عنوان میکنند که روی Repository آن، دوباره یک Repository درست نکنید. در بحث هم اشاره به «یک abstraction از abstraction دیگر» همین مطلب است.
اینترفیس IDbSet معروف در EF دقیقا یک abstraction است و بیانگر ساختار الگوی مخزن. کاملا هم قابلیت mocking دارد؛ از نگارش 6 به بعد EF البته (^ و ^ و ^).
- راه حلهای ارائه شده به دلیل اینکه Uow را تزریق نمیکنند مشکل دارند. اساسا هرگونه لایه بندی بدون تزریق وابستگیها مشکل دارد؛ نمیشود یک وهله از یک شیء را بین چندین کلاس درگیر به اشتراک گذاشت (مباحث مدیریت طول عمر در IoC Containerها). مثلا در راه حل آخر ارائه شده فقط آغاز و پایان اجرای یک متد از یک کنترلر مشخص تحت نظر هستند. واقعیت این است که تا اجرای یک اکشن متد به پایان برسد، در طول یک درخواست، پردازش referrer رسیده هم در کلاسی دیگر به موازت آن باید انجام شود (در یک HTTP Module مجزا) و امثال آن. در این حالت چون یک وهله از Uow به اشتراک گذاشته نشده، مدام باید وهله سازی شود؛ بجای اینکه از آن تا پایان درخواست، استفادهی مجدد شود. برای حل آن، در متن ذکر شده مطمئن شوید که «globally accessible» است. این مورد و راه حلهای استاتیک (مانند نحوهی فراخوانی MyApp آن) و singleton در برنامههای وب تا حد ممکن باید پرهیز شود. چون به معنای به اشتراک گذاری آن در بین تمام کاربران سایت. این مورد تخریب اطلاعات را به همراه خواهد داشت. چون DbContext جاری در حال استفاده توسط کاربر الف است و در همان زمان کاربر ب هم چون دسترسی عمومی به آن تعریف شده، مشغول به استفاده از آن خواهد شد. در این بین عملا تراکنش تعریف شده بیمعنا است چون اطلاعات آن خارج از حدود متدهای مدنظر توسط سایر کاربران تغییر کردهاند.
همچنین به دلیل عدم تزریق وابستگیها، پیاده سازیهای آن تعویض پذیر نیستند و قابلیت آزمایش واحد پایینی خواهند داشت. برای مثال در بحث mocking که مطرح شد، میتوانید بگویید بجای این متد خاص از کلاس اصلی، نمونهی آزمایشی من را استفاده کن.
- در مورد EF به خصوص (در این مطلب)، DbSet و DbContext آن پیاده سازی کنندهی الگوهای Repository و Uow هستند ( و منکر آن نیستند ). به همین جهت عنوان میکنند که روی Repository آن، دوباره یک Repository درست نکنید. در بحث هم اشاره به «یک abstraction از abstraction دیگر» همین مطلب است.
تصویری است از قرار دادن کرسر ماوس بر روی DbContext در VS.NET که به صراحت در آن از پیاده سازی الگوی مخزن یاد شده
اینترفیس IDbSet معروف در EF دقیقا یک abstraction است و بیانگر ساختار الگوی مخزن. کاملا هم قابلیت mocking دارد؛ از نگارش 6 به بعد EF البته (^ و ^ و ^).
- راه حلهای ارائه شده به دلیل اینکه Uow را تزریق نمیکنند مشکل دارند. اساسا هرگونه لایه بندی بدون تزریق وابستگیها مشکل دارد؛ نمیشود یک وهله از یک شیء را بین چندین کلاس درگیر به اشتراک گذاشت (مباحث مدیریت طول عمر در IoC Containerها). مثلا در راه حل آخر ارائه شده فقط آغاز و پایان اجرای یک متد از یک کنترلر مشخص تحت نظر هستند. واقعیت این است که تا اجرای یک اکشن متد به پایان برسد، در طول یک درخواست، پردازش referrer رسیده هم در کلاسی دیگر به موازت آن باید انجام شود (در یک HTTP Module مجزا) و امثال آن. در این حالت چون یک وهله از Uow به اشتراک گذاشته نشده، مدام باید وهله سازی شود؛ بجای اینکه از آن تا پایان درخواست، استفادهی مجدد شود. برای حل آن، در متن ذکر شده مطمئن شوید که «globally accessible» است. این مورد و راه حلهای استاتیک (مانند نحوهی فراخوانی MyApp آن) و singleton در برنامههای وب تا حد ممکن باید پرهیز شود. چون به معنای به اشتراک گذاری آن در بین تمام کاربران سایت. این مورد تخریب اطلاعات را به همراه خواهد داشت. چون DbContext جاری در حال استفاده توسط کاربر الف است و در همان زمان کاربر ب هم چون دسترسی عمومی به آن تعریف شده، مشغول به استفاده از آن خواهد شد. در این بین عملا تراکنش تعریف شده بیمعنا است چون اطلاعات آن خارج از حدود متدهای مدنظر توسط سایر کاربران تغییر کردهاند.
همچنین به دلیل عدم تزریق وابستگیها، پیاده سازیهای آن تعویض پذیر نیستند و قابلیت آزمایش واحد پایینی خواهند داشت. برای مثال در بحث mocking که مطرح شد، میتوانید بگویید بجای این متد خاص از کلاس اصلی، نمونهی آزمایشی من را استفاده کن.