‫۶ سال و ۶ ماه قبل، یکشنبه ۲۷ اسفند ۱۳۹۶، ساعت ۱۹:۱۶
قطعا یک محیط عالی برای نوشتن برنامه‌های دات نتی فعلا در حال حاضر خود ویژوال استودیو هست چون از هر نظر که بررسی بشه فول اپشنه و چیزی رو کم نداره البته جاهایی کم کاری کردن ولی خب به چشم نمیاد و خیلی ریزه مشکلاتش و نسبت به نرم افزارهای دیگه سرتره 
من از rider خوشم اومده ولی منتها هنوز جا برای تکمیل داره و اخطارهای سرخ رنگ زیادی حین کار داره. مثلا گزینه Create View داره ولی کارکردی ازش ندیدم و دستی میسازم  ولی همچنان دستور return سرخ رنگ هست و نمیشناسه (شاید تو اپدیت بعدی درست شده و چک نکردم) . همچنین این برنامه و vs code هم بعضی موارد رو مثل ویرایش فایهای ریسورس گزینه ای ندارن.
ولی در کل محیط راحت و سبکی هست و امکانات زیادی داره و نیاز نیست با vs سنگین سر و کله زد. به خصوص اگر قبلا با ویراستارهای شرکت جت برینز کار کرده باشید محیط فوق العاده ای میشه
خطاهایی نظیر Specified key was too long; max key length is 767 bytes تنها یکی از موارد است (این مشکلی است که من با آن مواجه بوده ام و لینک دادن صرفا برای توضیحات بیشتر است )و منظور از ساختار کدنویسی پیچیده موردی که خود من با آن روبه رو شدم در توسعه سیستمی افزونه پذیر و بکارگیری روش IUnitOfWork  بود و تغییر بدون درد سر نوع بانک اطلاعاتی است نه عدم امکان آن. و برنامه نویس زمانی می‌تواند درک مناسبی از این مشکلات داشته باشد که با ORM ای مانند  Gorm کار کرده باشد .(نکته همینجاست که با وجود کوچک بودن رضایت برنامه نویسان مرتبط خودش را فراهم کرده است .  )
کسی منکر کامل بودن EF نیست و در سیستمهای دات نتی همواره از آن استفاده می‌کنم و معتقدم هر ابزار و روشی در برنامه نویسی مناسب موقعیت خاصی است و پیچیدن نسخه ای تمام عیار برای تمامی سناریوها اشتباه است . و به نظر من کامل بودن و پرداختن به جزئیات می‌تواند تغییر موقعیت در سناریو را با چالش مواجه کند .  توضیحاتی که در بالا عنوان کردم صرفا دلیل شخصی من برای رای دادن است .  
یکی از اهداف ORM‌ها توانایی تغییر نوع بانک اطلاعاتی است در پروژه‌های بزرگ با روابط بین موجودیتی و ساختار کدنویسی پیچیده ORM ای مانند EF محدودیتهای فراوانی ایجاد می‌کند که این کار را عملا ناممکن یا حداقل طاقت فرسا می‌کند . 
یعنی اگر پروایدر بانک اطلاعاتی مورد استفاده را در آغاز برنامه تعویض کردید کار نمی‌کند؟ فقط به یک شرط کار نمی‌کند. از امکانات بومی آن بانک اطلاعاتی با SQL نویسی مستقیم کار کرده باشید. وگرنه تمام آن پیچیدگی‌ها برای این هستند که کدهای شما با تعویض پروایدر بانک اطلاعاتی به صورت خودکار جهت بانک اطلاعاتی جدید ترجمه شوند.
استفاده از ORM هر چند نوع ضعیف آن  را به استفاده از کوئری زدن مستقیم به دلیل تغییرات زیادی که عملا در حین کدنویسی در ساختار موجودیت‌ها ایجاد می‌شود  ترجیح می‌دهم . پیچیده بودن و داشتن امکانات زیاد  با عث عدم انعطاف پذیری میشود . یکی از اهداف ORM‌ها توانایی تغییر نوع بانک اطلاعاتی است در پروژه‌های بزرگ با روابط بین موجودیتی و ساختار کدنویسی پیچیده ORM ای مانند EF محدودیتهای فراوانی ایجاد می‌کند که این کار را عملا ناممکن یا حداقل طاقت فرسا می‌کند .  دیگر اینکه در برنامه‌های موبایلی نیازی به ORM ای پیچیده به دلیل ماهیت اینگونه برنامه‌ها نیست .
در پلت فرمهای جدید برنامه نویسی بسیاری از  ORM‌ها ی موفق (از دید برنامه نویسان) حتی کلیدهای خارجی و روابط ، خارج از حوزه دید آنها است چرا که انعطاف و راحتی برنامه نویسان را در اولویت قرار می‌دهند و بسیاری از قوانین داده ای برای بررسی صحت داده‌ها و اعتبارسنجی آنها با چند خط کد قابل بررسی است . 
بنظرم روش استاندارد و تمیزتری که در کدنویسی هم داره و از قبل هم وجود داشته orm بوده و فعلا هم همینطوره + اینکه اکثرا دیدم کسانی که با sqlite کار میکنند بعد از عرضه نسخه بتا دچار درگیری‌های کدنویسی میشن و دستشون بستست و مجبور میشن بیس کارو تغییر بدن و به سمت orm مراجعه کنن ، پس با اینحال فعلا orm گزینه مطلوب‌تری هست ...!
بله ، پس از راه اندازی Realm Server برای Sync شدن با سرور نیازی به استفاده از Rest Api ( برنامه سرور مد نظر شما) نیست اما در صورتی که منطق برنامه شما پیچیده باشد یا در سمت سرور نیاز به کنترل بیشتری دارید ناگزیر به استفاده از Api‌های خودتان هستید. couch  در مورد همگام سازی دو سویه (bidirectional sync) سابقه طولانی‌تری نسبت به realm دارد و سازندگان آن مدعی هستند امکان replication دو طرفه بین دو دیتابیس لوکال هم وجود دارد.
با تشکر از شما.
ایکاش دوستان دیگری که نظر میداند دلیل استفاده از مورد انتخابی رو هم می‌نوشتند و اینکه کدام گزینه در چه شرایطی میتونه مفیدتر باشه.
اینطور که شما نوشتید با استفاده از Realm  میشه گفت نیازی به برنامه سرور نداریم ، درسته؟


