تفاوت میان استفاده از Linq و Stored Procedure در Entity Framework

csharpcollegian · Apr 8, 2017

عرض سلام و وقت به خیر خدمت دوستان و اساتید محترم
همونطور که می دونید در Entity Framework برای ایجاد تقاضا روی دیتابیس هم میشه از Linq کمک گرفت و هم میشه از Stored Procedure ها استفاده کرد.
برای مثال فرض کنید تصمیم داریم رکورد آخرین مشتری ثبت شده در دیتابیس توسط کاربر با شناسه 1 رو پیدا و ستون ImageID اون رو برابر 3 قرار بدیم. برای انجام اینکار توسط Linq براحتی می تونیم توسط کد زیر این کار رو انجام بدیم :

اما اگر بخوایم به کمک Stored Procedure ها این کار رو انجام بدیم بایستی در ابتدا یک پروسیجر حاوی کدهای زیر ایجاد کنیم، سپس در برنامه پروسیجر مربوطه رو صدا زده و اجرا کنیم :

به نظر من روش اول (Linq) خیلی ساده تره و پیچیدگی کمتری داره و خودم شخصا این روش رو ترجیح میدم. اما می خوام بدونم از نظر شما کدوم روش بهتره ؟
ممنونم میشم همه اساتید نظرشون رو با یک توضیح مختصر مطرح کنند.
متشکرم

the_king · Apr 9, 2017

csharpcollegian گفت:
عرض سلام و وقت به خیر خدمت دوستان و اساتید محترم
همونطور که می دونید در Entity Framework برای ایجاد تقاضا روی دیتابیس هم میشه از Linq کمک گرفت و هم میشه از Stored Procedure ها استفاده کرد.
برای مثال فرض کنید تصمیم داریم رکورد آخرین مشتری ثبت شده در دیتابیس توسط کاربر با شناسه 1 رو پیدا و ستون ImageID اون رو برابر 3 قرار بدیم. برای انجام اینکار توسط Linq براحتی می تونیم توسط کد زیر این کار رو انجام بدیم :

اما اگر بخوایم به کمک Stored Procedure ها این کار رو انجام بدیم بایستی در ابتدا یک پروسیجر حاوی کدهای زیر ایجاد کنیم، سپس در برنامه پروسیجر مربوطه رو صدا زده و اجرا کنیم :

به نظر من روش اول (Linq) خیلی ساده تره و پیچیدگی کمتری داره و خودم شخصا این روش رو ترجیح میدم. اما می خوام بدونم از نظر شما کدوم روش بهتره ؟
ممنونم میشم همه اساتید نظرشون رو با یک توضیح مختصر مطرح کنند.
متشکرم

بهتر بودن بستگی به نیاز ها و اولویت هاتون داره، گاهی اوقات سرعت و سهولت کد نویسی در اولویت ئه، گاهی سرعت اجرا و گاهی امنیت و گاهی قابلیت استفاده مجدد از کد.
فرضا اگه شما قراره در بین مشتری های بانک دنبال مشخصات یک فرد خاص بگردید و ویرایشی رو انجام بدید، احتمالا از لحاظ امنیتی و پهنای باند شبکه اصلا مصلحت نباشه که با Linq حتی مشخصات یک فرد از طریق شبکه منتقل بشه، چه برسه به اینکه لیستی از مشتریان رو دریافت کنید و بین شون دنبال مشتری مورد نظر بگردید. Stored Procedure اینجا این مزیت رو داره که درخواست لیست مشتریان اش اصلا از محیط سرور خارج نمیشه، همونجا روی سرور جستجو رو خیلی سریعتر انجام میده.
در نظر بگیرید که هر زبان و Framework ای که در کد #C تون بکار بگیرید نهایتا با SQL Server از طریق دستورات SQL ارتباط برقرار میشه. یعنی اگر Linq to SQL و ADO.NET Entity Framework و ... امتیازی داشته باشند در ساده تر کردن کد نویسی ئه. معایب شون اولا همیشه کاهش سرعت اجرا است، چون تبدیل کد به دستورات SQL به هر حال سربار داره و ثانیا تمامی معایب و مزایایی که اجرای کد SQL در خارج از محیط Stored Procedure خواهد داشت رو هم دارند. پس در نظر بگیرید که شما وقتی از Entity Framework و Linq استفاده می کنید کد نویسی تون می تونه ساده تر بشه، بستگی به این داره که چقدر نسبت به SQL براتون ساده تر به نظر بیاد، اما در مقابل سرعت اجرای تراکنش رو قدری کاهش می دهید، ممکنه اصلا محسوس نباشه یا اونقدر تراکنش ها پیچیده و مکرر باشه که این کاهش سرعت به چشم بیاد.
و به هر حال چه مستقیما کد SQL بنویسید و چه از Linq کمک بگیرید با Stored Procedure این تفاوت ها رو داره :

Stored Procedure تحت پوشش امنیتی که پایگاه داده رو محصور کرده قرار گرفته، به همین دلیل امنیت اش در بالاترین حدی ئه که خود پایگاه داده ازش برخورداره.
از اونجایی که Stored Procedure روی سرور و در کنار پایگاه داده اجرا میشه، داده ها رو کنار خودش می بینه و نیازی به ارسال داده و کد و ترافیک سنگین بین سرور و برنامه نیست و بار ترافیک بین برنامه و سرور میتونه خیلی کم باشه.
سطوح امنیتی بهتری برای Stored Procedure وجود داره، شما می توانید بگید فلان کاربر ئه SQL Sever فقط اجازه داره فلان Stored Procedure ها رو اجرا کنه. یعنی مستقیما حتی حق نداره جداول رو ببینه.
اون کد SQL ای که شما می نویسید قبل از اجرا باید توسط سرور کامپایل بشه، بنابر این اگه ده بار اجراش کنید ده بار کامپایل میشه، برای همین در بهترین شرایط هم سرعت اجرای Stored Procedure که از قبل کامپایل شده بیشتر ئه.
و احتمالا در کاهش دوباره کاری و استفاده مجدد از کد های قبلی Stored Procedure مزیت داشته باشه.

