درسته که نویسنده مطلب به عمد اون مثال رو گفته ولی حتما هستن کسایی که این اشتباه رو میکنن مثلا همون دوستانی که بخاطر استفاده از SP از ORM استفاده نمیکنن و...

این مطلب از لحاظ محتوا ایراد دارد. کوئری‌های LINQ در ORMها نهایتا تبدیل به SQL می‌شوند و روی بانک اطلاعاتی اجرا خواهند شد. این اجرا هم توسط sp_executesql انجام می‌شود که کاملا متفاوت است از مثال به عمد بی‌ربط فراخوانی exec ساده روی یک رشته، در مقاله فوق. sp_executesql پارامتری عمل می‌کند و همانند exec ساده، جمع زدن یک سری رشته نیست.
خلاصه مطلب فوق به بیانی بهتر:
اگر شما یک رویه ذخیره شده دارید که داخلش از exec ساده استفاده شده، فرقی نمی‌کند که از ORM استفاده می‌کنید یا نه، یا هر حالت دیگری. این روش نا امن است.

مرسی، جالب بود.

برای تحت وب هم بهتون پیشنهاد میکتن که با ASP.NET MVC شروع کنید که سازگاری خوبی با ORM مایکروسافت یعنی Entityframewrok (آشنایی کاربردی با Entityframework )داره و برای شروع مطالب مربوط به ASP.NET MVC در وبسایت و بعد هم برای آشنایی بیشتر و ریز جزئیات بهترین کتاب فارسی ASP.NET MVC در حال حاضر که ترجمه|تالیف آقای مهندس راد هست که خود من هم تهیه کردم کمک بگیرید. البته الگوهای طراحی رو هم در نظر داشته باشید که برای آشنایی باز هم مطالب مربوط به آشنایی با الگوهای طراحی در همین سایت و کتابی که خدمتتون عرض شد، اشاره شده است.

شما هنوز از ie 8 استفاده می‌کنید؟!

نویسندگان این سایت که قرار نیست برای همه بیان بگن مثلا می‌تونی کوئری‌های لینک رو با تاخیر اجرا کنی. مثلا deferred execution هم وجود داره برای ترکیب چند کوئری با هم. یا این کوئری‌ها همشون پارامتری هستند و مثل رویه‌های ذخیره شده کش میشن. 

ما یک نرم افزار تقریبا بزرگ داریم که قبلا تحت ویندوز نوشته شده.حالا می‌خواهیم تحت وب هم ایجاد کنیم(c#).دیتابیس sql2005  است دیتابیس هم قرار نیست که تغییر کند  چند تا سوال داشتم چون نمیدونم از orm استفاده کنم یا sql queries !

در صورتی کوئری‌های پیچیده داشته باشیم باز هم میشود از orm استفاده کرد؟

سرعت واکشی اطلاعات به چه صورت است؟یعنی به ازای هر select به دیتابیس connectin میزند؟

درسته سوتی دادم حق با شماست (از همه دوستان معذرت می‌خوام)

مطلب در ژانویه 2010 منتشر شده و مربوط به VS 2012 نیست

اگر این کتابخانه‌ها نبودند و امروزه تا این حد تکامل پیدا نکرده بودند، هیچ وقت سیلورلایت و فلش از صحنه روزگار محو نمی‌شدند. در بسیاری از اوقات هدف ساخت یک برنامه غنی وب است. برنامه‌ای که تجربه کاربری آن همانند برنامه‌های دسکتاپ باشد. مثلا صفحه مدام چشمک نمی‌زند و کاربر احساس نمی‌کند که مدام رفت و برگشت به سرور وجود دارد، کنترل‌های auto-complete مانند برنامه‌های دسکتاپ و یا حتی شکیل‌تر و غنی‌تر از آن‌ها در وب وجود دارند، برنامه‌های تک صفحه‌ای وب، اعتبار سنجی‌های سمت کاربر، بدون هدایت او به سرور و دریافت پاسخ آنی و بسیاری از مثال‌های دیگری که در جهت بهبود کاربری در وب مطرح هستند. در اینجا HTML خالص بدون جاوا اسکریپت حرفی برای گفتن ندارد. HTML خالص صرفا جهت ارائه محتوا اختراع شده است نه طراحی برنامه‌های غنی وب و کار ما هم با ASP.NET و یا فناوری‌های مشابه، تولید برنامه‌های وب است و نه صرفا ارائه محتوا. اگر قرار است مثلا چند صفحه توضیح مشخصات شرکتی را در اینترنت قرار دهید، این تنها به معنای ارائه‌ی محتوا است. نیازی به برنامه خاصی ندارد. چند صفحه HTML به همراه مقداری هم CSS برای اینکار کافی است. اما اگر همینجا قرار شد از کاربر اطلاعات دریافت کنید، نیاز است تجربه کاربری او را غنی کنید.

سوالی که برای من مطرحه اینه که آیا استفاده از JqGrid و کلا کامپوننت هایی که بر اساس Jquery عمل می‌کنند در طراحی سایت به صلاح هست یا خیر و تا چه حد امروزه وب سایت ما باید به javascript وابسته باشه ، که در صورت غیر فعال شدن آن توسط کاربر دچار مشکل نشیم