پیکر بندی EF Codefirst و الگوی Unit Of Work
سلام دوستان عزیز.
قبل از اینکه تاپیک رو بخونید معذرت خواهی کنم یه مقدار سوالام زیاد بود توی این قضیه واسه همین سعی کردم خیلی مرتب و تمیز بنویسم.عزیزانی که میتونن کمکم کنن نیاز نیست به همش پاسخ بدن، در حدی که توانش رو دارن پاسخ بدن ممنون میشم.(سوالات رو شماره گذاری کردم)
یه مقاله انگلیسی دارم میخونم برای پیاده سازی لایه بندی نرم افزار به صورت Best Practice
چندتا سوال برام پیش اومده که میپرسم..
در ابتدا لینک مقاله رو هم قرار میدم.
https://chsakell.com/2015/02/15/asp-...est-practices/
----------------------------------
سوالاتی که دارم مربوط به بخش: Data Access Layer and Repositories
سوال اول:
توی این کلاسی که از DbContext مشتق شده و قراره کار تبدیل کلاس هارو به جدول در دیتابیس بکنه، کلاس یک سازنده داره به صورت زیر:
public StoreEntities() : base("StoreEntities") { }
دلیل این کار چیه؟ اونطور که من متوجه شدم برای ساختن پایگاه داده به این نام این کار رو انجام میدن..آیا دلیل دیگه ای هم داره؟
-------------------------------
سوال دوم:
داخل همین کلاس بالایی که گفتم یه تابع به صورت زیر تعریف شده
public virtual void Commit()
{
base.SaveChanges();
}
قضیه این تابع چیه؟ فکر کنم مربوط به Unit Of work باشه که به نظر من تازه کار یه مقدار پیچیدس
--------------------------------
سوال سوم:
یه اینترفیس ساخته شده به نام IDbFactory
public interface IDbFactory : IDisposable
{
StoreEntities Init();
}
نقشش چیه این وسط؟
------------------------------
سوال چهارم:
دلیل ساختن کلاس Disposible چیست؟
public class Disposable : IDisposable
{
private bool isDisposed;
~Disposable()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
private void Dispose(bool disposing)
{
if (!isDisposed && disposing)
{
DisposeCore();
}
isDisposed = true;
}
// Ovveride this to dispose custom objects
protected virtual void DisposeCore()
{
}
}
فکر کنم حجم سوالام داره میره بالا..البته هنوز کلی سوال دیگه درباره Unit of work دارم که در ادامه همین تاپیک میپرسم
البته اگه مقاله خوبی درباره Unit Of Work دارین ممنون میشم معرفی کنید که بخونم
پیشاپیش تشکر.
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
سوال 1 :
این مربوط به #C میشه. با کلمه ی کلیدی base میتوانید سازنده ی کلاس مادر رو (کلاسی که ازش ارث بری کردید رو فراخوانی کنید تا نیاز به تعریف مجدد سازنده نداشته باشید.
سوال دوم:
وقتی از UoW استفاده میشه چند جدول به صورت همزمان یا در یک تراکنش آپدیت میشوند به همین دلیل از عبارت Commit برای ذخیره سازی استفاده میشه. کار خاصی انجام نمیده فقط به کلاس مادر رجوع میکنه و متد SaveChanges رو فراخوانی میکنه. مگر اینکه شما بخواهید قبل از عمل ذخیره سازی کدی برای Valid کردن اضافه کنید.
سوال سوم:
چون چند کلاس نیاز به استفاده از یک دیتابیس دارند همرو در از یک اینترفیس گرفته تا ریشه ی مشترک داشته باشن. میشه بدون اینکار هم پروژه رو نوشت.
سوال چهارم :
برای مدیریت Garbage Collection از یک IDisposable دستی استفاده شده. هر وقت کار با دیتابیس تمام میشه با فراخوانی این متد میشه فضای اختصاص داده شده رو دستی تخلیه کرد. گرچه اینکار توسط دات نت به طور خودکار انجام میشه.
به طور کلی Unit of Work کاربرد خیلی کمی داره. یعنی جایی که واقعا بهش نیاز پیدا خواهید کرد کمه.
و خیلی از تکنیک هایی که در این مقاله استفاده شده. از جمله استفاده از یک کلاس جنریک برای تعریف کلاسهای دیتابیس روش خوبی نیست. بسته به نوع پروژه هر کدام از این روشها ممکن خوب یا بد باشن. این حالت کلی و البته بهترین روش برای کار با دیتابیس نیست.
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
نقل قول:
به طور کلی Unit of Work کاربرد خیلی کمی داره. یعنی جایی که واقعا بهش نیاز پیدا خواهید کرد کمه.
در رابطه با این موردی که گفتین یه مثال میزنم:
فرض کنید یه نرم افزار داریم واسه مدیریت کردن مشتری ها.حالا وقتی یه مشتری قراره ثبت بشه علاوه بر ثبت مشخصات فردی توی براش سال مالی،ایجاد شناسه کاربری و ممکنه کلی جدول دیگه دست خوش تغییر بشه.
حالا اینجا اگه قرار باشه برای هر تراکنش یه کانکشن به دیتابیس زده بشه خیلی ناجور میشه، ولی با UOF میشه با یک بار رفتن و اومدن به دیتابیس همه این عملیات رو ثبت کرد
الان این برداشتی که من داشتم غلطه به نظرتون یا درست گفتم؟
ولی وقتی قراره یه CMS بنویسیم دیگه UOF معنی نداره و کار اضافیه..چون زیاد پیچیده نیست کلا رکوردها با CRUD میتونن هندل بشن. و دیگه اینجا نیازی به UOF نیست در حد همون ریپازیتوری کفایت میکنه
نظر شما درباره اون مورد اول که گفتم چی هست؟
پیشاپیش تشکر:لبخندساده:
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
اگه شما با mvc کار میکنید یا wpf فقط در صورتی که با repository و unitofWork کار می کنید می تونین نرم افزار آرمون پذیر بنویسید.
مطلبی که تو لینک زیر هست رو دقیق با سوال و جواب هاش مطالعه کنید.نظر شخصی من اینه که رعایت کردن مواردی مثل تزریق وابستگی (IOC) در پروژه های وب الزامی هستش و قوانین Solid باید در هر پروژه ای رعایت بشن. و یکی از دلایلش Reusability بهتر و از بین بردن وابستگی محکم درپروژتون هستش استفاده از Domain Driven و CQRS از پیشنهادات خود ماکروسافت هستش
لینک اول
در مورد unit of work هم مطالب موجود در لینک زیر رو مطالعه کنید و به
What is the use of Unit of Work design pattern? و
What is “Work” and “Unit” in a software application? دقت بیشتری بکنید.
لینک دوم
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
نقل قول:
نوشته شده توسط
Maryam_1368
در رابطه با این موردی که گفتین یه مثال میزنم:
فرض کنید یه نرم افزار داریم واسه مدیریت کردن مشتری ها.حالا وقتی یه مشتری قراره ثبت بشه علاوه بر ثبت مشخصات فردی توی براش سال مالی،ایجاد شناسه کاربری و ممکنه کلی جدول دیگه دست خوش تغییر بشه.
حالا اینجا اگه قرار باشه برای هر تراکنش یه کانکشن به دیتابیس زده بشه خیلی ناجور میشه، ولی با UOF میشه با یک بار رفتن و اومدن به دیتابیس همه این عملیات رو ثبت کرد
پیشاپیش تشکر:لبخندساده:
بازهم نیازی به استفاده از این روش ندارید. کاری که Repository و UnitOfWork انجام میده همون کاری هست که EntityFramework داره انجام میده. شما می توانید چند شی رو همزمان و با یک بار اتصال از طریق EF ذخیره سازی کنید. بجای اینها یک لایه ی سرویس پیاده کنید و کدهارو بر اساس اون پیش ببرید.
شما زمانی به UnitOfWork نیاز دارید که نیاز به لایه ی Repository داشته باشید. در دات نت این لایه با جدا کردن اشیای EntityFramework انجام میشه.
در واقع شما چند شی که درون DbContext هست
و دارن با هم کار میکنن (تراکنش پذیر هستند)رو با لایه ی Repostitory از هم جدا می کنید و بعد برای اینکه دوباره اونها رو تراکنش پذیر کنید با استفاده از UnitOfWork به هم میچسبونید. مثل اینکه لقمه رو دور سر خودتون بچرخونید.
چرا از لایه ی ریپوزیتوری استفاده میشه ؟
1- در تیم های برنامه نویسی بزرگتر یک یک یا چند نفر وظیفه مستقیم پیاده سازی لایه ی دیتای پروژه رو به عهده دارند بهتره لایه ریپوزیتوری وجود داشته باشه تا این افراد بتونن کدها و خروجی کارشون رو مجزا از سایر اعضای تیم مدیریت کنند.
2- وقتی پروژه اینقدر بزرگه که ممکنه برای بهینه سازی بجای استفاده از EntityFramework مستقیما به دیتابیس وصل شوید. یا از ابزار دیگری برای مپ کردن دیتابیس به پروژه استفاده کنید. یا حتی نیاز به پیاده سازی سیستم کش دارید و باید ابزاری مانند Redis را بکار بگیرید.
مسلما این اتفاق قرار نیست در همه جای پروژه بیوفته ولی وجود لایه ی ریپوزیتوری کمک میکنه بقیه ی لایه های متوجه تغییر روش دسترسی به دیتابیس نشوند و به راحتی تغییرات رو اعمال کرد بدون اینکه در لایه های بالایی خطایی پیش بیاد. وقتی صحبت از بزرگی پروژه میشه منظور پروژه هایی در ابعاد MS Azure است. پروژه هایی که چند صد میلیون کاربر دارند و صدها سرور در کشورهای مختلف عمل مدیریت دیتابیس را به عهده خواهند داشت. اگر پروژه ی شما قراره در یک سرور اجرا بشه نیازی به چنین کارهایی ندارید.
نکته دیگه اینکه شما همیشه می توانید در آینده ی پروژه لایه ی ریپوزیتوری را اضافه کنید. نیازی نیست که در روز اول پروژه کارهایی از این دست انجام دهید. بسته به نیازهایی که برای پروژه بوجود می آید کار خود را پیش ببرید.
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
به طور کلی هدف اصلی از الگوی واحد کار یا UnitOfWork به اشتراگ گذاشتن یک Context بین همه نمونه‌های ساخته شده از Repository یا سرویس‌های برنامه است. فرض کنید در یک کنترلر شما از دو یا سه نمونه از سرویس‌ها یا Repositoryها وهله سازی کرده اید. اگر قرار باشد برای اعمال تغییرات، مجبور به فراخوانی متد Save هر Repository باشیم چرا اصلا الگوی واحد کار را به کار بردیم؟ فراخوانی SaveChanges الگوی واحد کار معادل است با فراخوانی متد‌های Save تمام Repositoryهای وهله سازی شده در طی یک درخواست.
نقل قول: پیکر بندی EF Codefirst و الگوی Unit Of Work
یک نمونه پروژه UnitOfWork در این خصوص:
