ساختن لایه سرویس برنامه با یک Context

سلام دوستان.
یه موردی هست می خواستم نظرتون رو بدونم.
مطمئنا خیلی جاها خوندین که استفاده از Repositroy و Unit of work اشتباه هست..چون خود DbContext حکم همین داستان رو داره.
من خودم طبق یه مقاله ای الگوی repository,unitofwork رو استفاده کردم که یه مقداری پیچیدگی میاره و بیشتر به درد پروژه های خیلی بزرگ میخوره.مثلا بحث تست واحد رو پوشش میده که اصلا به درد کار من نمیخوره و اینکه از autofac استفاده میکنه برای تزریق وابستگی..حالا من اصلا نیازی به این کارها ندارم.
--------------------------------------------------------------------------------------------------------------
حالا فرض کنید پروژه ای که قرار هست استارت بزنیم یه پروژه کوچیک هست مثلا یه CMS.
داشتن لایه سرویس که بیزینس کار داخلش نوشته میشه میتونه مفید باشه برای برنامه نویس که منطق برنامه رو داخل اکشن های کنترلر پیاده سازی نکنه.
حالا اگه بخوام این لایه سرویس رو پیاده سازی کنم بحث Roll Back ممکنه داخل سیستم اتفاق بیوفته. یک مثال میزنم.
فرض کنید کاربر قرار هست که یک مطلب رو به همراه تگ های اون ثبت کنه.
یعنی دوتا از جداول با زدن دکمه ثبت دچار تغییر میشن.
جدول اول به درستی تغییر میکنه و جدول دوم به هر دلیلی با خطا مواجه میشه.
جدول اول لایه سرویس مربوط به خودش رو داره و جدول دوم هم به همین صورت.
اگر داخل لایه سرویس متد SaveChange صدا زده بشه دیگه نمیش عملیات Roll Back رو انجام داد.
سوال اصلیه من اینه که این SaveChange رو چجوری باید پیاده سازی کنیم که به اصطلاح Context برنامه ما یکی باشه و همه ی سرویس ها از یک Context استفاده بکنن؟
بحث بعدی هم Dispose کردن اون هست که به شکلی باید باشه.
مثلا توی هر لایه سرویس باید dbcontext رو new بکنیم و ازش استفاده کنیم ولی متد Savechange رو چجوری داشته باشیم؟

مقاله های کمی هستن که میگن Anti Pattern هست این الگو ، که فکر میکنم از dotnettips این رو میگید.
Repository پیاده سازیش شاید در ابتدا کمی مشکل باشه اما مزایای بسیار زیادی داره.
میتونید باهاش مباحثی مثل Unit Test, AOP و ... رو پیاده سازی کنید که مورد Unit Test بحثی مهم هستش که در پروژه های بزرگ پیاده سازیش از واجبات هست ; همچنین SoC و Encapsulation رو با این الگو رعایت کردید.
حتی با استفاده از Generic Repository میتونید یکبار بنویسید و براحتی چندبار استفاده کنید.
منبع بد نبودن این الگو میتونه این باشه که در بسیاری از آموزش ها مثل Design Patterns Library از Pluralsight این پترن آموزش داده شده و همچنین در پروژه های بزرگی مثل NopCommerce از همین Generic Repository استفاده شده ، پس میشه به این فکر کرد که این الگو Anti Pattern نیست و به صرف یک مقاله از یک سایت نمیشه این الگو رو زیر سوال برد.

در آخر درباره سوال در مورد لایه سرویس ، میتونید داخل سرویس هاتون از Repository و Unit Of Work استفاده کنید و کارهای اضافه مثل Validation و ... رو داخل سرویس انجام بدید.
https://stackoverflow.com/a/10588594/6661314
https://stackoverflow.com/a/41124405/6661314

به نظر من پیاده سازی UOW به پروژه کوچیک یا بزرگ ربطی نداره
وقتی داریم چند موجودیت رو همزمان به روزرسانی میکنیم مثل مثال شما باید حتمن یک ترانسکشن وجود داشته باشه
توی این موارد UOW خیلی کارساز هست

