در دنیای Object Oriented Programming کار مستقیم با دیتابیس یک معضل حساب می‌شود. چون به خاطر ماهیت رابطه‌ای بودن آنها نمی‌شود با آنها مثل object برخورد کرد. به همین خاطر ORMها به وجود آمدند تا دیتابیس را زیر خودشان مخفی کرده و آن را به شیوه‌ی مناسب object oriented به لایه‌های بالاتر تحویل دهند.
برای استفاده کامل از امکانات ORM باید همه اصول Object Oriented Programming رعایت شود. یعنی تعریف کلاس‌ها، اینترفیس‌ها و روابط بین آنها باید مطابق اصول باشد. مثلاً اگر عادت به استفاده از متغیرهای عمومی دارید، اگر متودها را فقط به صورت استاتیک می‌نویسید، اگر متودهایی می‌نویسید که گاه به ۵۰۰ خط هم می‌رسند، اگر عادت به استفاده از مفاهیم سه‌گانه OOP ندارید، اگر نمی‌دانید Design Pattern چیست و… باید روش خود را تغییر دهید در غیر این صورت استفاده از ORM نه تنها هیچ مزیتی برای شما ندارد بلکه شما را حسابی هم به دردسر خواهد انداخت.
در بحث Documentation در ORM و دیتابیس، مهم‌ترین موضوعی که با آن برخورد می‌کنید این است که دیگر اجازه استفاده از ERD ندارید. بلکه به جای آن باید از UML Class Diagram استفاده کنید. چون ERD بر اساس ماهیت رابطه‌ای است ولی Class Diagram بر اساس ماهیت Object Oriented ساخته شده. اگر افراد گروه شما به ERD عادت دارند و نمی‌توانند یا نمی‌خواهند از Class Diagram استفاده کنند، این یعنی یک زنگ خطر. چون این افراد بعدها مشکلات زیادی را به وجود خواهند آورد.
تعامل با دیتابیس یکی از بنیادی‌ترین تغییراتی است که استفاده از ORM ایجاد می‌کند. ORMها این تفکر را تبلیغ می‌کنند که عملیات دادهای در سمت کد اتفاق بیفتند نه در داخل دیتابیس. این یعنی حداقل استفاده از امکانات داخلی دیتابیس. به عبارت دیگر اگر می‌خواهید از ORM استفاده کرده و از همه مزایای بهره‌مند شوید باید استفاده از Stored Procedureها، Viewها، Triggerها و… را بی‌خیال شوید. حال اگر در شرکتی هستید که همه Business برنامه را از طریق Stored Procedureها، Triggerها، Viewها و… اعمال می‌کنند، بدانید که استفاده از ORM در آنجا خیلی سخت بوده و مخالفان سرسخت زیادی خواهد داشت.
تجربه‌ای که ما در شرکت قبلی داشتیم در بعضی جاها با خودش شکست به همراه داشت. البته میزان موفقیت در استفاده از ORM از نظر شخص خودم حداقل ۷۵ درصد بود. متاسفانه علت آن بخش‌های ناموفق فقر دانش خودمان در استفاده از ORM بود. مهم‌ترین آنها عبارتند از:
۱- چون نتوانسته بودیم ORM خودمان را به خوبی Config کنیم دچار مشکل Performance شده و مجبور شده بودیم بعضی جاها استثنا قائل شده و از Store Procedure استفاده کنیم.
۲- در صفحات ASP.NET برای Data Binding از ObjectDataSource استفاده نکرده بودیم در نتیجه مجبور شده بودیم بیشتر کارها از جمله Paging و… را از طریق code behind انجام دهیم. این موضوع باعث حجیم شدن و پیچیده شدن بیهوده‌ی code behind شده بود. علت عدم استفاده از ObjectDataSource نا آگاهی خودمان بود ولی به هر صورت اگر از به جای ORM از ADO.NET استفاده می‌کردیم کمتر دچار این مشکلات می‌شدیم.
۳- ما برای گزارش‌گیری از MS SQL Server Reporting Services استفاده می‌کردیم. گزارشات در این سیستم به دو نوع client و server تقسیم می‌شوند. ما بلد نبودیم یا شاید هم راهی وجود نداشت که خروجی‌های objectی مثل IList را به گزارشات سروری بفرستیم. در نتیجه آنجا هم مجبور شدیم برای تهیه گزارشات به صورت مستقیم از Sql استفاده کنیم.
توصیه شخصی من برای استفاده یا عدم استفاده از ORM این است که با توجه به پیشرفت فناوری‌ها و گرایشات روز دنیای نرم‌افزار و با توجه به رواج روز افزون روش‌های Agile و TDD بهتر است شما هم هر چه زودتر خودتان را به جمع کاربران ORM اضافه کنید. درست است که ORM درصد خیلی کمی از سرعت برنامه را کاهش می‌دهد، تغییرات زیادی را در روش کار می‌دهد و نیاز زیادی به آموزش و مطالعه دارد، اما در مجموع هزینه‌های تولید را کاهش می‌دهد، نگهداری کد را راحت‌تر می‌کند، تعداد باگ‌ها را کاهش می‌دهد و در نهایت هم منافع کارفرما و مدیریت را با خود به همراه دارد و هم رضایت برنامه‌نویسان را.
Comments
سلام،
ممنون آقای محبی
بسیار لطف کردید.
یکی از چالش های مهم برای استفاده از ORM بحث نا آشنا بودن تیم توسعه با روش های طراحی OOP است که خیلی مهمه و بخش دیگه اش هم عادت به انجام کارها از طریق خود دیتابیس مثل نوشتن SP و Trigger برای انجام کارهای مختلفه.
من هم سعی میکنم در این مورد بنویسم.
باسلام
از اینکه تجربیات خودتان را به اشتراک می‌گذارید مخصوصاُ در زمینه‌ی ORM از شما سپاسگذاری میکنم
با سلام و تشکر از مطلب خوبتون
راستش ما یه برنامه برای یه صندوق قرض الحسنه داریم که میخاهیم یه بازنویسی توی کدش انجام بدیم با دیتابیسی با حدود 150 جدول و 600 تا روال بنظرتون منطقیه با این حجم دیتابیس از ORM استفاده کنیم؟
ممنون از راهنمائیتون
محمد: به نظرم اگه اولین باری که می‌خواین از یک ORM استفاده کنید، بهتر است یک پروژه کوچولو را به طور امتحانی با آن کار کنید تا زیر و بم آن دستتان بیاید.
ضمناً ORM جماعت سر سازگاری خوبی با store procedureها ندارند.
ممنونم از جوابتون الان داریم کار تست با یه پروژه ی کوچیک رو انجام میدیم بصورت کلی پرسیدم که آیا به صرفه هست
برای یه پروژه بزرگ با دادهای زیاد و منطقی که الان بیشترش در روال انجام میشه به سمت ORM
حرکت کنیم؟
ممنونم از اینکه وقت گذاشتی
محمد: به طور کلی مشکل خیلی زیادی با حجم دیتا نیست. بیشتر ORMها مکانیزم‌های برای برخورد بهینه با حجم زیاد دیتا دارند.
اما مشکل اصلی با استفاده خیلی زیاد از stored procedure است. اصولاً یکی از مزایای استفاده از ORM این است که به شما اجازه می‌دهد در تمام بخش‌های برنامه که قسمت مهمی از آنها را همین بخش پردازش اطلاعات تشکیل می‌دهد، از مفاهیم Object Oriented استفاده کنید. حال اگر شما تعداد زیادی sp قدیمی داشته باشید از این مزیت اصلی ORM هیچ استفاده‌ای نبرده‌اید.
سلام
خیلی ممنون از اطلاعاتی که گذاشتید.
من یه سوال دارم
برای زمانی که پروژه ممکنه ادیت بشه و بخش هایی به پروژه اضافه یا کم بشه باز هم استفاده از ORM ها می تونند مناسب باشن؟
مرسی ازتون
اگه منظور از کم و زیاد شدن، تغییرات در تعداد entity یا خود entityهاست که می‌شود گفت ORMها بهتر عمل می‌کنند. چون یکی از اهداف آنها دادن قابلیت خوانایی بهتر و قدرت تغییرات بیشتر است
ممنون از پاسخی که دادید.
به جز تغییرات در entity ها چه نوع تغییرات دیگری ممکنه پیش بیاد؟؟؟
هر چیزی می‌تواند تغییر کند. تعریف پروژه، فناوری‌ها، روش ارتباط با شبکه، UI و خیلی چیزهای دیگر
BA SALAM JENAB AFSHAR AYA EMKAN DARAD MAN SHOMARE TAMAS YA EMAIL JENABALI RA DASHTE BASHAM BARAIE PAREI AZ SOALAT..? BA TASHAKOR