جریان virtual‌قرار دادن وراورتی ها در mvc چیه؟

[EnKamran]

سلام.
ببخشید دوتا سوال داشتم
یکی اینکه پراپرتی ها رو توی کلاسهای موجودیت ها چی هستن؟
public virtual int Id {get;set;}
و اینکه جای قرار گیری هر لایه به چه صورته؟
یعنی مثلا چیزی که من فهمیدم :
۱. یک پروژه کلاس لایبرری برای موجودیت ها
۲. پروژه وب برای خود سایت
که توی پروژه وب سایت مدل ویو مدل هم درست میکنیم (نمیفهمم مگه تو پروژه کلاس لایبرری موجودیت ها رو تعریف نکردیم؟ پس ویو مدل چیه؟)
من مشکل زبان ندارم میشه یه منبع مفهومی معرفی کنید؟
ببینید خود سایت asp.net آموزشاتش رو میخونم اما اونها فقط میگن فلان پروژه رو درست میکنیم و فلان کارو میکنیم. نمیگن چرا.
ممنون

[بهزاد علی محمدزاده]

سلام .
یکی اینکه پراپرتی ها رو توی کلاسهای موجودیت ها چی هستن؟ این بخش از سوالت واضح نیست . یعنی کلا Property رو نمی دونی ؟ یا virtual رو می خوای بدونی ؟ Properties ها در کلاس های موجودیت ها صفات اون موجودیت هستند .

برای لایه بندی می تونی توی همون پروژه وب اگر پروژه ات کوچیکه کار کنی . ولی اگر می خوای لایه های جدا داشته باشی . در جستجوها به نمونه های فراوانی می رسی . من یه لایه بندی رو پیشنهاد می کنم :


Business
Data
DataAccess
Common
Web


در لایه Business دو پوشه ایجاد کن . یکی رو بذار Models و یکی رو بذار Services . اینها logic پروژه شما هستند . لایه سرویس مثلا کلاسی داره برای درج محصول ویرایش و حذفش و ... اونوقت هر منطقی که داری رو اونجا پیاده سازی می کنی . (البته یه لایه هم باید برای تست داشته باشی که من نذاشتم برات گفتم شاید هنوز سراغش نرفته باشی)

http://www.uploadax.com/images/24471554646256048957_thumb.png (http://www.uploadax.com/viewer.php?file=24471554646256048957.png)

پوشه Models جای همون ViewModel هاست . درک ViewModel از نان شب واجب تره . می بایستی درکش کنی . فرض کن شما می خوای محصول رو حذف کنی . کل محصولات رو هم در قالب جدول داری به کاربر نشون میدی . جالا شما چرا تمام مشخصات محصول رو ارسال کنی به صفحه ایی که فقط نام و کد و شاید تاریخ رو نیاز داره ؟ پس یه ViewModel برای اون قسمت ایجاد می کنی . و اون و به سمت کاربر ارسال می کنی . باید باهاش کار کنی تا دستت بیاد . ولی دورش نمیشه زد .

عمومی های برنامه رو می تونی توی Common قرار بدی . مثلا Helpers ها و Filters ها و ... لایه Data همون موجودیت ها رو نگهداری می کنه . لایه DataAccess ارتباط با بانک و Context رو اونجا تعریف کن . همچنین Map ها ( یعنی تنظیم روابط بین موجودیت ها . مثل یک به چند و ... ) رو هم در این لایه ایجاد کن .

اما برای پروژه های کوچیک میشه اینها رو بصورت پوشه توی همون پروژه Web تعریف کرد .

برای آموزش من یه تاپیک ایجاد کرده بودم که توش معرفی یه کانال ویدیویی هست . 100 قسمت آموزش asp.net mvc رو گفته و بسیار عالی هم هست . اونها رو دانلود کن و حتما ببین .

[aroshanzamir]

اول اینکه در MVC معماری رعایت شده Model View Controller ....

تعریف Property خیلی جا ها کاربرد داره . مثلا برای انجام عملیات مثل درج و .....

شما یه جدول به برای استان دارید و یه جدول دیگه برای شهرستان ها


