استفاده مستقیم از DbContext یا پیاده سازی الگوهای دیگر؛ کدامیک؟

[Cybersilent]

تقریبا همزمان با ارائه ef و روش codefirst این بحث همیشه وجود داشته که یکسری افراد شاید به دلیل عادت های قبلی برنامه نویسی همواره به سمت لایه بندی این طراحی بر اساس الگوهای مختلف طراحی دیگر، حرکت داشته اند.
من تقریبا تمام مباحث زیر رو خوانده ام، اما هنوز متوجه نشده ام که چرا باید در یک برنامه که از EF 6.x استفاده می کنم باید بخواهم یک لایه دیگر روی آن قرار بدهم و یکبار از اول تمامی متدهای خود DbContext رو بازنویسی کنم.
(چیزی که در اینجا (http://www.dotnettips.info/post/842/ef-code-first-12#comment-6810)و اینجا (http://www.dotnettips.info/post/842/ef-code-first-12#comment-7049)گفته شده است!) و یا مجبور به پیاده سازی چنین متدهای (http://www.dotnettips.info/post/842/ef-code-first-12#comment-5862)شوم
مگر استفاده مستقیم از خود Dbcontext و متدهای اون چه مشکلی رو ایجاد می کند که باید دست به ابتکار زد و مثلا از الگوی Repository یا چیزی مثل Unitofwork استفاده کرد؟
آیا حتما باید از الگوی واحد که به نحوی که در اینجا (http://www.dotnettips.info/post/842/ef-code-first-12)پیاده سازی شده استفاده و خود را هم درگیر مباحث تزریق وابستگی نمود؟ با این فرض که قرار نیست بعدا از ORM دیگری استفاده نمود و فقط مبحث Unit Test مورد نظر باشد.


Repository ها روی UnitOfWork ایده خوبی نیستند (http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF)
Repositories On Top UnitOfWork Are Not a Good Idea (http://rob.conery.io/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/)
Using DbContext and DbSet instead of implementing repositories and unit of work (http://stackoverflow.com/questions/28367623/using-dbcontext-and-dbset-instead-of-implementing-repositories-and-unit-of-work)
Why shouldn't I use the repository pattern with Entity Framework (http://programmers.stackexchange.com/questions/180851/why-shouldnt-i-use-the-repository-pattern-with-entity-framework)
Architecting in the pit of doom: The evils of the repository abstraction layer (http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer)
EF Codefirst #12 (http://www.dotnettips.info/post/842/ef-code-first-12)


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

[anubis_ir]

در مطلب EF-12 كه دقيقا از خود متدهاي Contex استفاده ميشه (متد Set دسترسي استفاده از DbSet رو به صورت مستقيم مي‌ده). چيزي رو قرار نيست شما بازنويسي كني. فقط روي كلاست يك اينترفيس تعريف مي‌كني تا قسمت‌هاي ديگر برنامه از اين اينترفيس استفاده كنن. چرا؟ بخاطر همون بالا رفتن تست پذيري. زمانيكه خواستي يك قسمت معمولي رو تست كني، مي‌توني بجاي پياده سازي اصلي اون اينترفيس، يك پياده سازي تقيلد شده (mocking) رو جايگزين كني كه با ديتابيس سروكار نداشته باشه و همه چيز در حافظه انجام بشه.
اون تزريق وابستگي‌ها و طول عمر تنظيم شده‌ي براش هم كمك مي‌كنه تا در طول يك درخواست فقط يكبار new Context صورت بگيره بجاي اينكه مرتبا در كدها new Context داشته باشي. اين مورد تعداد بار باز و بسته شدن كانكشن رو كم مي‌كنه و سرعت برنامه رو بالا مي‌بره.

[Cybersilent]

خب درباره mocking که در نسخه 6 به بعد اضافه شده است و نیازی به کارهای بالا به خاطر آن نیست. (اینجا (http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF#comment-9756))
در حالت استفاده مستقیم از DbContext هم یکبار تعریف می شود و در تمام اکشن ها مورد استفاده قرار می گیرد، دقیقا مثل همان IUnitofwork ، پس تفاوت در کجاست؟

[r4hgozar]

سلام.
فکر نکنم ضرورتی در استفاده از ایجاد لایه های اضافی که فکر کنم به اصطلاح business layer گفته می شن باشه.
اما خوب مزیت هایی اون باعث شده که تو پروژه های بزرگ از اون استفاده کنن.
دوستمون درباره تست رو گفت.
من خودم به شخصه میام و پروژه های رو به 7 یا 8 تا class library تقسیم می کنم.
اینطوری هم کد ها دسته بندی شده و هم به راحتی میشه عیب و ایراد کد ها رو پیدا کرد. از مثلا من خیلی کار ها رو به جای اینکه تو controller بنویسم تو لایه ای به نام service می نویسم.
شاید تو پروژه های کوچیک نشون نده همون ظور که خیلی از دوستام میگن. اما یه مزیت دیگش اینه که به راحتی می تونین کد های مورد نظرتون رو تو پروژه های دیگتون استفاده کنین. یا به راحتی میشه کار رو توسعه داد چون تمام بخش ها جدا شده و مشخصه.

این چیز هایی بود که من تجربه کردم. البته من به نظرم خودم هنوز خیلی مبتدیم. این فقط تجربه حدود 10 ماه برنامه نویسی من با asp mvc بود.
موفق باشید

[hakim22]

استفاده ی مستقیما از EF بدون لایه بندی در نهایت میتونه به ضرر شما تمام شه ،

در روز اول وقتی پروژه رو تازه شروع کردید شاید اضافه کردن یک لایه و کدهای مربوطه توجیهی نداشته باشد اما در دراز مدت وقتی باگها شروع میشوند عیب یابی کدهایی که هم باید با دیتابیس کار کنند هم امور محاسباتی یا مدیریت داده را انجام دهند (Business) کار مشکلی میشود .

امکان تست ذخیره سازی اطلاعات به طور مجزا وجود ندارد

امکان تست Business به طور مجزا وجود ندارد

امکان استفاده ی مجدد از کدهای وجود ندارد. (فرض کنید شما برای یک پروژه فروشگاه طراحی می کنید بعد در پروژه ی دیگری هرچند دیتابیس یکی هست مدل تجاری فرق میکند. عملا شما نمی توانید از کدهایی که قبلا برای کار با دیتابیس نوشته مستقیما استفاده کنید و باید همه ی کدها را باز نویسی کنید)

در بعضی مواقع شما ممکن است بخواهید برای یک یا چند جدول دستورات EF را باز نویسی کنید (مثلا مقادیر پیش فرض را در SaveChanges جا سازی کنید) بدون استفاده از Repository جدا کردن این نوع عملیات از یکدیگر عملا ممکن نیست.

در حالی که به راحتی میشود با استفاده از Generic ها یک لایه ی Repository را در پروژه پیاده سازی کنید عدم استفاده از آن هر چند پروژه ی شما کوچک باشد کمک زیادی به شما نمی کند.

[Cybersilent]

مگر در یک پروژه MVC، کنترلر ها همان لایه تجاری (Business) ما نمی باشند؟ اگر بلی پس چرا باید این لایه را درون لایه ای دیگر قرار داد؟

[salar IT man]

مگر در یک پروژه MVC، کنترلر ها همان لایه تجاری (Business) ما نمی باشند؟ اگر بلی پس چرا باید این لایه را درون لایه ای دیگر قرار داد؟

وقتی بحث MVC میاد وسط بیشتر افراد تصور میکنند که دیگه همه چی حله و دارم یه نرم افزار رو به صورت چند لایه توسعه میدهم. نخیر!!!! این چنین نیست .MVC یک الگوی طراحی برای لایه UI است و با معماری نرم افزار شما فرق دارد.
حالا اهدافی که معماری چند لایه دنبال میکند :
قابلیت کار تیمی
قابلیت نگهداری و توسعه بالا
قابلیت تست واحد !!! اگر شما بدون استفاده از الگوی تزریق وابستگی ها بخوایین تست هم بنویسید در این صورت تست شما دیگه واحد نخواهد بود و به دیتابیس شما وابسته شده است .به دلیل استفاده نکردن از اینترفیس ها و معکوس سازی وابستگی ها ، قابلیت تقلید را از دست داده اید .
وقتی با یک ORM مدل سازی میکنید پروژه خود را در واقع روی Domain پروزه تمرکز دارید و اینجاست که DomainClasse های شما نباید وابسته به پروژه خاصی باشد (وب. ویندوز فرم . WPF ,...)

من در خدمتم که بحث کنیم.
برای تکمیل بحث این مقالات را ببیند
http://www.dotnettips.info/search/label/n-layer%20architecture#/page/1/date/asc

همچنین Chapter 2 کتاب http://www.ebooksworld.ir/post/index/79/%D8%AF%D8%A7%D9%86%D9%84%D9%88%D8%AF-%DA%A9%D8%AA%D8%A7%D8%A8-building-enterprise-applications-with-wpf-and-mvvm-pattern-

[Cybersilent]

درباره تست پذیری هم من پیشنهاد می کنم اینجا (http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF#‎‎‎comm ent-9623)و مخصوصا اینجا (http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF#‎‎‎comm ent-9756)رو بخونید.

اینترفیس IDbSet (http://msdn.microsoft.com/en-us/library/gg679233%28v=vs.113%29.aspx) معروف در EF دقیقا یک abstraction است و بیانگر ساختار الگوی مخزن. کاملا هم قابلیت mocking دارد؛ از نگارش 6 به بعد EF البته (^ (http://thedatafarm.com/data-access/how-ef6-enables-mocking-dbsets-more-easily/) و ^ (http://msdn.microsoft.com/en-us/data/dn314429) و ^ (http://romiller.com/2012/02/14/testing-with-a-fake-dbcontext/)).
با این حساب چه دلیلی می تواند وجود داشته باشد که من نخواهم به صورت مستقیم از DbContext استفاده کنم، صرف اینکه لایه بندی های اضافی ممکنه من رو حرفه ای تر نشون بده و یکم پروژه را بی جهت پیچیده تر کند؟

[salar IT man]

درباره تست پذیری هم من پیشنهاد می کنم اینجا (http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF#‎‎‎‎c omment-9623)و مخصوصا اینجا (http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF#‎‎‎‎c omment-9756)رو بخونید.

با این حساب چه دلیلی می تواند وجود داشته باشد که من نخواهم به صورت مستقیم از DbContext استفاده کنم، صرف اینکه لایه بندی های اضافی ممکنه من رو حرفه ای تر نشون بده و یکم پروژه را بی جهت پیچیده تر کند؟

جواب را آقای نصیری در همان کامنتی که خوانده اید داده اند . http://www.dotnettips.info/post/1773/repository-%D9%87%D8%A7-%D8%B1%D9%88%DB%8C-unitofwork-%D8%A7%DB%8C%D8%AF%D9%87-%D8%AE%D9%88%D8%A8%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA%D9%86%D8%AF#‎‎‎‎c omment-9756

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

[salar IT man]

این مقاله فک کنم نظر شما را هم عوض خواهد کرد. http://www.dotnettips.info/post/842/ef-code-first-12

[Cybersilent]

تا حدود زیادی متوجه شدم، تنها یک مساله هست که یکم هضمش واسم سخته اونم اینکه :
فرض کنید من 15 موجودیت داشته باشم و بخواهم از الگوی واحد کار به نحوی که در مقالات اشاره شده توضیح داده شده استفاده کنم.
آیا من به ازای تمام اون موجودیت ها باید متدهای CRUD به همراه Async CRUD اونها رو از اول پیاده سازی کنم!؟

[salar IT man]

یکی از اصول SOLID تک مسئولیتی کلاس ها میباشد! و نوشتن پروژه ای که اصولی و قابل نگه داری بالاست ، باید هزینه پرداخت کرد که این هزینه نوشتن کمی کد اضافه نسبت به حالت قبل میباشد. بسته راه حل وجود دارد که این کار ها را همیشه تکرار نکنید مثلا استفاده و کار کردن با فایل های T4 یا هر روش دیگری ولی باز هم میگم آنچنان وقت گیر نخواهد بود. ببینید این یه شکل استاندارد هستش حالا تصمیم با شماست . خوبه که نظرتون عوض شده است.:لبخندساده:

[salar IT man]

با این چند تا مقاله دیگه حجت رو تموم میکنم :لبخند:
چرا از ایجاد کنترلر های چاق و شلوغ اچتناب کنیم؟؟؟http://gunnarpeipman.com/2015/05/why-to-avoid-fat-controllers/
انتقال کد ها به یک لایه بنام سرویس :http://gunnarpeipman.com/2011/06/asp-net-mvc-moving-code-from-controller-action-to-service-layer/

برای پروژه های بزرگ بهتر است از این الگو ها استفاده کنی.

اگه قانع هم نشدی سرمو میزنم به دیوار دیگه :گریه:


شوخی کردم. یا علی
:لبخند:

[salar IT man]

سلام به همه دوستان امروزه هرشغلی در جامعه برای ارائه محصولات، اخبار روز، گفتگوهای دوستانه، تبادل اطلاعات و... در دنیای مجازی نیاز به یک وبسایت دارد. برای ساخت وبسایت ابتدا باید طراحی صفحات وب را بیاموزید تا بتوانید یک قالب حرفه ای و شیک برای ساخت خود بسازید. به همین منظور دوره ای از صفر تا صد برای طراحی سایت بر روی platformهای مختلف به همراه دو هدیه ویژه برای علاقه مندان برگزار می شود. در این دوره زبان های XHtml و CSS را میاموزید و زبان های jQuery و Bootstrap را به عنوان هدیه دوره از ما آموزش می بینید. این دوره به دوصورت حضوری و آموزش از راه دور برگزار می شود تا دوستانی که ساکن تهران نیستند یا بدلیل مشغله کاری امکان حضور در این دوره را ندارند، می توانند بصورت آموزش از راه دور ثبت نام کنند. مدرس دوره : مهندس مهرداد نادری کارشناسی ارشد طراحی و ساخت صفحات وب از کنسرسیوم جهانی وب امریکا، عضو ویژه مایکروسافت، مدرس رسمی اندروید و استاد دانشگاه. برای ثبت نام و یا کسب اطلاعات بیشتر شماره زیر تماس حاصل فرمایید. (ظرفیت محدود) شماره تماس : 22946542 www.mehrdadnaderi.com (http://www.mehrdadnaderi.com) :گیج:


موضوع تاپیک و بحث های آن اصلا ربطی به این پست نداشت . مدیر این بخش کیه ؟!
بحثی که در اینجا مطرح شده مفید تر است از چند تا دوره ای که تا الان خیلی از آموزش ها شبیه به آن در قالب ویدئو و کتاب و ... منتشر شده است. متاسفم برات

[Cybersilent]

با تشکر از دوستانی که در تفهیم مساله کمک کردند.
در این مطلب یک نمونه پیاده سازی از چیزی که دنبالش بودم رو پیدا کردم و بهتر دیدم که اینجا هم به اشتراک بزارم.
در واقع اینجا مشکل تکرار کد در الگویی که دوستمون عرض کرد رو با استفاده از جنریک ها حل کرده اند.
پیاده سازی لایه دسترسی به داده ها توسط EF CodeFirst و Service Layer (http://www.dotnettips.info/post/914/%d9%be%db%8c%d8%a7%d8%af%d9%87-%d8%b3%d8%a7%d8%b2%db%8c-%d9%84%d8%a7%db%8c%d9%87-%d8%af%d8%b3%d8%aa%d8%b1%d8%b3%db%8c-%d8%a8%d9%87-%d8%af%d8%a7%d8%af%d9%87-%d9%87%d8%a7-%d8%aa%d9%88%d8%b3%d8%b7-ef-codefirst-%d9%88-service-layer)