csharpcollegian · Apr 9, 2017

the_king گفت:
بهتر بودن بستگی به نیاز ها و اولویت هاتون داره، گاهی اوقات سرعت و سهولت کد نویسی در اولویت ئه، گاهی سرعت اجرا و گاهی امنیت و گاهی قابلیت استفاده مجدد از کد.
فرضا اگه شما قراره در بین مشتری های بانک دنبال مشخصات یک فرد خاص بگردید و ویرایشی رو انجام بدید، احتمالا از لحاظ امنیتی و پهنای باند شبکه اصلا مصلحت نباشه که با Linq حتی مشخصات یک فرد از طریق شبکه منتقل بشه، چه برسه به اینکه لیستی از مشتریان رو دریافت کنید و بین شون دنبال مشتری مورد نظر بگردید. Stored Procedure اینجا این مزیت رو داره که درخواست لیست مشتریان اش اصلا از محیط سرور خارج نمیشه، همونجا روی سرور جستجو رو خیلی سریعتر انجام میده.
در نظر بگیرید که هر زبان و Framework ای که در کد #C تون بکار بگیرید نهایتا با SQL Server از طریق دستورات SQL ارتباط برقرار میشه. یعنی اگر Linq to SQL و ADO.NET Entity Framework و ... امتیازی داشته باشند در ساده تر کردن کد نویسی ئه. معایب شون اولا همیشه کاهش سرعت اجرا است، چون تبدیل کد به دستورات SQL به هر حال سربار داره و ثانیا تمامی معایب و مزایایی که اجرای کد SQL در خارج از محیط Stored Procedure خواهد داشت رو هم دارند. پس در نظر بگیرید که شما وقتی از Entity Framework و Linq استفاده می کنید کد نویسی تون می تونه ساده تر بشه، بستگی به این داره که چقدر نسبت به SQL براتون ساده تر به نظر بیاد، اما در مقابل سرعت اجرای تراکنش رو قدری کاهش می دهید، ممکنه اصلا محسوس نباشه یا اونقدر تراکنش ها پیچیده و مکرر باشه که این کاهش سرعت به چشم بیاد.
و به هر حال چه مستقیما کد SQL بنویسید و چه از Linq کمک بگیرید با Stored Procedure این تفاوت ها رو داره :

Stored Procedure تحت پوشش امنیتی که پایگاه داده رو محصور کرده قرار گرفته، به همین دلیل امنیت اش در بالاترین حدی ئه که خود پایگاه داده ازش برخورداره.

از اونجایی که Stored Procedure روی سرور و در کنار پایگاه داده اجرا میشه، داده ها رو کنار خودش می بینه و نیازی به ارسال داده و کد و ترافیک سنگین بین سرور و برنامه نیست و بار ترافیک بین برنامه و سرور میتونه خیلی کم باشه.

سطوح امنیتی بهتری برای Stored Procedure وجود داره، شما می توانید بگید فلان کاربر ئه SQL Sever فقط اجازه داره فلان Stored Procedure ها رو اجرا کنه. یعنی مستقیما حتی حق نداره جداول رو ببینه.

اون کد SQL ای که شما می نویسید قبل از اجرا باید توسط سرور کامپایل بشه، بنابر این اگه ده بار اجراش کنید ده بار کامپایل میشه، برای همین در بهترین شرایط هم سرعت اجرای Stored Procedure که از قبل کامپایل شده بیشتر ئه.

و احتمالا در کاهش دوباره کاری و استفاده مجدد از کد های قبلی Stored Procedure مزیت داشته باشه.

جناب the_king عزیز بابت پاسخ کامل و وقتی که گذاشتین ازتون بسیار ممنونم، فقط یه سوال جزئی دیگه دارم که ممنون میشم راهنمایی بفرمایید
در برنامه نویسی Entity Framework Code First که خیلی هم رو به گسترش هستش، امکان استفاده از Stored Procedure وجود نداره درسته ؟ و باید تمام نیازهای بانک اطلاعاتی رو به کمک همین Linq برطرف کنیم درسته ؟
خیلی ممنونم ازتون

the_king · Apr 9, 2017

csharpcollegian گفت:
جناب the_king عزیز بابت پاسخ کامل و وقتی که گذاشتین ازتون بسیار ممنونم، فقط یه سوال جزئی دیگه دارم که ممنون میشم راهنمایی بفرمایید
در برنامه نویسی Entity Framework Code First که خیلی هم رو به گسترش هستش، امکان استفاده از Stored Procedure وجود نداره درسته ؟ و باید تمام نیازهای بانک اطلاعاتی رو به کمک همین Linq برطرف کنیم درسته ؟
خیلی ممنونم ازتون

نه، مشکلی از این بابت نیست، از ورژن 5 اش به بعد علاوه بر اینکه برای اون Customers تون متد SqlQuery وجود داره، دو متد context.Database.SqlQuery و context.Database.ExecuteSqlCommand هم هست.