جدول استان :شامل فیلد های :ID ,Province
//شماره و نام استان

جدول شهرستان :شامل فیلد های ID,ID_Province,City
//شماره و شماره استان(کلید خارجی) و شهر

با توجه به فیلد های دو جدول دو کلاس ایجاد می کنیم :


public class Province_
{
public int ID { get; set; }
public string Province { get; set; }
}
public class City_
{
public int ID { get; set; }
public virtual int ID_Province { get; set; }
public string City { get; set; }
}


Property ID_Province را Virtual تعریف کردیم به دلیل اینکه کلید خارجی می باشد

مابقی کار ها کار کردن با کلاس ها می باشد.

[Amir Oveisi]

این موردی که مد نظر شما هست ربطی به MVC نداره و مربوط به شیوه Code-First در Entity Framework هست. زمانی که شما یک Navigation Property رو به صورت virtual تعریف میکنید در واقع دارید به EF میگید که Lazy Loading رو بر روی اون property فعال کنه. اگر virtual تعریف نکنید از مزایای Lazy Loading بی بهره میمونید.
در صورتی که نیاز به اطلاعات بیشتری دارید توصیه میکنم در تالار Entity Framework به دنبال توضیحات بیشتر بگردید.

[Amir Oveisi]

در مورد دلیل استفاده از ViewModel با وجود اینکه Model ها رو داریم به این نکته باید دقت کنید که همیشه چیزهایی که در یک View قرار هست نمایش داده بشن، صرفا Model ها نیستند بلکه اکثر اوقات شما بنا به دلیل های متفاوتی نیاز پیدا خواهید کرد که یک سری اطلاعات بیشتر یا کمتر از اون چیزی که مدل شما داره رو در View نمایش بدید. بنابراین راه اصولی حل این مساله این هست که ما مدل ها رو دستکاری نکنیم و بزاریم اون ها صرفا مدل خالص باشند (منظور از خالص این هست که نیاز های نشات گرفته از View نباید رو مدل تاثیر بزاره و اونا رو تغییر بده) و بجاش ViewModel های متناظر هر View رو ایجاد میکنیم و هر چیزی که لازم داریم در داخل اون ViewModel تعریف کنیم تا در View نمایش داده بشه. ممکنه یک سری از این چیزا! که در ViewModel هستن همونا باشن که در مدل هم هستن و بعضی دیگشون تو مدل نیستن.
به عنوان مثال خیلی ساده فرض کنید شما یک مدل دارید برای یک کتاب که 30 تا property داره. توی یک View شما میخواید اطلاعاتی در مورد اون کتاب رو نمایش بدید اما بنا به نیاز شما فقط لازم هست که 5 تا از اون 30 تا property نمایش داده بشه. آیا منطقی هست که شما یک مدل با 25 تا property بلا استفاده رو بفرستید به View؟ بهتر نیست به جای اینکار یک ViewModel برای کتاب ایجاد کنید و فقط اون 5 تا Property که لازم دارید رو توش تعریف کنید و اون رو بفرستید به View ؟

[EnKamran]

راستش اصلا فکر نمیکردم دوستان به این خوبی جواب بنده رو بدن، از همه عزیزان تشکر میکنم کاملا درک کردم.
دوست عزیزم بهزاد، بله من خود virtual رو میخواستم ببینم چرا استفاده میشه که دوستمون aroshanzamir گفتند برای کلید خارجی و Amir Oveisi عزیز هم توضیج دادند که برای استفاده از Lazy Loading بدرد میخوره.
مثالهایی که زدید عالی بود کاملا متوجه شدم.
یک دنیا ممنون.

[Amir Oveisi]

به این نکته دقت کنید که برای تعریف کلید خارجی در Code-First نیازی به استفاده از virtual نیست. بلکه EF از روی Naming Convention و یا Attribute هایی که برای Property مشخص کردید و یا اینکه با استفاده از Fluent API تعریف کردید، تشخیص میده که کلید خارجی ها کدوم هستند.
بنابراین virtual هیچ ارتباطی به مشخص کردن کلید خارجی نداره.