
ایجاد Repository ها
امروزه راه حل مناسب برای جداسازی لایه دسترسی داده ها از Domain Model استفاده از مفهومی به نام repository است. اما این Repository چیست و چه موجودیت هایی باید در قالب یک Repository قرار بگیرند؟
برای جواب به این سوالات نیاز داریم تا با مفهمومی به نام های Aggregation آشنا بشیم.
همونطور که میدانیدDomain Model ها، نمایی از دیتابیس را به ما ارائه میدهند ولی راه حلی برای نحوه پیاده سازی مدل با استفاده از C# و SQL Server به ما ارائه نمیدهد به عبارت دیگر به ما نمی گوید درصورت بازیابی موجودیتی، چه موجودیت هایی دیگری نیز باید بازیابی شوند و یا در صورت حذف یک موجودیت کدام موجودیت ها نیز باید حذف گردند. اینها مواردی هستند که Domain Model ها پاسخی برای آن ندارند.
متدولوژی DDD یا Domain Driven Design که یکی از محبوب ترین متدولوژی ها در معماری MVC می باشد پاسخ خوبی برای سوالات بالا ارئه میدهد. بر اساس این متدولوژی موجودیت های مدل در گروه هایی دسته بندی میشوند که Aggregates نام دارند. یک Aggregate میتواند شامل یک یا چند موجودیت باشد و دارای یک موجودیت ریشه به نام Root Entity یا Root Aggregate است. یکی از قوانین متدولوژی DDD این است که موجودیت های خارج از Aggregate تنها میتواند با Root Entity ارتباط داشته باشند. سوالی که پیش میاد این است که Aggregateها را چطور نشخیص دهیم؟ راه تشخیص این است که این سوال را از خود بپرسید در زمان حذف یک موجودیت چه نمونه هایی دیگری باید حذف شوند. به عنوان مثال اگر در یک سیستم وبلاگ یک "پست" را حذف کنیم باید "نظرات" آن نیز حذف شوند اما اطلاعات کاربری که پست را ایجاد کرده نباید حذف شود پس "پست" و "نظرات" یک Aggregate خواهند بود و موجودیت "کاربر" یک Aggregate جدا خواهد بود.
دونستن این نکته مهم هست که بر اساس متدولوژی DDD لزوما ارتباطات موجودیت ها در پایگاه داده، مانند Domain Model نیست.
بنابراین براساس مستنداتی که گفته شد قراردادی که استفاده میشود این است: به ازای هر Aggregate یک کلاس repository تعریف میشود.
و نکته آخر اینکه کلاس های repository تنهای برای انجام اعمال چهارگانه معروف CRUD استفاده میشوند و متدهای آنها نباید شامل هیچگونه کد مربوط به تعیین منطق فرایند برنامه باشند.
دیدگاه کاربران