نقل قول:

---

به نظر من پیاده سازی UOW به پروژه کوچیک یا بزرگ ربطی نداره

---

کاملا موافقم..دقیقا واسه همین این تاپیک رو زدم.
آیا میشه بدون استفاده از interface و DI الگوی Unit of work رو به صورت درست حسابی و اصولی پیاده سازی کرد؟
چون همه آموزش ها میگن Generic Repository & Unitofwork
من نمیخام جنریک استفاده کنم.

نقل قول:

---

Repository پیاده سازیش شاید در ابتدا کمی مشکل باشه اما مزایای بسیار زیادی داره.

---

بله دقیقا... اما پروژه ای که دارم خیلی بزرگ(اصلا) بزرگ نیست..واسه همین ارزش این همه وقت گذاشتن نداره

نقل قول:

---

میتونید باهاش مباحثی مثل Unit Test, AOP و ... رو پیاده سازی کنید که مورد Unit Test بحثی مهم هستش که در پروژه های بزرگ پیاده سازیش از واجبات هست ; همچنین SoC و Encapsulation رو با این الگو رعایت کردید.

---

اصلا من unit test به کارم نمیاد اینجا

برای پیاده سازی الگوی UOW ملزم به Generic Repository یا Repositoryنیستید بدون کلاسهای جنریک Repository هم میشه پیاده سازی کرد
کلاسهای جنریک نوعشان مشخص نیست خب شما کلاسهای Repository بسازید با نوع مشخص یا اینکه کلا از Repository استفاده نکنید فقط از UOW برای ذخیره اطلاعات در دیتابیس استفاده کنید
این لینک میتونه کمکتون کنه
https://docs.microsoft.com/en-us/asp...vc-application

نقل قول:

---

بله دقیقا... اما پروژه ای که دارم خیلی بزرگ(اصلا) بزرگ نیست..واسه همین ارزش این همه وقت گذاشتن نداره

---

تمام وقت لازم برای ایجاد یک Generic Repository فقط ایجاد 1 کلاس و 1 Interface هست که در تمامی پروژه ها ثابت هست.
اگر از StructureMap هم استفاده کنید خودش با استفاده از Naming Convention ها Resolve میکنه اینترفیس ها و کلاس هاتون رو باهم.
تنها کاری که باید بکنید تزریقش به کنترلر هاتون هست که اون هم کلا 3 خط کد میشه.

اگر نمیخواید از Repository استفاده کنید ، میتونید بطور جداگانه فقط Unit Of Work رو ایجاد کنید و ازش استفاده کنید اما یکی از دلایل استفاده از این الگو new نکردن هرباره ی Context در کنترلر ها هست.
اگر عملیات Add, Delete, Update رو بطور مستقیم با Context انجام بدید و ذخیره سازی رو برعهده Unit Of Work بزارید ، دیگه دلیلی بر استفاده از این الگوها نیست.

نقل قول:

---

مطمئنا خیلی جاها خوندین که استفاده از Repositroy و Unit of work اشتباه هست..چون خود DbContext حکم همین داستان رو داره.

---

این یک اشتباه رایج در مورد نحوه ی کار DbContext و الگوی Repository هست. مارتین فاولر در کتاب Patterns of Enterprise Application Architecture که در واقع مرجع اصلی الگوهای برنامه نویسی امروزه در تعریف الگوی Repository میگه :

نقل قول:

---

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object
collection.

---

که مشخصا اشاره میکنه به اینکه Repository یک واسط بین Domain و Data Mapper هست که Domain همون مدلها و سرویسهاست و Data Mapper همون DbContext هست.
در واقع DbContext اطلاعات رو در حافظه ذخیره نمیکنه و برای اجرای هر عملیاتی به سراغ دیتابیس میره . اما Repository قراره داده هارو درون متغیرهای محلی ذخیره کنه که سرعت دسترسی به اونها بیشتر بشه. نقش Unit Of Work اینه که این حافظه ی موقت ایجاد شده رو زنده نگه داره و جلوی ازبین رفتنش رو بگیره تا بشه همیشه خیلی سریع به داده ها دسترسی داشت.

