الگوی واحد کار، کدفرست و ریپوزیتوری کدام روش بهتر است؟مفاهیم و توضیح هرکدام را ذکر کنید.
Printable View
الگوی واحد کار، کدفرست و ریپوزیتوری کدام روش بهتر است؟مفاهیم و توضیح هرکدام را ذکر کنید.
توضیحات درباره Unit Of Work و Repository و مثال های اون : http://bit.do/designPatterns
Code First :نقل قول:
در روش Code First شما کار را با ساختن کلاسهای مورد نظر شروع می کنید. سپس با ایجاد یک کنترلر برای این کلاس و انتخاب New Context یک کلاس Context جدید برای شما ایجاد می شود. سپس در web.config میبایست Connection String مربوطه (هم نام Context) را ویرایش کنید تا مشخصات اتصال به دیتابیس معین باشد. با اولین اجرای برنامه و رفتن به کنترلر مورد نظر دیتابیس و جداول مربوطه ایجاد خواهند شد!
ابتدا از پاسختون تشکر میکنم.
من در ابتدا با DBFirst کار میکردم اخیرا از کدفرست، میخوام بدونم کدوم روش بهتره،آیا کدفرست هم از الگوی کار پیروی میکنه؟ الگوی کار بهتره یا ریپوزیتوری؟
مطالعه کردم اما اونطور که باید متوجه نشدم
جایی دیده نشده که بگن Code First بهتره یا Database First ، اما اخیرا بیشتر افراد به سمت Code first میرن و با اون کار میکنن.نقل قول:
میخوام بدونم کدوم روش بهتره
در Code First هم از Repository و هم از Unit Of Work میتونید استفاده کنید .نقل قول:
آیا کدفرست هم از الگوی کار پیروی میکنه؟
بین این 2 الگو هم همینطور هست که بهتر وجود نداره . هرکدوم در بخش خودشون استفاده میشن . Unit Of Work برای عملیات Save و Repository برای Update , Add , ... استفاده میشن.نقل قول:
الگوی کار بهتره یا ریپوزیتوری؟
از پاسختون متشکرم.میشه بگید فرقUnit Of Work و Repository چیه؟ با اینکه با هردو میشه عملیات افزودن،حذف،ذخیره و... انجام داد اما در مقاله ای خوندم که میگفت از Repository استفاده نکنید!
هر سه مورد فوق بهمراه یکدیگر معنا پیدا میکنند یعنی از Unitofwork و Repository در کنار کلاسهای poco یا همون code first یک مجموعه تشکیل داده و عملیات CRUD کار با بانک اطلاعاتی را انجام می دهیم
مسلما Code First اجماع نظر و محبوب اکثر برنامه نویسا هست بخاطر انعطاف پذیری و مدیریت بیشتر و راحتی تغییرات برنامه هست
ولی در dbfirst اگر از روی دیتابیس مهندسی معکوس بشه و تبدیل به code first هم عالیه
وقتی ما چند عملیات متعدد مثلا درج حذف یا ویرایش داریم که ممکنه همزمان نیاز داشته باشیم در دیتابیس این عملیاتها رو ثبت کنیم
مثلا یک فاکتور فروش در نظر بگیرید
1- سربرگ فاکتور
2- جزئیات و اقلام فاکتور
3- جزئیات پرداخت وجه فاکتور
4- پرسنل
اگر 3 مورد اول 3 تا موجودیت و یا سه تا جدول بهم متصل در بانک برنامه باشند و چنانچه بخواهیم یک فاکتور فروش ثبت کنیم و همزمان ثبت رکورد جدید در جدول اشخاص هم داشته باشیم مسلما نیاز داریم برای همه این عملیات ها یک وهله سازی جدید بر روی دیتاکانتکست برنامه داشته باشیم
var context= new ApplicationContext()
{
var person= new personnel{
id=1000,
name="ali",
.
.
.
}
context.personnel.AddOrUpdate(person)
//عملیات ویرایش پرسنل و ریختن در حافظه
Context.SaveChange()//ثبت در دیتابیس
}
var context= new ApplicationContext()
{
//عملیات ثبت سند فاکتور و ریختن در حافظه
Context.SaveChange() اعمال تغییرات در دیتابیس
}
اینجا 2 نمونه از دیتاکانتکست برنامه ساخته شده و بعد از عمل ذخیره سازی دو تراکنش بر روی بانک برنامه توسط متد savechange که از متدهای ذاتی entity framework هست انجام میشه
برای ایتکه تبدیل به یک تراکنش واحد بشه و مراجعات به بانک برنامه کمتر شده و جامعیت بانک نیز باید در نظر داشته باشیم
برای این کار از الگویی بنام Unit Of work بهره میبریم تا همه عملیات با یک دیتاکانتکس واحد و طی یک SaveChange درون دیتابیس ذخیره شود.
نه اینکه به ازای هر عمل یک دیتاکانتکست جدا ساخته و استفاده کنیم
معمولا از اینترفیسها interface برای الگوی واحد کار استفاده میشه
به عنوان مثال یک interface میسازیم
public interface IUnitOfWork
{
} int SaveAllChanges();
و اگر یک کلاس دیتاکانتکست بدین صورت داشته باشیم و از IunitOfWork ارث بری کنیم
public class ApplicationDbContext : DbContext,IUnitOfWork
{
}
و در نهایت وهله سازی دیتاکانتکست در قسمت جنرال برنامه یا یک جای عمومی بدینصورت داشته باشیم
IUnitOfWork uow= new ApplicationDbContext();
فقط کافیه
uow.SaveAllChanges();
رو درون متدهامون صدا بزنیم و به این میگن UnitOfWork
و اما Repository
اگر درون کدهای بالا نگاه کنید نوشته شده عملیات ویرایش پرسنل یا ثبت سند فاکتور
context.personnel.AddOrUpdate(person)
متد AddOrUpdate یکی از توابع ef برای درج و ویرایش رکورد هست
معمولا برنامه نویسها میان کلاسهای جدا به ازای هر کلاس ef میسازند و متدهایی درونش پیاده سازی میکنند و اسمش میزارن Repository
در برخی موارد نیازی هم نیست برای ساختن Repository
مثلل نوشتن برنامه ساده یا کوچک
البته هدف از Repository یکی کاهش کدنویسی و تکرار کدهای شبیه به هم هست و دیگری برای اعمال تزریق وابستگی و لایه بندی نرم افزار هست
public class PersonRepository
{
public void AddPerson(personnel p)
{
DbSet<personnel> i;
i.AddOrUpdate(p)
}
}
personnel همون کلاس code first هست
DbSet یک کلاس جنریک درون Ef هست و کوئری های ef که معادل کوئری sql هست توسط اون ساخته شده و روی بانک برنامه اعمال میشه
و در نهایت متد Addperson توی کلاسها یا جاههای دیگه صدا میزنند
البته این رو بصورت ساده و خلاصه گفتم
Repository خوب و کارامدتر با interface ها پیاده سازی میشن و مباحثی همچون تزریق وابستگی یا dependency injection هم به میون میاد که بحث طولانی تری داره ولی خیلی کاربرد مفید و جذابی داره
نقل قول:
نوشته شده توسط ali_md110
بسیار بسیار ممنونم.خیلی خوب گفتید.مقالاتی خونده بودم و با مفهوم هرکدام کمی آشنا بودم اما نمیتونستم کنار هم اون مفهوم اصلی رو تشخیص بدم.ولی حالا مشکل برطرف شد:لبخندساده:
پس فرق چندانی ندارند و بسته به دفعات اتصال به بانک و نوع پروژه و سلیقه برنامه نویس یکی از این روش ها استفاده میشن.
مجددا تشکر
سلام
من در مورد Unit of work و Repository خیلی مطلب خوندم این موضوعی هم که شما مطرح فرمودید رو مطالعه کردم و جالب بود برام
موضوعات آموزشی رو هم مطالعه کردم
همه اول Repostitory ها رو میسازند و سپس UOW رو آموزش میدهند
یک موضوع رو متوجه نشدم
من یک دیتابیس دارم یک کلاس Ado.Net entity رو به پروزه اضافه کردم
حالا با توجه به الگوی Unit Of Work
این قطعه کد رو مینویسم
private CrudGenericRepository<Person> _Person;
public CrudGenericRepository<Person> Person
{
get
{
if (_Person== null)
{
_Person= new CrudGenericRepository<Person>(_db);
}
return _Person;
}
}
وقتی که اینجا دارم مستقیم به خود جدول person اشاره میکنم پس نقش repository چیه؟
و کجای این قضه به Repository ها مربوط میشه؟
اصلا چرا باید بسازمشون؟
سلام
من در مورد Unit of work و Repository خیلی مطلب خوندم این موضوعی هم که شما مطرح فرمودید رو مطالعه کردم و جالب بود برام
موضوعات آموزشی رو هم مطالعه کردم
همه اول Repostitory ها رو میسازند و سپس UOW رو آموزش میدهند
یک موضوع رو متوجه نشدم
من یک دیتابیس دارم یک کلاس Ado.Net entity رو به پروزه اضافه کردم
حالا با توجه به الگوی Unit Of Work
این قطعه کد رو مینویسم
private CrudGenericRepository<Person> _Person;
public CrudGenericRepository<Person> Person
{
get
{
if (_Person== null)
{
_Person= new CrudGenericRepository<Person>(_db);
}
return _Person;
}
}
وقتی که اینجا دارم مستقیم به خود جدول person اشاره میکنم پس نقش repository چیه؟
و کجای این قضه به Repository ها مربوط میشه؟
اصلا چرا باید بسازمشون؟
این قسمت زمانی مفید که توی یه اکشن با چندتا جدول سر و کار داری
مطلب زیر توی سایت مایکروسافت درج شده (لینک صفحه)
گفته که برای ef همیشه بهترین انتخاب نیست که از repozitory و unit of work استفاده بشه و دلایلش رو هم آورده
Create an abstraction layer
Many developers write code to implement the repository and unit of work patterns as a wrapper around code that works with the Entity Framework. These patterns are intended to create an abstraction layer between the data access layer and the business logic layer of an application. Implementing these patterns can help insulate your application from changes in the data store and can facilitate automated unit testing or test-driven development (TDD). However, writing additional code to implement these patterns isn't always the best choice for applications that use EF, for several reasons:
- The EF context class itself insulates your code from data-store-specific code.
- The EF context class can act as a unit-of-work class for database updates that you do using EF.
- EF includes features for implementing TDD without writing repository code.