نحوه رفرنس دادن comment های customer از اگریگیت Product
سلام
من یه پروژه فروشگاهی دارم برای تمرین میزنم، بعد سر اینکه انتیتی Comment کجا باشه خیلی گیج شدم، اول اگریگیت روت بود به صورت تنها، بعد الان بُردمش توی اگریگیت Product اسمشم کردم ProductComment، من مشکلم اینجاست که میخوام یوزر یعنی Customer توی پروفایلش بتونه تمام کامنت هایی که زاشته رو ببینه.
گفتیم که مستقیم نمیتونیم یه لیست ProductComment رفرنس بدم توی کلاس یوزر، و باید آیدی رو فقط اضافه کنیم ن خود آبجکت رو، پس من الان باید یه پراپرتی اینجوری اضافه کنم به کلاس Customer؟
public class Customer
{
public List<long> CommentsIds { get; private set; }
}یعنی یه لیستی از آیدی های کامنت هایی که یوزر زاشته، این روش درسته بنظر شما؟ بعد الان من این لیست رو چجوری و کِی باید پُر کنم؟
موقع ایجاد یه کامنت باید بیام آیدیشو اضافه کنم به این لیست؟
بعدشم اینکه متود های AddComment, RemoveComment هم توی انتیتی Product هست، اونجوری اصلا اصولی هست که بیام یه کامنت به خود محصول اضافه کنم، بعد توی همون AddCommentCommandHandler (از CQRS استفاده میکنم) بیام آیدیه اون کامنت رو به این لیست کامنت های یوزر اضافه کنم؟
چون یکم منطق ها متفاوت هست، انگار 2 تا کار جدا انجام میدیم، میگم شاید اصل Single Responsibility Principle رو زیر پا بزاره این کار.
چجوری باید کامنت های یوزر رو توی انتیتیش رفرنس بدم؟
پاسخ ها
محمد اشرافی
سلام ، ببینید کلا کار رو اشتباه اومدین ، من عرض کردم خدمتتون بحث Query زدن کاملا جدا است و اصلا توی Query زدن دیگه Aggregate معنایی نداره و مستقیم از Context و خوده دیتابیس استفاده میکنیم ، و ممکنه شما توی یک Query لازم باشه از 3 تا Entity مختلف دیتا واکشی کنید.
حالا شما می خواین لیست کامنت هرو بهش نمایش بدین ، خوب Query میزنید روی Table کامنت ها و اونایی که UserId اش برابر باشه با Customer میگیرید و بهش نمایش میدین
باز هم میگم ، Domain Model هاتون رو بر اساس تفکر Query زدن نسازید ، Query روی دیتابیس زده میشه کاری به Aggregate ها نداریم
bzmind
ممنون استاد، اینکه میگید تفکر دیتابیسی نداشته باشید درسته واقعا، ولی من چون تازه کارم، یکم طول میکشه برام جا بیفته این مفهوم، از همین راهنمایی های ارزشمند شما استفاده میکنیم کم کم مدل هامونو بهتر میسازیم، ببخشید اگر سوالاتم مُبتدی و شاید کلا اشتباهه 😅
پس یعنی اصلا لازم نیست کامنت های یوزر رو توی پراپرتیزش رفرنس بدم؟ ینی هر وقت خواست ببینه یه کوئری بزنم بیام رو صفحه نمایش بدم؟
اینجوری که خیلی از Navigation Property ها بی فایده میشن، میشه هر وقت لازم شد یه کوئری زد آورد هرچی میخوایمو.
خب دیتابیسی هم فکر نکنیم، آدم با خودش میگه که خب الان یوزر مثلا قراره کامنت هاشو ببینه، بعد اولین کاری که میکنه میاد توی پراپرتی هاش یه Navigation property واسه کامنت های یوزر میزاره.
فقط در صورتی که فکر کنه به دیتابیس، بگه خب هر وقت یوزر خواست ببینه کامنت هاشو، یه کوئری میزنم میارمش، اون موقع میفهمه که Navigation Property ای که زاشته لازم نبوده اصن.
bzmind
منظورم از اینکه Navigation Property ها بی فایده میشن، یا بی معنی میشن، اینه که الان مثلا شما توی همین پروژه کتاب خوب که دارید میزنید
انتیتی Product الان یه لیست از ProductImage داره
خب ما میتونستیم اصلا همچین پراپرتی ای نزاریم
بجاش موقع نشون دادن عکس هاش، کوئری میزدیم و میرفتیم تو Table پروداکت ایمِیج ها، و اون image هایی که ProductId ایشون مساوی پروداکتمون بود رو میاریم نشون میدیم.
پس چرا دیگه از Navigation Property ها استفاده کنیم اصن؟
محمد اشرافی
اونا منطق برنامه رو کنترل میکنن ربطی به Query هامون ندارن
توی سیستم ما یک موجودیت وجود داره به نام Product که این Product دارای چندین عکس ه خوب توی نرم افزار هم باید این وجود داشته باشه
و خود Product این عکس هارو مدیریت میکنه ، و وجود یا عدم وجودشون به product بستگی داره
-----------------------------
اما توی معماری های Data Centric به این شکل نبود Navigation Property فقط برای دیتابیس مفهوم داشت و فقط برای Query زدن
ما داریم از Domain Centric استفاده میکنیم پس دیگه Navigation Property های اضافه لازم نداریم
bzmind
خب الان Product من هم کلا باید کامنت داشته باشه و وجود کامنت ها هم به پروداکت بستگی داره
ولی میگید توی پروداکت نباید پراپرتی کامنت بزارم،
خب این که منطق سیستممه، فقط بخاطر دیتابیس نیست، در این صورت میشه من توی کلاس پروداکت Navigation Property بزارم برای کامنت ها؟
اصن چجوری تشخیص بدیم که این تصمیمی که میگیریم منطقه سیستممونه یا فقط واسه دیتابیس داریم اینکارو میکنیم؟
چون اینکه یوزر هم کامنت داره، از دید من انگار منطق سیستم محسوب میشه ولی شما میگید که نیست.