باگشو تو پروژه خودم دیدم!... خیلی باگ تابلوییه !

از این نمونه گزارش‌های خطا زیاد است. برای مثال
Jquery Ajax call works in all browser except ie 10  

فکر نکنم من با Windows 8 و IE10 و jquery 1.8.3 تست کردن و بخوبی کار می‌کنه. ممکنه مشکل از جای دیگه باشه البته این باگ با jquery 1.8.2 دیده شده

ممنون مطلب مفیدی بود...

اتفاقا یکی از دوستان که پروژه ای با این مشخصات رو داره نگهداری میکنه در مورد استفاده از اوراکل با استفاده از EF تستهایی رو انجام داده و برای مهاجرت از یه لایه پر از دردسر و خطا آماده شده ولی حجم پروژه اجازه سریع این حرکت رو از ایشون گرفته.

مشکل عمومی در بین برنامه نویس‌ها وجود دارد و آن هم این است که فکر می‌کنند آنی که سریع‌تر است بهتر است. خیر! در ADO.NET خام تمام مسایلی که توضیح دادم مانند کش، ترجمه کوئری، نگاشت‌ها و رعایت بسیاری از best practices که در EF لحاظ شده، وجود ندارند. 50 قسمتی مطلب در موردش در سایت هست. در طول زمان همین کلاس‌های sql helper برای لحاظ این الگوها باید تغییر کنند و اینجا است که دست آخر به این نتیجه خواهید رسید، EF از تمام کارهای دست ساز بسیاری از برنامه نویس‌ها، سریعتر و بهینه‌تر است.
کار اصولی با بانک اطلاعاتی صرفا یک select ساده نیست که بر اساس آن کارآیی و یا بهتر بودن روشی را مشخص کنید. 

استفاده از EF برای ارتباط با Oracle واقعا عذاب آور است.
در یکی از پروژه‌ها که بانک اطلاعاتی oracle و نرم افزار asp.net بود مجبور شدیم از همان sqlHelper‌ها استفاده کنیم. حتی در یک برنامه تستی برای یک select ساده از یک جدول با یک میلیون رکورد تفاوت فاحشی بین ado.net و EF5 وجود داشت (100 میلی ثانیه در مقابل 2 ثانیه با رعایت Initialize‌های EF در حالی که خروجی EF در پروفایلر هم همان کوئری بود).

1 - با EF Code first بدون نیاز به دیتابیس می‌تونید یک برنامه رو کامل کنید. (منهای بحث آزمایش)
- کد نهایی تمیزتر. چون کلاس‌ها را خودتان طراحی می‌کنید و توسط ابزارها به صورت خودکار تولید نمی‌شوند، کنترل بیشتر و نهایتا کیفیت بالاتری دارند.
- ساده است. درگیر نگهداری edmx modelها نخواهید بود. به روز رسانی بانک اطلاعاتی آن هم می‌تواند کاملا خودکار شود.
 
2 - دیتاست که کلا کارآیی بالایی نداره. اما ... نهایتا مطمئن هستم خروجی EF (به همراه تمام best practices لحاظ شده در آن) سرعت بالاتری از کلاس‌های دست ساز sql helper موجود در وب دارد. برای مثال سطح اول کش آن خیلی از کوئری‌ها را مجددا به بانک اطلاعاتی ارسال نمی‌کند. قابلیت اجرای به تعویق افتاده کوئری‌های لینک امکان تهیه کوئری‌های بسیار پیچیده را در یک رفت و برگشت مهیا می‌کند. کاری که با sql helperهای معمولی نیازی به چندبار رفت و برگشت دارد. قابلیت‌های lazy loading آن می‌تواند مصرف حافظه و بار سرور را درصورت استفاده صحیح کاهش دهد. کوئری‌های آن strongly typed و پارامتری هستند (تحت نظر کامپایلر + امنیت + سرعت (کوئری‌های پارامتری مانند رویه‌های ذخیره شده کش می‌شوند)). به صورت پیش فرض از تراکنش‌ها استفاده می‌کند و ... خیلی از الگوهای مفید دیگر که چندین سال باید وقت صرف کنید تا نمونه آن‌ها را پیاده سازی کنید. یعنی کار اصولی با بانک اطلاعاتی صرفا یک select ساده نیست که بر اساس آن کارآیی و یا بهتر بودن روشی را مشخص کنید.

سلام

من برای سویچ از NH به EF حداقل دو مشکل عمده دارم:

1. تجربه چند ساله در استفاده از NH و سورس‌های کدهای موجود با NH
2. ترس از تکیه کامل به محصولات فقط یک شرکت (حالا هر شرکتی). البته قبول دارم که همین الان هم همه زندگی ابزارها و روش‌ها و غیره با همین یک شرکت است ولی...

EF یک مزیت بسیار بزرگ نسبت به NH دارد آن هم تعداد برنامه‌نویس‌های خیلی بیشتر آن است. الان EF واقعا فراگیر شده است.

این نکته هم نباید فراموش شود که در خیلی از کاربردها هیچ وقت نه به سقف محدودیت‌های EF می‌رسید نه NH.