اطلاعیه تیم Ado.net
Announcement
http://ayende.com/Blog/archive/2008/...nq-to-sql.aspx
http://codebetter.com/blogs/david.ha...good-home.aspx
http://codebetter.com/blogs/david.ha...the-lines.aspx
در مورد این مطلب کسی می تونه توضیح واضحی بده و آیا من که تازه می خوام linq رو شروع کنم کار درستی می کنم یا نه؟
همچنی در مورد Entity Framework و همچنین Hibernating اگه میشه توضیحی بدهید.
با تشکر
linq to sql یک قسمت از linq هست که به احتمال زیاد در نسخه 4 دیگر روی آن کار نخواهند کرد به این معنی که هیچ تغییر خاصی نخواهد کرد و بابت توسعه آن هزینه ای نمیشه.نوشته شده توسط ultrap30
سلام دوست عزیز،
For the last several months, I have repeatedly heard a rumor that there was no future for LINQ to SQL. One reader even informed me that they heard LINQ to SQL was going to be snuffed and that because of this, their company changed architectural direction away from LINQ to SQL.
Concerned that the rumors may be either true and some developers are on a dead end path, or false and LINQ to SQL adoption may be suffering unnecessarily as a result of the rumors, I emailed Scott Guthrie at Microsoft to get his position on the future of LINQ to SQL.
Scott told me "Regarding LINQ to SQL, we definitely don't have plans to drop this. We plan to continue to fully support this going forward.".
Scott continued with "I actually blog most of my samples using LINQ to SQL these days (I just did one last week on ASP.NET MVC form scenarios and used LINQ to SQL for the data access). Expect to see me continue to blog more about it in the future.".
ref : http://www.linqdev.com/PublicPortal/...spx?EntryID=36
I've just started tweeting!
@Alireza_Maddah
http://blogs.msdn.com/adonet/archive...s-futures.aspx
اما در این پست نیز صراحتا" عبارت LINQ To SQL Is Dead مورد تایید قرار نگرفته است :
Is LINQ to SQL Dead?
We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios. As mentioned, we have been working on this decision for the last few months. When we made the decision, we felt that it was important to immediately to let the community know. We knew that being open about this would result in a lot of feedback from the community, but it was important to be transparent about what we are doing as early as possible. We want to get this information out to developers so that you know where we’re headed and can factor that in when you’re deciding how to build future applications on .NET. We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.
I've just started tweeting!
@Alireza_Maddah
بله ولی دیگر ای یک پروژه جدی نخواهد بود و روی آن سرمایه گذاری نخواهد شد و بیشتر روی ado.net enitity framewordk کار خواهند کرد
We work in the dark, we do what we can, we give what we have.
Our doubt is our passion and our passion is our task.
The rest is the madness of art
LINQ To SQL VS Entity Framework
خلاصه این لینک:
[How will this shake out? I can’t tell you since I have no idea.The EF team (and nHibernate crowd) talk like the train has arrived at the destination already while in reality it has not even left the station. We are still at the station buying tickets (to an unknown destination). Stay tuned.
SQL is a decent base level OR/M, and I had had several people tell me that they are willing to accept its current deficiencies, knowing that this will be fixed in the next version. Now, there isn't going to be a next version, and that is really bad for Microsoft reputation.
و این به این معنی است:
LINQ To SQL has a provider model to support multiple databases but was sealed so it could not be extended. What is the #1 thing about the Entity Framework? Multiple database support. Hmmm....
حتی اگر به تیم Linq To SQL بودجه ای تعلق نگیرد،این پروژه یا در codeplex بصورت متن باز در خواهد آمد یا فروخته میشود به sponser های دیگر.
و این جمله از تیم مغرور ADO.net به معنای یک معضرت خواهی با کلاس است:
We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.
quote=MS Blog]http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx[/quote
حالا ایشالا هر وقت به feedback تاریخ شمسی ما رسیدگی کردند به این مورد ها هم رسیدگی میکنند.اما قطعا ماکروسافت این نکته را نادیده نمیگیرد:
According to Data Direct Technologies’s recent .NET Data Access Trends Survey (November 24th, 2008), 8.5% of production .NET applications use Linq to SQL as their primary data access method
ولی حالا نظر مدیر تیم Linq to SQL را در این باره بشنوید:
We knew that being open about this would result in a lot of feedback from the community, but it was important to be transparent about what we are doing as early as possible. We want to get this information out to developers so that you know where we’re headed and can factor that in when you’re deciding how to build future applications on .NET. We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.
و در آخر مطلبی برای کسانی که تا بحال با LINQ کار نکرده اند:
There is a big difference between LINQ to SQL and LINQ.
LINQ is Language Integrated Query, today we ship the following sources over which one can execute a LINQ query:
- DataSet : LINQ to DataSet
- XML: LINQ to XML
- In Memory Objects: LINQ to Objects
- ADO.NET Data Services (Astoria) Client: LINQ to Data Services
- LINQ to Relational Databases:
- LINQ to SQL – the technology we were discussing in the original post
- Entity Framework (LINQ to Entities)
تاپیک جداگانه ای را میطلبد
یقینا کارایی Linq to Sql در مقایسه با ADO.NET از انعطاف پذیری بالایی برخوردار است :
1- در بحث استخراج داده ها گزینه های بسیاری برای محدود کردن داده های نامربوط به پرس و جوی مورد نظر وجود دارند که گزینه ها و حالات اضافی را در زمان استخراج داده ها و نه بعد از آن
حذف میشوند.
2-در اختیار گذاشتن Join های آماده تا چند سطح . شاید سخت ترین پرس و جوهای موجود را میتوان در Join کردن پیدا کرد. وجود RelationShip ها در دیتابیس به صورت Join های آماده در
Linq to SQL به نمایش گذاشته شده اند. این Join ها در چندین سطح متوالی و توسط تکنولوژی Intellicense قابل دسترسی میباشد و کد SQL این Join ها در زمان استفاده شدن توسط کاربر
تولید و اجرا میشوند.
3- تطابق کامل با مدل برنامه نویسی شئ گرا که دغدغه و عامل جدایی دنیای داده ها از دنیای
Solution های شئ گرا با وجود Linq to SQL و Linq to Entity از بین میرود و اگر کسی به کد نوشته شده یک توسعه دهنده که از Linq to SQL و Linq to Entity استفاده میکند ، نگاه کند پردازش روی اشیاء و آرایه ها را متصور میشود نه داده های استخراج شده بانک اطلاعاتی.
4- از بین بردن تعداد واسطه های مضاعف برای بهره بردن و توسعه سریع نرم افزارهایی که از مدل N'Tier برای پیاده سازی و طراحی استفاده میکنند.اگر از Linq to SQL و Linq to Entity برای توسعه نرم افزار استفاده کنید ، مجبور میشوید از N'Tier برای پیاده سازی و طراحی استفاده کنید و این یک انگیزه و درک است که هیچوقت آنرا بصورت تئوری نیاموخته اید
بنده از Linq to SQL و Linq to Entity در پروژه ای نسبتا پیچیده و حجیم در رابطه با بانک اطلاعاتی استفاده کردم و هیچگونه خطایی را هنوز مشاهده نکرده ام
5- کارایی بسار بالای اشیایی که در رابطه با استخراج داده ها بکار میروند. بطوریکه با تستی که انجام دادم متوجه شدم که بارگذاری و پیمایش یک میلیون رکورد که هرکدام برروی دیسک تقریبا صد بایت حافظه اشغال میکنند فقط 10 مگابایت حافظه را اشغال میکند. در صورتیکه این تعداد رکورد در صورت تبدیل شده به لیست تقریبا 10 برابر حافظه را اشغال میکند.
6- افسار همه چیز در دستان شماست. به این معنی که میتوانید بعد از اینکه از درستی نحو پرس وجو اطمینان حاصل کردید.هر وقت که خواستید از نتیجه خبردار شوید و یا قبل از اینکه نتیجه را ببینید از پرس و جو در ایجاد پرس و جوی دیگری استفاده کنید.
7- کارایی اجرای دستورات SQL . چرا که اگر توجه کرده باشید نحوه نوشتن پرس و جو در Linq با SQL متفاوت است و این تفاوت به ترتیب اجرای هر نشانه در موتور SQL نزدیکتر است تا خود زبان پرس وجوی SQL.
این خصایص قسمتی از قدرت Linq را به نمایش میگذارند. مادامیکه از Linq to SQl برای ایجاد پرس و جو استفاده میکنید زمان بازیابی داده ها بسیار کوتاه خواهد بود. اما با درگیرکردن اشیاء کلاسی زمان کار با داده ها بسیار بالا خواهد رفت.
نتیجه اینکه اگر Linq to SQL و Linq to Entity مشکل و یا باگ داشته باشند میتوان با استفاده از انعطاف پذیری آنها براحتی مشکلات را پشت سرگذاشت. و این در عمل برای شخص خودم بارها اتفاق افتاده است.
موق باشید.
کارایی در چه ضمینه ای؟و تکنیک های بکار رفته در بالا بردن کاراییش چیست؟
ممنون
با سلاممنظور از کارایی 2 دیدگاه کلی را شامل میشود
1- در تعامل با SQL
2- در تعامل با اشیاء دات نت
ترتیب پردازش نشانه ها در موتو SQL میباشد
(8) SELECT
(9) TOP
(1) FROM
(3) JOIN
(2) ON
(4) WHERE
(5) GROUP BY
(6) WITH
(7) HAVING
(10) ORDER BY
با نگاه به این ترتیب و مقایسه با Linq متوجه میشویم که نحو و املای نوشتن پرس و جو در Linq حتی نزدیکتر از زبان پرس وجوی خود SQL میباشد و لازم نیست موتور SQL ترتیب را برای انجام پرس وجو دوباره بررسی کند و تغییر دهد.
همچنین تمام پرس وجوهای گرفته شده توسط Linq to SQL در صورتی به استخراج داده منجر خواهند شد که ما صریحا بخواهیم. اما اگر بخواهیم بدون اینکه پرس و جوی ایجاد شده ، داده ای را استخراج کند ، به عنوان منبع داده برای پرس وجوی دیگر عمل کند ، آنگاه میتوانیم از توانایی Linq بهره برداری کنیم و بدون استخراج داده ها از یک پرس و جو آنرا در پرس و جوی دیگری بکار ببریم .با این ترفند هم املا و نحو را بدون اجرای پرس و جوی اولیه چک میکنیم و هم درخواستی را به موتور SQL نفرستاده ایم.
در هنگام بازیابی داده ها اگر بخواهیم میتوانیم تعیین کنیم که در زمان باز شدن کانکشن ویا پرس و جو از جدول خاصی فلان داده ها به صورت آنی در حافظه بارگذاری شوند و یا داده های مرتبط با بعضی Relationship ها را تحت شرایطی که توسعه دهنده اعلام میکند ، با پدرهایشان در حافظه قرار بگیرند.
2- پرس و جوهایی که توسط Linq to Sql گرفته میشوند ، میتوانند بصورت کامپایل شده در آیند و بصورت متد مستقیما بدون تبدیل اجرا شوند. واقعیت اینست که تمامی پرس و جوهایی که توسط Linq گرفته میشود در زمان اجرا برای اجرا شدن به متد تبدیل میشوند سپس به اجرا در می آیند. این انعطاف پذیری گزینه های بسیاری را برای انتخاب پیش روی یک توسعه دهنده قرار میدهد.
با استفاده از برنامه نویسی شئ گرا و استفاده از سازنده ها میتوانیم زمانیکه یک پرس و جو به اجرا در می آید و اشیاء آن پرس و جو انواع بدون نام نباشند ، پردازش هایی را روی Collection بدست آمده اعمال کنیم.
مثلا اگر نتیجه اجرای یک پرس و جو به استخراج 2000 شئ از نوع Student منجر شود ، و ما بخواهیم تعداد اشیاء استخراج شده را داشته باشیم ، این عملیات باعث میشود پرس و جوی ما یکبار بصورت کامل اجرا شود ، اما اگر در کلاس Student فیلد ایستایی تعریف کنیم که تعداد اشیاء بوجود آمده را بررسی کند آنوقت بدون اجرای دوباره پرس و جو تعداد اشیاء استخراج شده را هم داریم.
جدای از این مسائل Entity ها توانایی تبدیل تمام داده های خود را به انواعی که از مقید سازی
پیچیده پشتیبانی میکنند ، رادارا هستند و تمامی پرس و جوهایی که از طریق Linq to SQL در تعامل با همین Entity ها بوجود می آیند میتوانند به عنوان منبع داده به یک DatagridView بدون تبدیل شدن به لیست عمل کنند. جالبتر اینکه اگر نوع Collection متصل شده به DatagridView از نوع انواع بدون نام باشد ، باز هم عملیات مقیدسازی بدون هیچگونه هیچ عیب و نقصی انجام می پذیرد.
اما جدای از بحث Linq ، اینکه بجای کلمه رکورد از کلمه شئ استفاده میکنم آنهم در کار با بانک اطلاعاتی واقعا لذت بخش است .
موفق باشید.
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول