چیزی که ما تا الان شنیدم در مورد شی گرایی اینه که خیلی خوبه و همیشه کار راه انداز هستش, ولی واقعیت اینه که همیشه این طوری نیست که بخواد کار راه انداز باشه و باعث کاهش حجم کد بشه اتفاقا بعضی جاها ممکنه استفاده از ویژگی‌های شی گرایی باعث افزایش حجم کد و سخت‌تر شدن نگه داری کد بشه

فرض رو میزاریم که به ما گفتن قراره یه سیستم نرم افزاری جدید طراحی کنیم( اینجا سعی میکنم اول با یه بازی شروع کنیم تا بعدا اگه فرصت شد توی دنیای واقعی این مسائل رو مطرح کنیم) وقتی میریم و در مورد این سیستم صحبت میکنیم متوجه میشیم که قراره یه بازی خیلی ساده طراحی کنیم 

NativeScript یک فریمورک متن باز برای ساخت برنامه‌های نیتیو موبایل با جاوا اسکریپت است.

Ionic فریمورک مبتنی بر Angular، به صورت متن باز برای توسعه نرم افزار تلفن همراه بکار می‌رود که باعث می‌شود برنامه‌های نیتیو و پیشرفته وب با تکنولوژی‌های بالا ساخته شود.

React Native یک فریمورک جاوا اسکریپت برای ساخت برنامه‌های تلفن همراه نیتیو است که از فریمورک React استفاده می‌کند.

انتخاب یکی از این 3 گزینه در دنیای صنعت رو به رشد امروز دشوار است. 

- متن را یکبار مطالعه کردید؟ یکبار مثال اصلی را با مثال فوق انطباق دادید؟
- در متن ذکر شده؛ مثال اصلی آن نوع ID را از نوع string تعریف کرده‌است. در اینجا برای نزدیک شدن مثال به دنیای واقعی و آن چیزی که مرسوم است، نوع Id به int تغییر داده شد.
اگر مورد نظر شما نیست، هرجایی که int مشاهده می‌کنید، تغییرش دهید به string. مثلا:
این int را تغییر دهید به string و در هر جای دیگری که تعریف شده و تغییر کرده. این تغییرات را با انطباق مثال تغییر یافته با نمونه‌ی اصلی که لینکش در متن هست می‌توانید پیدا کنید.

- تعریف T به شکلی که در این مثال خاص، محدود شده به کلاس Post، با سرویس معمولی به نام Post تفاوتی ندارد و یک کار اضافی است. اگر محدودیت Post این T را بر دارید به الگوی Repository می‌رسید که در قسمت 11 این سری در مورد آن بحث شده‌است. همچنین مطالب دیگری هم در سایت در مورد الگوی مخزن و نقد آن موجود هستند.
- جهت مدیریت ساده‌تر کار، بهتر است هر کدام از موجودیت‌ها یک کلاس سرویس مجزا داشته باشند. ضمنا در دنیای واقعی در بسیاری از اوقات نیاز است این کلاس‌های سرویس با چندین موجودیت جهت برآورده ساختن یک منطق تجاری کار کنند. بنابراین محدود کردن آن‌ها به T عملا پاسخ نخواهد داد.
- پیشتر هم در نظرات قبلی عنوان شده، نمونه‌ی پروژه‌ی خوب در این مورد، سیستم مدیریت محتوای IRIS است که مطالعه‌ی کدهای آن می‌تواند دید بهتری به شما بدهد. 

با تشکر از همگی دوستان

شخصا نظرم به نظر جناب نصیری نزدیک‌تر است. جناب پاکدل هم به نکات خوبی اشاره فرمودند. اما صرفا توصیه‌های مایکروسافت و دیگران دال بر درستی یا کارآمدی یک رویکرد نمی‌تواند باشد. مطلب پست شده مبتنی بر چندین پست از توسعه دهندگان مطرح دنیای دات نت ترجمه و تالیف شده. مسلما هیچ راه حل نهایی (silver-bullet) ای وجود ندارد و توسعه ساختار پروژه بر اساس نیازها و تعاریف اپلیکیشن‌ها به پیش می‌رود. اما در کل می‌توان اینگونه نتیجه گیری کرد که استفاده از الگوی Repository در کنار فریم ورک‌های ORM مانند EF که مبتنی بر UnitOfWork کار می‌کنند ایده خوبی نیست. برای مطالعات بیشتر به چند لینک نمونه زیر مراجعه شود.

^ ، ^ ، ^ ، ^ ، ^ ، ^

یکی از اشکالات repository این بود که در عمل و دنیای واقعی، قابلیتی برای تعویض ORM ایجاد نمی‌کرد و گفتید در صورتی می‌توان این کار را کرد که دست و پای ORM را ببندیم و از مشترکات استفاده کنیم. اما در الگویی که معرفی کردید یعنی IUnitOfWork هم ظاهرا دست و پایمان برای پیاده سازی متدهای خاص بسته است مانند متد ساده زیر
یا متدی که در بالا ذکر شد یعنی:
اینطور نیست؟

مطلب جالبی است که کمتر مورد استفاده قرار می‌گیره. شاید ذکر مثال‌های دنیای واقعی اون در اینجا مکمل خوبی باشه. اگر دوستان هم مثالی مدنظرشون بود، لطفا عنوان کنند.
An easier way to manage INotifyPropertyChanged
Custom Explicit and Implicit Operators in C#
Why does this code work?
ASP.NET MVC Model binding with implicit operators
Forgotten C# language features: implicit operator  
How to fake Enums in EF 4 

مطلب جالبی هست از یکی از اعضای تیم کامپایلر سی شارپ :(^)
بحث محاسبه کارآیی در دات نت شامل زمان صرف شده برای JIT اولیه کدها هم هست. به همین جهت اجرای اولیه اندکی بیشتر زمان می‌بره. همچنین GC هم در اینجا در ترد دیگری به موازات کار شما مشغول به کار است و اگر در یک اجرا زمان خوبی بدست آوردید به این معنا نیست که الزاما در اجرای بعدی هم همان زمان را بدست می‌آورید چون GC موکول شده به بعد. ضمن اینکه این نوع محاسبات چون به صورت ایزوله انجام می‌شود عموما بیانگر شرایط دنیای واقعی که پارامترهای زیادی در آن‌ها دخیل هستند، نیست.
و ... اینکه برای خیلی از برنامه نویس‌ها این نوع مقایسه‌ها بیشتر جذاب هستند:
Head-to-head benchmark: C++ vs .NET