هنگامی که مایکروسافت برای اولین بار Framework Entity را منتشر کرد ، توسعه دهندگان Agile با انتقاد از آن انتقاد کردند. این توسعه دهندگان اصول توسعه و تست دامنه محور را بسیار بالا دارند. کلاسهای تولید شده از مدل داده های موجود (EDM) با ارث بردن از EntityObject یا پیاده سازی هایی که به کلاس ها اجازه می دهند در تغییر ردیابی و مدیریت روابط شرکت کنند ، بسیار محکم به API های Framework Entity محدود می شوند.
مشکل این امر این است که جدا کردن نگرانی های برنامه شما در بخش های کوچکتر از منطق بسیار دشوار است تا بتوانید آن را حفظ کنید. علاوه بر این ، نوشتن تست های واحد با EntityObjects دشوار است. بسیاری از روش هایی که باید آزمایش شوند ، نوعی تعامل با پایگاه داده را انجام می دهند. در آزمایش واحد ، شما باید این پایداری را تقلید کنید. به عبارت دیگر ، به جای اینکه به معنای واقعی کلمه از پایگاه داده پرس و جو کنید ، یک آزمایش ممکن است برخی از داده های جعلی را به یک کلاس عرضه کند ، یا به جای ارسال داده به فروشگاه داده ، یک آزمایش ممکن است بگوید "خوب ، بیایید وانمود کنیم که این قسمت فقط اتفاق افتاده است و ما حرکت خواهیم کرددر حال حاضر."
تیم Framework Entity در مورد این و سایر نشریات نمایش دهنده از جامعه چابک گوش فرا داد و یاد گرفت و تعدادی از مکانیسم های جدید را برای حمایت از توسعه چابک اضافه کرد.
یکی از این موارد پشتیبانی از اشیاء قدیمی CLR قدیمی (POCO) است. POCO کلاس هایی هستند که از زیرساخت های پشتیبان مانند Framework Entity عاری هستند. یک کلاس POCO از EntityObject Entity Framework به ارث نمی برد. اما همانطور که دیدید ، EntityObject تمام کارهای مهم را برای ارائه روابط و تغییر اطلاعات ردیابی به متن انجام می دهد. به منظور از بین بردن وابستگی به EntityObject ، چارچوب Entity برخی از قابلیت های جدید را به دست آورد که به ObjectContext اجازه می دهد تا رابطه را به دست آورد و اطلاعات ردیابی را از کلاس هایی که از EntityObject به ارث نمی رسند ، تغییر دهد. در واقع ، همانطور که خواهید دید ، می تواند این کار را با کلاس هایی انجام دهد که هیچ دانش در مورد چارچوب موجودیت ندارند.
علاوه بر پشتیبانی POCO ، این تیم دو ویژگی مهم دیگر را برای توسعه دهندگان که نمی خواهند با نگرانی های پایگاه داده گره خورده باشند ، اضافه کرد. یکی پشتیبانی از توسعه مدل اول است که به توسعه دهندگان اجازه می دهد یک پروژه را با یک مدل شروع کنند و از آن مدل برای ایجاد یک پایگاه داده استفاده کنند. دیگری با نام کد-اولین توسعه نامیده می شود. کد اول هنوز یک کار در حال انجام است و به عنوان بخشی از بارگیری جداگانه به نام The Entity Framework CTP در دسترس است.
در این مقاله، اصول اولیه نحوه ایجاد و کار با POCO ها در Entity Framework را خواهید آموخت. دو راه برای پشتیبانی POCO وجود دارد. شما با ساده ترین شکل شروع می کنید، که به کمی کار اضافی در قسمت ObjectContext نیاز دارد. سپس با شکل دیگری از پشتیبانی POCO آشنا خواهید شد که به POCO ها اجازه می دهد در زمان اجرا مشابه EntityObjects رفتار کنند.
شما با ساده ترین شکل شروع می کنید، که به کمی کار اضافی در قسمت ObjectContext نیاز دارد. سپس با شکل دیگری از پشتیبانی POCO آشنا خواهید شد که به POCO ها اجازه می دهد در زمان اجرا مشابه EntityObjects رفتار کنند.
ایجاد کلاس های POCO
کلاسهای POCO در ارتباط با یک مدل کار می‌کنند، زیرا باید موجودیت‌های موجود در مدل را منعکس کنند.
برای شروع این بحث، از SampleModel که یک مدل و پایگاه داده بسیار ساده است، استفاده خواهم کرد. برای اطلاعات در مورد دانلود این پایگاه داده، به نوار کناری «دریافت پایگاه‌های داده نمونه» مراجعه کنید. بیایید مدل و سپس کلاس ها را ایجاد کنیم، زیرا اشاره به ارتباط آنها با یکدیگر مفید خواهد بود. این احتمال وجود دارد که ابتدا کلاس ها را ایجاد کنید یا حتی از قبل وجود داشته باشند.
** توجه: ** POCO و کلاس های مرتبط ایجاد شده در این مقاله به صورت دستی ساخته شده اند. اگر با یک مدل شروع می کنید، استفاده از الگوی T4 برای تولید کلاس های POCO از مدل بسیار منطقی تر است.
با ایجاد یک پروژه جدید Console Application شروع کنید. سپس یک Entity Data Model جدید بر اساس ProgrammingEntityFrameworkDB1 اضافه کنید. نام EntityContainer را POCOEntities بگذارید و همه جداول را انتخاب کنید. اکنون به مدل ساده خود بازگشته اید.
چند قانون وجود دارد که باید هنگام ایجاد کلاس هایی که با Entity Framework تعامل دارند، رعایت کنید. یکی این است که نام کلاس و ویژگی باید با مدل هماهنگ باشد. دیگری این است که هر ویژگی موجود در مدل باید در کلاس نمایش داده شود. این شامل ویژگی های اسکالر و ویژگی های ناوبری است. برای این مثال، ما فقط از مدل موجود، نشان داده شده در شکل 1 پیروی می کنیم تا نام و ساختار کلاس ها را تعیین کنیم.
شکل 1: مدل ساده ای که در مثال های زیر از آن استفاده خواهیم کرد.
دو فایل کلاس جدید به نام های Contact. cs و Address. cs به پروژه اضافه کنید. در مرحله بعد، برای هر ویژگی موجود در نهاد Contact، ویژگی هایی را به کلاس Contact اضافه کنید.
مطمئن شوید که نام ها و همچنین انواع آن را با یک نکته تقلید کنید. ویژگی Addresses navigation یک EntityCollection را برمی گرداند که یک نوع بسیار محدود است. در کلاس خود، از یک ICollection برای برگرداندن مجموعه مرتبط استفاده کنید. هنگامی که کلاس را مصرف می کنید، یک ICollection به شما انعطاف پذیری نهایی را می دهد.
در اینجا قطعه کد برای کلاس Contact آمده است. توجه داشته باشید که از ویژگی‌های پیاده‌سازی خودکار استفاده می‌کند، که برای حفظ مقادیر خود به متغیر پشتیبان نیاز ندارند.
داشتن ویژگی‌های اضافی مانند جنسیت و متدها در کلاسهای POCO کاملاً قابل قبول است. تا زمانی که خصوصیات موجودیت را به حداقل می‌رسانید، کلاس‌ها در چارچوب Entity کار می‌کنند.
اکنون که شما کلاس های خود را دارید، دیگر نیازی به تولید کلاس های مدل نیست. می توانید تولید کد را خاموش کنید.
مدل را در Designer باز کنید. در پنجره Properties مدل، ویژگی Code Generation Strategy را از Default به None تغییر دهید. همانطور که در فصل قبل آموختید، فایل کلاس پیوست شده به مدل همچنان وجود خواهد داشت، اما فقط حاوی یک نظر به عنوان یادآوری است که تولید کد از مدل غیرفعال شده است.
به خاطر این نسخه ی نمایشی ساده، از شما می خواهم همه چیز را در یک پروژه واحد قرار دهید. این روش مناسبی برای طراحی این نوع راه حل نیست، بلکه روشی ساده تر برای آشنایی با مفاهیم اولیه است.
یک کلاس جدید به نام Entities ایجاد کنید و کد را در لیست 1 اضافه کنید. این کلاسهای ObjectContext را شبیه‌سازی می‌کند که در فصل‌های قبلی کتاب هستند که این مقاله از آنها استخراج شده است.
کلاس Entities از ObjectContext به ارث می برد، درست مانند سایر کلاس های Entities که تاکنون دیده اید. سازنده کلاس از امضای ObjectContext استفاده می کند که نام رشته EntityConnection در فایل app. config و همچنین نام EntityContainer در مدل را می گیرد. همانند سایر کلاسهای Entities، این کلاس حاوی ویژگی‌های فقط خواندنی است که یک ObjectSet از هر نوع که می‌خواهید با آن کار کنید، برمی‌گرداند. فیلدهای این ویژگی های ObjectSet در سازنده کلاس نمونه سازی می شوند. به یاد داشته باشید، این فقط ObjectSet را تعریف می کند اما یک پرس و جو را اجرا نمی کند.
بررسی POCO ها با یک پرس و جو
اکنون می توانید اولین پرس و جوهای خود را بنویسید تا ببینید چگونه همه اینها با هم هماهنگ می شوند.
در ماژول اصلی برنامه، کد زیر را اضافه کنید، که ObjectContext جدید شما را نمونه سازی می کند، برای همه مخاطبین پرس و جو می کند، آدرس آنها را مشتاقانه بارگذاری می کند و سپس به آدرس های یک مخاطب نگاه می کند.
اگر از این طریق اشکال زدایی کنید ، خواهید دید که همه مخاطبین به لیست Contactlist بازگردانده می شوند و اولین تماس دارای یک آدرس در مجموعه آن است.
تغییر ردیابی با POCO
به خاطر داشته باشید که دو روش برای استفاده از POCO وجود دارد. شما از اینجا با ساده ترین شکل شروع می کنید. فصلی که از آن این مقاله گزیده شده است ، شامل نمونه ای نیز است که روش بسیار متفاوتی از تعامل با ObjectContext را نشان می دهد.
هنگامی که شما یک پرس و جو را انجام می دهید که منجر به موجودات POCO می شود ، ObjectContext دقیقاً مانند آنچه با یک EntityObject انجام می دهد ، اشیاء ObjectStateEntry را برای هر نتیجه ایجاد می کند. با این حال ، کلاس هایی که از EntityObject به ارث می برند ، به طور مداوم با ObjectContext در تعامل هستند ، بنابراین زمینه قادر به پیگیری وضعیت کلاس ها و همچنین روابط آنها با یکدیگر است.
POCO ها به متن ارتباط نمی دهند. بنابراین ، زمینه در بعضی از نقاط باید به POCO ها نگاهی بیندازد و داده های آنها را با اشیاء ObjectStateEntry که نمایانگر آنهاست ، همگام سازی کند. کلاس ObjectContext روشی به نام DetectChanges دارد که این هدف را برآورده می کند.
درک اهمیت تشخیص
مهم است که به این زمینه دستور دهید قبل از ساخت دستورات مختلف SaveChanges ، هنگامی که می خواهید هرگونه تغییر در POCO های خود را به پایگاه داده ارسال کنید ، تغییرات را تشخیص دهید. در غیر این صورت ، اشیاء ObjectStateEntry که زمینه در آن مدیریت می شود ، منعکس کننده تغییرات نیست و هیچ درج ، به روزرسانی یا حذف دستورات به فروشگاه داده ارسال نمی شود.
روش SaveChanges می تواند یک پارامتر SaveOptions اختیاری را بگیرد. یکی از پارامترهای SaveOptions DetectAllChanges نامیده می شود. این گزینه زمینه را وادار به فراخوانی DetectChanges قبل از منطق ذخیره می کند. رفتار پیش فرض برای SaveChanges این است که آن را DetectChanges می نامد ، بنابراین نیازی نیست که صریحاً با روش تماس بگیرید یا Enum SaveOptions را تنظیم کنید.
رفتار پیش فرض برای SaveChanges این است که آن را DetectChanges می نامد ، بنابراین نیازی نیست که صریحاً با روش تماس بگیرید یا Enum SaveOptions را تنظیم کنید.
بارگیری داده های مرتبط با POCO
هنگام کار با EntityObjects، می توانید داده های مرتبط را به طور صریح با روش EntityCollection. Load یا روش EntityReference. Load بارگیری کنید یا از مزیت بارگذاری تنبل برای وارد کردن داده های مرتبط بدون ایجاد پرس و جو جدید استفاده کنید. با POCO هایی که به تازگی ساخته اید، نمی توانید این کار را انجام دهید. ویژگی های پیمایش دیگر EntityCollections یا EntityReferences نیستند، بنابراین روش Load در دسترس نیست. همچنین کلاس EntityCollection و EntityReference است که Entity Framework را با قابلیت بارگذاری تنبل خود ارائه می دهد. بدون این نوع در کلاسهای خود، به مکانیسم دیگری برای بارگیری داده‌ها بعد از این واقعیت نیاز خواهید داشت.
بارگیری از زمینه
همانطور که قبلا ذکر شد، بسیاری از پشتیبانی POCO Entity Framework بر اساس قابلیت های جدید ObjectContext است. در دات نت 4، ObjectContext یک روش جدید به نام Load-Property دارد و به این صورت است که می توانید به طور صریح داده ها را با POCO های خود بارگذاری کنید.
به جای فراخوانی Load در یک ویژگی ناوبری (به عنوان مثال contact. Address. Load)، می‌توانید به Context اجازه دهید بارگذاری را با نحو زیر انجام دهد:
این اضافه بار از ژنریک برای مشخص کردن نوع بارگیری شده از () استفاده می کند تا بتوانید از تایپ قوی برای استفاده از لامبدا برای تعیین اینکه کدام ویژگی باید بارگیری شود (c. Addresses) بهره مند شوید. به دلیل تایپ قوی، IntelliSense به شما کمک می کند تا عبارت لامبدا را بسازید. چند اضافه بار دیگر برای این روش وجود دارد که می توانید آنها را در http://msdn. microsoft. com/en-us/library/dd382880. aspx بیابید. با این حال، من ترجیح می دهم از لامبدا استفاده کنم.
بارگیری تنبل از یک پروکسی پویا
اگر می خواهید رفتار بارگذاری تنبلی برای POCO خود داشته باشید، باید از ترفند ارائه شده توسط Entity Framework زمان اجرا استفاده کنید. با علامت‌گذاری یک ویژگی ناوبری به‌عنوان مجازی (قابل تغییر در ویژوال بیسیک)، در زمان اجرا، Entity Framework یک پوشش در اطراف آن ویژگی ایجاد می‌کند که آن را به یک EntityCollection یا EntityReference (در صورت لزوم) تبدیل می‌کند. بنابراین، اگر بارگذاری تنبل را فعال کرده باشید، به سادگی همانطور که انتظار می رود کار می کند.
بررسی و تصحیح تأثیر POCOها بر روابط دو طرفه
توسعه دهندگانی که با EntityObjects کار می کنند انتظار دارند که روابط دو طرفه به طور خودکار در دسترس باشد. به عنوان مثال، اگر ویژگی تماس یک شی Address را تنظیم کنید، آن آدرس به طور خودکار بخشی از مجموعه آدرس های مخاطب می شود.
این رفتار به خودی خود با کلاس های POCO شما اتفاق نمی افتد. برای اعمال این رفتار یا باید کد اضافی بنویسید یا منتظر تماس DetectChanges باشید که "تعیین" را از طرف شما انجام می دهد.
اطلاعات دقیق تری در مورد این ارائه شده در فصل وجود دارد که از آن این مقاله گزیده شده است.
استفاده از پروکسی ها برای فعال کردن اعلان تغییر ، بارگذاری تنبل و رفع روابط
همانطور که قبلاً خوانده اید ، DetectChanges همچنین زمینه را برای به روزرسانی اشیاء ObjectStateEntry که برای ردیابی تغییر استفاده می کند ، به روز می کند. هنگامی که شما به DetectChanges می پردازید ، زمینه عکس فوری از وضعیت فعلی موجودات را می گیرد.
این امکان وجود دارد که اشخاص را مجبور به اطلاع رسانی در زمینه تغییرات کنند تا نیازی به صبر کردن تا زمانی که شما (یا روش SaveChanges) با ردیابی تماس بگیرید.
شما می توانید این کار را با استفاده از یک ویژگی خاص از Framework Entity انجام دهید که کلاس ها را قادر می سازد توسط یک کلاس ویژه پروکسی در زمان اجرا پیچیده شوند. برای استفاده از این ، شما باید هر ویژگی موجود در کلاس را به عنوان مجازی علامت گذاری کنید. در VB ، این بسیار قابل مشاهده است.
در زمان اجرا ، Entity Framework از بازتاب استفاده می کند تا متوجه شود که شما خواص را به عنوان مجازی مشخص کرده اید و یک کلاس پویاپروکسی را در پرواز ایجاد می کند و سپس آن را مجبور می کند تا از موجودیت خود به ارث ببرد. شکل 2 پروکسی زمان اجرا را برای یک کلاس تماس در اشکال زدایی نشان می دهد.
شکل 2: یک شی تماس در زمان اجرا با یک بسته بندی پروکسی پویا.
الگوی POCO کلاسهای نسبتاً ساده ای را با تمام خصوصیات خود که به عنوان مجازی مشخص شده اند ، ایجاد می کند و آنها را مجبور می کند از کلاس های پویا در زمان اجرا استفاده کنند.
این پروکسی عملکردی را به کلاس POCO زمان اجرا اضافه می کند که دارای بسیاری از ویژگی های یکسان به عنوان یک EntityObject است. اما همانطور که در ادامه خواهید دید ، این یک نهاد نیست. این چیزی کاملاً متفاوت است.
استفاده از پروکسی ها به طور خودکار کلاس های شما را با رفع خودکار خودکار ارائه می دهد. در عین حال ، شما همچنین بسیاری از رفتارهای مشابه توسط EntityObject ، مانند اعلان تغییر و بارگذاری تنبل را به دست می آورید (یا دوباره به دست می آورید).
شما می توانید جزئیات بیشتری را در مورد چگونگی فعال کردن پروکسی های زمان اجرا ، اعلان تغییر خودکار ، بارگذاری تنبل و همگام سازی روابط در فصل که این مقاله از آن گزیده شده است ، بخوانید.
با استفاده از T4 برای تولید کلاس های POCO
کتابی که از آن این فصل گزیده شده است ، استفاده از الگوهای T4 برای تولید کد را نشان می دهد. این کار زیادی برای خنثی کردن الگوی پیش فرض T4 Framework Entity Framework برای مجبور کردن آن برای ایجاد اشیاء ساده است. اگر از مراجعه به دندانپزشک لذت می برید ، ممکن است خودتان علاقه مند باشید که خودتان این کار را انجام دهید. با این حال ، مایکروسافت قالب هایی را ایجاد کرده است که Framework Entity Pocos را از EDMX می سازد. شما می توانید با یکی از آن ها شروع کنید و سپس الگوی را بیشتر تغییر دهید تا کلاس هایی ایجاد کنید که از الگوی مورد نظر شما پیروی کنند.
متأسفانه ، الگوهای POCO هنگام نصب Visual Studio 2010 RTM "در جعبه" نیستند ، اما اضافه کردن آنها بسیار آسان است. مایکروسافت دو جفت الگوهای POCO ایجاد کرده است که از Visual Studio 2010 Manager در دسترس است. اگر به دنبال POCO در مدیر پسوند هستید ، اولین جفت "Microsoft Ado. net C# Poco Entity Generator" و "Microsoft Ado. net VB Poco Entity Generator" متداول هستند. جفت دوم به طور خاص برای وب سایت ها است و من روی آن تمرکز نمی کنم. همچنین می توانید مستقیماً به http://www. visualstudiogallery. com/ برای بارگیری پسوندهای ویژوال استودیو مراجعه کنید.
پس از نصب یک پسوند Generator Poco Entity ، الگوی ژنراتور Ado. net Poco Entity در هنگام انتخاب اضافه کردن یک مورد تولید کد به مدل خود گزینه ای خواهد بود. انتخاب این الگوی ، در واقع ، دو قالب را به پروژه شما اضافه می کند. یک الگوی ، با گسترش Breakaway. context. tt ، به طور خاص برای تولید کلاس ObjectContext است. دیگری ، Breakaway. tt ، کلاس های موجودیت را تولید می کند. شکل 3 دو الگوی جدید موجود در Solution Explorer را به همراه کلاس های موجودی به طور خودکار تولید شده نشان می دهد.
شکل 3: دو قالب اضافه شده توسط ژنراتور موجودیت Ado. net Poco به همراه کلاس های تولید شده آنها.
متوجه خواهید شد که هم زمینه و هم الگوی موجودیت در پروژه مدل قرار دارند. اگر برای جدا کردن نگرانی های برنامه خود معمار هستید ، احتمالاً نمی خواهید کلاس های موجودیت را در همان پروژه با مدل و لایه پایداری قرار دهید.
قالب POCO کلاسهای نسبتاً ساده‌ای ایجاد می‌کند که تمام ویژگی‌های آنها به‌عنوان مجازی علامت‌گذاری شده‌اند، و آنها را مجبور می‌کند تا از کلاسهای DynamicProxy در زمان اجرا استفاده کنند. علاوه بر این، کدی را اضافه می کند تا اطمینان حاصل شود که هر کلید خارجی با ویژگی ناوبری مربوطه خود هماهنگ می شود. و در نهایت، کدی برای حفظ اصلاحات روابط دو طرفه مشابه آنچه قبلا در این فصل دیدید، وجود دارد، اگرچه آنها از کلاسی به نام FixUpCollection استفاده می کنند که در BreakAway. cs خواهید یافت.
فهرست 2 فهرست کاملی را برای کلاس پرداخت ایجاد شده نشان می دهد. به کد موجود در ReservationID توجه کنید که خاصیت Reservation را با کلید خارجی ReservationID همگام نگه می دارد. علاوه بر این، می‌توانید کد اصلاحی را ببینید که در صورت لزوم، Payment را به مجموعه Reservation. Payments اضافه یا حذف می‌کند.
با نگاهی اجمالی به کلاس Customer ایجاد شده، متوجه خواهید شد که الگو همچنین تنظیمات مقدار پیش فرض را برای CustomerID خوانده و آن را اعمال کرده است:
راهنمای اضافی در فصل 13
در فصلی که این مقاله از آن استخراج شده است، همچنین راهنمایی در مورد ایجاد مدلی که با کلاسهای از قبل موجود کار می‌کند و اشاره به ویژگی آتی «اول کد»، که در حال حاضر بخشی از پیش‌نمایش فنی انجمن Entity Framework است، خواهید یافت.(CTP).
خلاصه
در این مقاله با یکی از مهم ترین ویژگی های اضافه شده به Entity Framework در NET 4 آشنا شدید: پشتیبانی از کلاس هایی که از کلاس EntityObject ارث نمی برند. شما یاد گرفتید که چگونه کلاس های ساده ای ایجاد کنید که همچنان از ویژگی های مدل سازی، پرس و جو، ردیابی تغییر و مدیریت رابطه Entity Framework بهره مند شوند. ObjectContext می‌تواند این کلاس‌ها را با گرفتن عکس‌های فوری از وضعیت فعلی آنها یا با استفاده از پراکسی‌های پویا پراکسی برای ارائه اطلاع‌رسانی تغییر و مدیریت ارتباط در جریان، مدیریت کند. همچنین نگاهی گذرا به قالب T4 مایکروسافت برای ایجاد کلاسهای POCO از Entity Data Model داشتید.
فصل‌های بعدی برنامه‌نویسی Entity Framework از کلاسهای POCO در راه‌حل‌های کاربردی استفاده می‌کنند و نشان می‌دهند که چگونه در معماری‌های نرم‌افزاری چابک‌تر قرار می‌گیرند در حالی که از تست واحد بهره می‌برند.
چارچوب نهاد برنامه نویسی، کتاب
این مقاله گزیده ای از Programming Entity Framework، نسخه دوم است که توسط O'Reilly Media در اوت 2010 منتشر شده است. برای کسب اطلاعات بیشتر در مورد کتاب، به http://learnentityframework. com یا http://oreilly. com/catalog/9780596807252 مراجعه کنید..
Entity Framework CTP4 و Code First Resources
EF Team Blog Post "EF ویژگی CTP4 منتشر شد!": http://blogs. msdn. com/b/adonet/archive/2010/07/14/ctp4announcement. aspx Scott Guthrie ، Code-First توسعه با Framework Entity 4: httpp: //bit. ly/9ufqx7 Scott Hanselman: کد ساده ابتدا با Framework Entity 4: http://bit. ly/9hsgdh
پایگاه داده های نمونه را دریافت کنید
بانک اطلاعاتی نمونه از کتاب ذکر شده در این مقاله در بارگیری کد منبع این مقاله گنجانده شده است. علاوه بر این ، می توانید پایگاه داده ها را از وب سایت کتاب بارگیری کنید: www. learnentityframework. com. حتما بارگیری های نسخه دوم را دریافت کنید ، نه چاپ اول.