خروجی متدهای DbContext از نوع IQueryable هست. که در واقع یک کوئری هست و نه خود داده ها. یعنی داده ها قبل از اجرای متد وجود ندارن و در لحظه ای که خط داره اجرا میشه از دیتابیس جمع آوری میشن.
ولی در Repository از IList استفاده میشه. که نوع خاصی از آرایه هست که اطلاعات رو در حافظه نگه میداره. و همه ی کوئری های بعدی روی این حافظه انجام میشه .

استفاده از DbContext مثل دستگاه های آب سردکن لحظه ایه. یک مخزن آب دارن که وقتی شما شیر رو باز میکنید آب رو در مسیر سرد میکنه. که فشار زیادی به دستگاه میاره و مصرف بالایی هم داره. اما ریپوزیتوری مثل اینه که بطری های آب رو درون یخچال نگه داری و هر وقت لازم داشتی یکی رو باز کنی و بخوری.

اینکه از کلاس Generic استفاده کنید یا نه به وقت و حوصله ی شما برمیگرده. متدهای زیادی هستند که یک شکل عمل میکنن و میشه درون یک کلاس Generic جای داد. از اونجایی که میشه از کلاسهای Generic ارث بری کرد اگر نیاز به متد اختصاصی داشته باشید به راحتی قابل پیاده سازی هست. برای حل مشکل سربار شدن ایجاد کلاسهای ریپوزیتوری هم پیشنهاد من اینه که از کد ساز استفاده کنید. با استفاده از T4 به راحتی میشه کد ریپوزیتوری رو به قالب تبدیل کرد و ایجاد.

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

نقل قول:

---

نوشته شده توسط Moien Tajik

تنها کاری که باید بکنید تزریقش به کنترلر هاتون هست که اون هم کلا 3 خط کد میشه.

---

زمانی که از تزریق وابتسگی توی سازنده کنترلر استفاده میکنیم دیگه نمیتونیم از identity استفاده کنیم.چون کنترلر account که به صورت پیش فرض ساخته میشه توی MVC تزریق وابستگیش از طریق سازنده فرق داره..حالا فرض کنید توی یه کنترلر هم شما نیاز دارید از userManagment استفاده کنید هم تزریق وابستگی لایه های سرویس که این دو تداخل دارند..برای این راه حلی هست؟

نقل قول:

---

نوشته شده توسط سعید کشاورز

زمانی که از تزریق وابتسگی توی سازنده کنترلر استفاده میکنیم دیگه نمیتونیم از identity استفاده کنیم.چون کنترلر account که به صورت پیش فرض ساخته میشه توی MVC تزریق وابستگیش از طریق سازنده فرق داره..حالا فرض کنید توی یه کنترلر هم شما نیاز دارید از userManagment استفاده کنید هم تزریق وابستگی لایه های سرویس که این دو تداخل دارند..برای این راه حلی هست؟

---

درسته ، AccountController خودش پیشفرض 2 تا Dependency در Constructor داره: UserStore و AuthenticationManager که باید بهش تزریق بشن.
تزریق کردن و درست کردن این مشکل هم چند خط بیشتر نیست ، کافیه به IoC Container خودتون بگید از چه کلاس هایی استفاده بشه.

بعوان مثال برای حل این مشکل با Structure Map ، این کد رو داخل Default Registry قرار بدید کافیه و مشکل حل میشه :

For<IUserStore<ApplicationUser>>().Use<UserStore<A  pplicationUser>>();

For<IAuthenticationManager>().Use(() => HttpContext.Current.GetOwinContext().Authenticatio  n);

For<DbContext>().Use(() => new ApplicationDbContext());

علاوه بر این اگر باز هم Controller های دیگه Dependency های دیگه ای بجز اینها نیاز داشته باشن ، براحتی میتونید با Container تون Configure کنید که چه کلاسی به کنترلر تزریق بشه.