در خود انجمن مثال های زیادی از کار با ADO.NET هست که از جدول رکورد می خوانند و می نویسند. ببینید در همه شون دستورات SQL رو می بینید؟ در پشت پرده تمامی ارتباط ها SQL هست ولی در کدی که می نویسید ممکنه حتی یک سطر کد SQL هم بکار نره. از این لحاظ هیچ فرقی بین کاری که داخل DataSet و Context انجام میشه نیست، همه شون دستورات SQL رو از شما مخفی می کنند. این که شما در کدتون مستقیما از SQL استفاده بکنید یا نه کاملا مربوط به نظر برنامه نویس و کاری است که میخواد بکنه. "ما باید از دستورات SQL برای ذخیره سازی استفاده کنیم" حکمی است که شما صادر می کنید، یک عقیده شخصی و فارق از واقعیت ها. از اون باید ها است که شما اختراع می کنید، نه در این انجمن و نه در سایت مایکروسافت و نه در کتاب های برنامه نویسی همچین بایدی ذکر نشده.
یک پایگاه داده کوچک در SQL Server یا هر سیستم سازگار با ADO.NET دیگری که مایل هستید بسازید که یک جدول داخلش باشه با دو تا رکورد، یک اندیس که کلید جدول ئه و یک نام که رشته متنی ئه.
صورت پروژه این باشه که بدون هیچگونه درج کد SQL در یک فرم دو تا Button و یک TextBox و یک ListBox داریم.
یک دکمه برای خواندن و نمایش نام ها در ListBox و یک دکمه برای اضافه کردن رکورد جدید به جدول که نام اش در TextBox قرار داره.
حالا شما این پروژه رو با Entity Framework بنویسید، من بدون Entity Framework می نویسم و مقایسه می کنیم.
خیلی ممنون استاد.
توی این کد زیر :
کد:
string conectionString = @"Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=E:\Project\Visual Studio\C#.Net\Saved Project\0 Practice\WinForm\Practice 1\Practice 1\Database1.mdf";
string commandText = "SELECT * FROM tblPerson";
using (SqlDataAdapter dataAdapter = new SqlDataAdapter(commandText, conectionString))
{
using (DataTable dataTable = new DataTable())
{
dataAdapter.Fill(dataTable);
this.dataGridView1.DataSource = dataTable;
}
}
هیچ اروری نمیده اما توی شی DataGrideView ام ، فقط فیلدهای جدول ام را نشون میده و رکوردهاش را نشون نمیده (با اونکه جدول دیتابیس ام پر هه و رکورد داره)
مشکلش از کجاست؟
بعد اینکه برای دیتابیس Sqlite میشه عملیات مربوط به دیتابیس را توسط متد Parallel.Invoke فراخونی و استفاده کرد دیگه؟ یعنی اینکه بجای اینکه در نخ جدید اجرا کنیم ، در این متد اجرا کنیم؟ (ان شاء ا... که در هسته ی جدید اجرا کنه)
بعد اینکه میشه کاری کرد که اطلاعات ، مستقیما از دیتابیس ، توی شی DataGrideView مون بریزه ؟ یعنی اطلاعات توی رم (شی DataTable) ریخته نشه . چون ممکنه جدول مون توی دیتابیس پر حجم باشه (مثلا 2 گیگ حجم اش باشه) اما طرف به اون مقدار ، حافظه ی اصلی نداشته باشه . (البته منظورم این نیست که فیلدها را دونه دونه یا رکورد به رکورد بخونیم مثل DataReader که حجم خیلی کمتری میگیره)
اون AttachDbFilename هم که مسیر فایل را مقدار لیترال دادم ، توجه نکنید . این پروژه ی تستی هه .
بعد اینکه ، ساده ترین کدی که میتونستم توی ADO.Net بنویسم که همه ی اطلاعات را نشون بده ، همین بودم . از این که نمیشه کد رو خلاصه تر کرد . میشه؟
اما توی Entity Framework ، رسیدنِ به همین هدف (هدف در کد بالا) ، اولا نیاز به دستورات sql نداشت و دوما خط هاش کمتر بود و سوما چون شی گرا بود ، درکش بسیار راحت تر بود .
من اینطور به مساله نگاه نمی کنم، مزیت ها و معایب رو کنار هم قرار میدم، ببینم در مقابل چقدر مزایا چقدر معایب حاصل میشه. این رو وقتی می توانید درست درک کنید که به هر دو طرف اشراف داشته باشید.
از من پرسیدید Entity Framework رو پیشنهاد می کنم، گفتم که دلیلی برای پیشنهاد کردنش ندارم. وقتی همچین پیشنهادی رو می کنم که معایب بزرگی در ADO.NET ببینم یا مزایای خیلی برجسته در Entity Framework ببینم که انتخابش نکنید تاسف خواهید خورد. خوب همچین حالتی رو نمی بینم. میخواهید رویش بحث کنید، می توانید ولی وقتی که به هر دوی آنها مسلط باشید، نه الان.
بله .
واسه ی همین هاست که تا حالا کسی بهتر از شما را توی برنامه نویسی ندیدم .
جایی که بیشتر (شاید هم همه) برنامه نویس ها (و حتی شرکت ها) ، چشم شون را میبندن و از یه چیزی استفاده میکنن ، شما شرایط را میبینین و با منطق پیش میرید .
مثلا من ندیدم کسی (حتی اساتیدهای دانشگاه) توی پروژه ی دسکتاپ اش ، استفاده از Sqlite را پیشنهاد کنه اما شما با منظق درست پیشنهاد دادین .
یا همین قضیه ی Entity Framework . من ندیدم کسی استفاده ازش را پیشنهاد نکنه (هر چند من تا حالا زیاد قانع نشدم)
یا اساتیدهایی رو دیدم که در زبان سی شارپ ، چیزهایی که شما به من آموزش دادین را اصلا نمیدونن (مثال خیلی هه) و از آموزش دادن شون مشخص هه که به فلسفه ی اون موضوع نرسیدن (منظورم این نیست من پی بردم یا فلسفه شو میدونم یا کامل میدونم) ولی شما دقیق همه رو گفتین .
خیلی ممنونم ازتون استاد .
معمولا ولی همیشه نه. برنامه نویس خودش تصمیم میگیره. ممکنه اون کار در Linq معادل داشته باشه ولی نوشتنش پیچیده باشه، یا اصلا برنامه نویس با SQL راحت تر باشه.
کسی که بلد نیست که نباید اصلا سراغش بره. برای چی از Entity Framework استفاده کنه وقتی میخواد خودش دستورات SQL بده.
Linq قرار بوده تا حدی که از قابلیت هاش برمیومده شما رو از نوشتن دستورات SQL بی نیاز کنه و خودش دستورات SQL رو بسازه. وقتی دستورات SQL رو می نویسید دیگه هم Linq درگیر نیست و هم اجرا کننده Entity Framework نیست. این چیز بدی نیست، در مواردی هم ناچار میشید، ولی وقتی مدام و برای هر کار ساده ای همچین کاری رو بکنید به این معنا است که از قابلیت ها استفاده نکردید و این Framework رو بیخودی انتخاب کردید.
حالا ببینم چی میشه . شاید از طریق Entity Framework نَرَم .