بنظر میرسد من و سایر کاربران سایت جاری تجربه خوبی در استفاده از ORM قدرتمند  EF داریم بنابراین امکانات و ویژگی‌های هر ORM دیگری را نیز با آن مقایسه میکنیم و شاید عیار سایر ORM‌ها را نیز با EF  بسنجیم.
روش معمول Sqlite:
مزایای اصلی این روش انعطاف پذیری ، بالا بردن توانایی مانور برنامه نویس، سرعت اجرای بهتر و حجم کمتر در فایل خروجی نهایی است . عیب اصلی آن مجیک استرینگ‌های زیاد و کثیف شدن کد، بالاتر بودن نرخ تعداد خطا در برنامه ،دیباگ سخت تر،قابلیت نگهداری کمتر کد ، تعداد خط کد بالای برنامه ، سرعت به نسبت پایین در develop است.
ORM:
میتوان گفت مزایا و معایب استفاده از ORM دقیقا نقطه مقابل روش معمول Sqlite است و در اصل ایده اصلی خلق اولین ORM ‌های دنیا نیز چنین بود ! عیب دیگر این ORM‌های اندرویدی این است که در مقایسه با EF دست و پا بریده ، خسته کننده و بعضا باعث کلافگی برنامه نویس میشوند.
NoSql یا ترکیبی:
با توجه به مدرن بودن و mobile-first  بودن برخی از این دیتابیس‌ها ، از ابتدا با بسیاری از نیازمندی‌های مدرن از جمله sync شدن با دیتابیس سرور، push notification , پردازش و مدیریت داده‌های json و هویت سنجی با OAuth همسو هستند .همچنین میتوان با کمترین تعداد خط کد و نفرات از ویژگی‌های پیشرفته آنها استفاده کرد. از نمونه‌های خوب دیتابیس‌های NoSql میشود به Realm و couchbase اشاره کرد. از نظر من عیب اصلی این دیتابیس‌ها عدم پختگی و ثبات ایده آل است هرچند برای اکثر پروژه‌ها تا همینجا هم گزینه ای عالی محسوب میشوند. 
‫۶ سال و ۷ ماه قبل، یکشنبه ۲۹ بهمن ۱۳۹۶، ساعت ۱۹:۴۶
کلا برنامه‌های تیره ، طبق لینک‌های ارجاع داده شده برای کارهای گرافیکی مناسب‌تر هستند. مثلا در برنامه فتوشاپ پس زمینه تیره برای سند، باعث میشه طرح رو بهتر ببینیم.یا مثلا برنامه‌های فیلم که شامل تعداد زیادی پوستر میشن و هر اونچه که مربوط به گرافیک میشه ولی برنامه نویسی یا برنامه هایی که بیشتر نیاز به فکر کردن دارن و یا اتوماسیون‌های کاری بیشتر نیازمند یه محیط ساده و کاری و تجاری دارن.
البته اگر ترکیب رنگ‌ها و نوع و سایز قلم در محیط میتونه خیلی از فرمول‌های بالا رو کنار بزنه
‫۶ سال و ۸ ماه قبل، پنجشنبه ۱۴ دی ۱۳۹۶، ساعت ۲۳:۳۳
منظور گزارش‌های آماری Big data بود در این نظر سنجی که بهترین گزینه nosql هست ولی با توجه به اینکه هردو سناریو هم برای rdms هم nosql در یک پروژه وجود دارد گفتم نظر دوستان رو بدونم که انتخاب هاشون به چه شکل هست. 
من خودم گزینه  استفاده از NoSql    که رای نیاورده بیشتر مدنظرم بود ... که با این نظر سنجی باید بیشتر روش فکر کنم. (البته به اشتباه گزینه دیگه ای رای دادم !)
با تشکر