فرض من در این مقاله این است که :
قبل از اینکه مقاله را شروع کنم کد زیر را ببینید:
حدس بزنید چه اتفاقی افتاده است؟ بر اساس کانکشنی که تعریف کردیم به کمک دستور SqlConnection، کانکشن را باز کرده و با متد QueryFirst یک دستور Select Top 1 را اجرا و خروجی را به شکل string در متغیر titleName ریختیم.
خیلی شبیه ADO.Net است ولی خروجیِ کوئری، تایپ دارد؛ برای ما برنامه نویس ها جذاب است و از این لحاظ شبیه EF عمل میکند.
دپر به عنوان یک ORM کوچک (Micro ORM) شناخته میشود. این کتابخانه‌ی بسیار پرکاربرد، حدود سال 2011 توسط تیم برنامه نویسی Stackoverflow منتشر شد. اما چرا دپر با وجود ORM های قدرتمندی مثل EntityFramework اینقدر پر طرفدار شده است؟ پروژه Stackoverflow در لایه دیتا از روش Linq2Sql استفاده می‌کرد اما به دلیل توسعه سریع پروژه Stackoverflow و ریکوئست ها و کوئری های زیاد مشکل پرفورمنسی برای پروژه بوجود آمد و مجبور شدند به Dapper مهاجرت کنند. این مهاجرت بیشتر در بخش کوئری ها انجام شد و Insert ها به همان روش قدیمی تا چند وقت قبل انجام می‌شد. این موضوع تا اکتبر 2018 ادامه یافت تا اینکه Nick Craver به عنوان معمار اصلی پروژه Stackoverflow اعلام کرد بطور کلی به EF Core مهاجرت خواهند کرد.
با این مقدمه، سوال مهمی که پیش می آید این است که چه موقع دپر انتخاب مناسبی خواهد بود؟
دپر کتابخانه فوق العاده سبکیست که شامل قابلیت های ابتدایی کار با دیتابیس است، یعنی از این لحاظ اصلا قابل مقایسه با EF یا Nhibernate نیست. نکته مثبت این ویژگی، در کمتر دستکاری شدن کوئری های شماست. شما به کمک دپر مستقیما کد T-SQL می‌نویسید و دپر فقط وظیفه مپ کردن مدل های شما را به عهده می‌گیرد. مپ کردن آیتم های جدول های دیتابیس به آبجکت های سی شارپ. همین.
در EntityFramework کنترل شما روی کوئری ها کامل نیست. یعنی با چند Join و Group توسط Linq یا Extension Method ها چیزی که پشت صحنه توسط EF به شکل کوئری T-SQL ساخته میشود گاهی عجیب و غریب و هزینه زا است. بدِ ماجرا اینجاست که اکثرا توسعه دهنده متوجه این فاجعه نمی‌شود و پرفورمنس برنامه پایین می‌آید.
در دپر شما دقیقا می‌دانید چه نوع کوئری اجرا میشود چون دقیقا همان کوئری SQL را می‌نویسید.
در کنار مزیت گفته شده، این موضوع را در نظر بگیرید که مهارت در کار با Linq و EntityFramework معمولا باعث کم کاری در کوئری نویسی T-SQL میشود و این موضوع نه تنها فایده ای ندارد بلکه از قدرت و مهارت شما در بخش SQL می‌کاهد. Dapper می‌تواند این خلاء را نیز پر کند.
سوال دیگر اینکه دپر به درد چه کسانی نمی‌خورد؟
گروه اول کسانی هستند که حوصله کوئری نوشتن با T-Sql را ندارند و غرق در Linq و امکانات EF هستند. برای این افراد دپر یک عذاب است.
گروه دوم کسانی که می‌خواهند پروژه ای که قبلا انجام داده اند را به دپر تبدیل کنند و پروژه سرشار از پیاده سازی و توسعه ی امکانات EF است و مثلا Tracking های EF همه جا ریشه دوانده باشد. به نظر برای این افراد مهاجرت به دپر چندان منطقی نیست.
نکته آخر اینکه معجزه دپر وقتی برای شما روشن میشود که مثل توسعه دهندگان Stackoverflow بخش حساس پروژه خود را که کوئری های پیچیده و بزرگ است به شکل دپری پیاده سازی کنید و از امکانات EF در بقیه جاهای پروژه استفاده کنید. این یعنی الزامی نیست که کل پروژه خود را از EF به Dapper منتقل کنید. Insert,Update,Delete عملیاتی هستند که چندان هزینه عجیبی ندارند و EF به سادگی از عهده آن بر می‌آید. می توانید پروژه خود را به شکل CQRS جلو ببرید و بخش های کامند را با EF و بخش های کوئری را با Dapper پیاده سازی کنید.
