اخیرا سیستمهای کار با دیتا در اندروید رو به افزایش است و هر روز سیستمهای جدیدتر و به روزتری ایجاد میشود. به نظرتان کدامیک از روش‌های بهتر است و مزایا و مشکلات آنان چیست و چه آینده ای دارند؟ و به نظرتان در حد شعارهایی که میدهند کارآمد هستند؟
مطالب مشابه
- اشتراک‌ها
راهکارهای مختلف کار با داده در .NET Coreاشتراک‌ها
آموزش ابزار گیت فلو (git-flow)بازخوردهای دوره
کار با RavenDB از طریق REST API آننظرات مطالب
معرفی Lex.Dbنظرات مطالب
جزئیات برنامه نویسی افزونه فارسی به پارسینظرات مطالب
مروری بر چند تجربه‌ی کاری با SQLiteنظرات مطالب
Entity Framework و آیندهنظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت اول - موجودیت‌های پایه و DbContext برنامهنظرات نظرسنجی‌ها
شما برای کار با دیتا در اندروید، کدامیک از روش های زیر را استفاده میکنید یا ترجیح می دهید؟نظرات نظرسنجی‌ها
تا چه مدتی ترجیح می‌دهید در یک محل کاری باقی بمانید؟
- لینک زیر میتونه برای انتخاب ابزار مناسب برای کار با داده‌ها مناسب باشه!Android-ORM-benchmark
- بنظر میرسد من و سایر کاربران سایت جاری تجربه خوبی در استفاده از ORM قدرتمند EF داریم بنابراین امکانات و ویژگی‌های هر ORM دیگری را نیز با آن مقایسه میکنیم و شاید عیار سایر ORMها را نیز با EF بسنجیم.روش معمول Sqlite:مزایای اصلی این روش انعطاف پذیری ، بالا بردن توانایی مانور برنامه نویس، سرعت اجرای بهتر و حجم کمتر در فایل خروجی نهایی است . عیب اصلی آن مجیک استرینگ‌های زیاد و کثیف شدن کد، بالاتر بودن نرخ تعداد خطا در برنامه ،دیباگ سخت تر،قابلیت نگهداری کمتر کد ، تعداد خط کد بالای برنامه ، سرعت به نسبت پایین در develop است.ORM:میتوان گفت مزایا و معایب استفاده از ORM دقیقا نقطه مقابل روش معمول Sqlite است و در اصل ایده اصلی خلق اولین ORM های دنیا نیز چنین بود ! عیب دیگر این ORMهای اندرویدی این است که در مقایسه با EF دست و پا بریده ، خسته کننده و بعضا باعث کلافگی برنامه نویس میشوند.NoSql یا ترکیبی:با توجه به مدرن بودن و mobile-first بودن برخی از این دیتابیس‌ها ، از ابتدا با بسیاری از نیازمندی‌های مدرن از جمله sync شدن با دیتابیس سرور، push notification , پردازش و مدیریت داده‌های json و هویت سنجی با OAuth همسو هستند .همچنین میتوان با کمترین تعداد خط کد و نفرات از ویژگی‌های پیشرفته آنها استفاده کرد. از نمونه‌های خوب دیتابیس‌های NoSql میشود به Realm و couchbase اشاره کرد. از نظر من عیب اصلی این دیتابیس‌ها عدم پختگی و ثبات ایده آل است هرچند برای اکثر پروژه‌ها تا همینجا هم گزینه ای عالی محسوب میشوند.
- بله ، پس از راه اندازی Realm Server برای Sync شدن با سرور نیازی به استفاده از Rest Api ( برنامه سرور مد نظر شما) نیست اما در صورتی که منطق برنامه شما پیچیده باشد یا در سمت سرور نیاز به کنترل بیشتری دارید ناگزیر به استفاده از Apiهای خودتان هستید. couch در مورد همگام سازی دو سویه (bidirectional sync) سابقه طولانی‌تری نسبت به realm دارد و سازندگان آن مدعی هستند امکان replication دو طرفه بین دو دیتابیس لوکال هم وجود دارد.
- بنظرم روش استاندارد و تمیزتری که در کدنویسی هم داره و از قبل هم وجود داشته orm بوده و فعلا هم همینطوره + اینکه اکثرا دیدم کسانی که با sqlite کار میکنند بعد از عرضه نسخه بتا دچار درگیری‌های کدنویسی میشن و دستشون بستست و مجبور میشن بیس کارو تغییر بدن و به سمت orm مراجعه کنن ، پس با اینحال فعلا orm گزینه مطلوب‌تری هست ...!
- استفاده از ORM هر چند نوع ضعیف آن را به استفاده از کوئری زدن مستقیم به دلیل تغییرات زیادی که عملا در حین کدنویسی در ساختار موجودیت‌ها ایجاد میشود ترجیح می‌دهم . پیچیده بودن و داشتن امکانات زیاد با عث عدم انعطاف پذیری میشود . یکی از اهداف ORMها توانایی تغییر نوع بانک اطلاعاتی است در پروژه‌های بزرگ با روابط بین موجودیتی و ساختار کدنویسی پیچیده ORM ای مانند EF محدودیتهای فراوانی ایجاد می‌کند که این کار را عملا ناممکن یا حداقل طاقت فرسا می‌کند . دیگر اینکه در برنامه‌های موبایلی نیازی به ORM ای پیچیده به دلیل ماهیت اینگونه برنامه‌ها نیست .در پلت فرمهای جدید برنامه نویسی بسیاری از ORMها ی موفق (از دید برنامه نویسان) حتی کلیدهای خارجی و روابط ، خارج از حوزه دید آنها است چرا که انعطاف و راحتی برنامه نویسان را در اولویت قرار میدهند و بسیاری از قوانین داده ای برای بررسی صحت داده‌ها و اعتبارسنجی آنها با چند خط کد قابل بررسی است .
یکی از اهداف ORMها توانایی تغییر نوع بانک اطلاعاتی است در پروژه‌های بزرگ با روابط بین موجودیتی و ساختار کدنویسی پیچیده ORM ای مانند EF محدودیتهای فراوانی ایجاد می‌کند که این کار را عملا ناممکن یا حداقل طاقت فرسا می‌کند .
یعنی اگر پروایدر بانک اطلاعاتی مورد استفاده را در آغاز برنامه تعویض کردید کار نمی‌کند؟ فقط به یک شرط کار نمی‌کند. از امکانات بومی آن بانک اطلاعاتی با SQL نویسی مستقیم کار کرده باشید. وگرنه تمام آن پیچیدگی‌ها برای این هستند که کدهای شما با تعویض پروایدر بانک اطلاعاتی به صورت خودکار جهت بانک اطلاعاتی جدید ترجمه شوند.- خطاهایی نظیر Specified key was too long; max key length is 767 bytes تنها یکی از موارد است (این مشکلی است که من با آن مواجه بوده ام و لینک دادن صرفا برای توضیحات بیشتر است )و منظور از ساختار کدنویسی پیچیده موردی که خود من با آن روبه رو شدم در توسعه سیستمی افزونه پذیر و بکارگیری روش IUnitOfWork بود و تغییر بدون درد سر نوع بانک اطلاعاتی است نه عدم امکان آن. و برنامه نویس زمانی می‌تواند درک مناسبی از این مشکلات داشته باشد که با ORM ای مانند Gorm کار کرده باشد .(نکته همینجاست که با وجود کوچک بودن رضایت برنامه نویسان مرتبط خودش را فراهم کرده است . )کسی منکر کامل بودن EF نیست و در سیستمهای دات نتی همواره از آن استفاده می‌کنم و معتقدم هر ابزار و روشی در برنامه نویسی مناسب موقعیت خاصی است و پیچیدن نسخه ای تمام عیار برای تمامی سناریوها اشتباه است . و به نظر من کامل بودن و پرداختن به جزئیات می‌تواند تغییر موقعیت در سناریو را با چالش مواجه کند . توضیحاتی که در بالا عنوان کردم صرفا دلیل شخصی من برای رای دادن است .
