ما برنامه‌نویس‌ها همیشه به دنبال سادگی و پیداکردن اصولی در کد هستیم که باعث میشن حس بهتری نسبت به کدمون داشته باشیم. بوهای بد توی کد رو پیدا می‌کنیم و اگه نتونیم رفعشون کنیم، هر بار که به کد نگاه می‌کنیم حس می‌کنیم یکی داره با چکش خیلی آروم اما مداوم می‌کوبه توی سرمون. یکی از چیزایی که ما رو اذیت می‌کرد کار با دیتابیس در نرم‌افزارها بود.
بیایید به عنوان یه سری برنامه‌نویس قبول کنیم که زبان دیتابیس‌ها با زبان ما فرق داره. یعنی آره، اون هم یه زبان برنامه‌نویسی به حساب میاد، اما بیخیال، اون که نمیتونه از یه مرزی پاشو فراتر بذاره. و می‌دونین وقتی یک زبان با زبان ما کمی فرق داره چی ما رو اذیت می‌کنه؟ قاطی کردنشون. ما برای کار با دیتابیس باید وسط کدمون یک رشته می‌ساختیم و توی اون شروع می‌کردیم عبارات SQL نوشتن. بعدا تکنیکی یاد گرفتیم به اسم DAO (Data Access Object) و گفتیم این شکلی تمام کد SQL که نیاز داریم رو توی یک کلاس می‌نویسیم و استفاده مجدد می‌کنیم، اما این واقعا تمام کد SQLی هست که نیاز داریم؟
پاسخ واضح بود، نه. اما این روش با این حال کارراه‌انداز بود. حالا یک مشکل جدید پیش می‌اومد، اگر توی SQL اشتباه کنم چی؟ اگر بخوام یه کار خاص انجام بدم و بخوام تغییری توی query بدم چی؟ اصلا این DAOها که دارن یه کار ثابت انجام میدن، چرا یکی نمیره این‌ها رو بنویسه تا من برای هر data class که تعریف می‌کنم مجبور نباشم یه عالمه کد تکراری بنویسم؟ همه این سوالات منجر شد به ظهور ORMها.
تمام این مشکلاتی که به ذهن ما رسید (و حتی بعضی‌ها که اینجا به ذهنمون نرسید) با ORMها حل شد. یک ORM (Object-relational mapping) به ما کمک می‌کنه که (تقریبا) بدون درگیرشدن با SQL بتونیم با دیتابیس کار کنیم. به طور خلاصه، این ابزارها نگاشتی هستن بین طرز فکر شیء‌گرای ما (آبجکت‌ها) و چیزی که دیتابیس می‌شناسه (رابطه‌ها).
همون طور که توی کد بالا می‌بینین، این ابزارها خیلی راحت با کد ما جور میشن. اگر با MongoDB کار کرده باشین، یک احساس آشنایی به شما دست میده.
یک ORM به ما اجازه میده تا مدل‌هایی رو تعریف کنیم، که این مدل‌ها در واقع قالب داده‌ای هستن که ما قصد داریم در یک جدول ذخیره کنیم. پس هر مدل معادل یک جدول در دیتابیس هست. کار دیگری که ORM انجام میده، ارائه متدها و کلاس‌هایی هست که روی این مدل‌ها کار می‌کنن و می‌تونن اون‌ها رو ایجاد کنن، از دیتابیس پرس‌و‌جو کنن، ویرایش کنن یا حذف کنن (عملیات CRUD). و در نهایت، به ما این امکان رو میدن که روابط بین مدل‌ها رو تعریف کنیم و بتونیم توی کد از اون‌ها استفاده کنیم. مثلا بگیم که یک Person، می‌تونه چند Project داشته باشه و در کد با استفاده از یک متد getProjects تمامی پروژه‌های یک فرد رو بگیریم، زیبا نیست؟
از اونجایی که من برای توسعه MVP محصول و سرور اون از Node.JS استفاده می‌کردم، به سراغ Sequelize رفتم. یادگیری این کتابخونه آسون بود اما خیلی سریع سوالات و مشکلاتی برام پیش اومد که واقعا نیازمند جست‌و‌جو و تحقیق زیادی بود. در نهایت، روال و نحوه کار با این کتابخونه رو فهمیدم و تصمیم گرفتم تا بیام و برای شما هم توضیحش بدم.
در قسمت‌های بعدی، یاد می‌گیریم که چطور به بهترین شکل از Sequelize استفاده کنیم و توی چاله و چوله‌های اون گرفتار نشیم.
