درک مطلب در درجه‌ای اول به دامنه‌ی لغات شما وابسته است. دامنه‌ی لغات کتاب‌های فنی هم خوشبختانه زیاد وسیع نیست برای مثال نسبت به کتاب‌های رمان و ادبی و امثال آن. بنابراین باید شروع کنید به «خواندن». نه خواندن لغات لغتنامه که هیچ اثری ندارد. لغات را باید در متن یاد بگیرید. مثلا شروع کنید به وبلاگ انگلیسی خواندن. در این سایت OPML را جستجو کنید. تعداد زیادی فید سایت‌های مرتبط برنامه نویسی رو می‌تونید پیدا کنید. خلاصه کم کم به این ترتیب، البته نه از روی تفنن، بلکه به صورت جدی با یاد گرفتن روزی حداقل 10 واژه جدید، ظرف یکسال ترس شما از متون فنی انگلیسی خواهد ریخت.

چون عموما تیم‌های سورس باز، از لشگر مستند ساز و مستند نویس مایکروسافت محروم هستند.
برای مثال یادم هست زمانیکه سیلورلایت 5 بتا ارائه شد (چند وقت قبل)، همان روز حدود بالای 30 مقاله‌ی بلند بالا در مورد تازه‌های محصولی که دقیقا همان روز در یک کنفرانس برای اولین بار معرفی شده، مطلب منتشر شد. خوب ... این یک لشگر سازماندهی شده است. رقابت کردن با این‌ها سخت است.
شما فکر می‌کنید کسانی که کتاب‌های بعدی سیلورلایت 5 را منتشر می‌کنند از کجا مطالب خودشون رو تامین می‌کنند؟ همین 30 تا مقاله رو کنار هم قرار می‌دهند با نگارش خودشون منتشر می‌کنند. راحت میشه نصف یک کتاب.
NHibernate هم به همین صورت، این لشگر مستند ساز رو نداره. به علاوه خیلی اشتباه است اگر تصور کنید NHibernate همان Hibernate جاوا است. خیلی اضافات در NHibernate به دلیل پیشرفت‌های زبان‌های دات نتی وجود دارد که در Hibernate نیست (همین مباحث static reflection ، lambda expression ، LINQ و غیره). خلاصه اینکه NHibernate فقط یک معادل یک به یک، یکی از کتابخانه‌ها‌ی معروف جاوا نیست. شاید نگارش اول آن اینطور بوده.

ضمنا فعلا شما همین کتاب EF 4.1 رو بخرید! اگر به چاپ دوم رسید یعنی می‌شود به انتشار کتاب‌های مشابه امیدوار شد!

نکته مهم: ادیتور متنی جدید آن این مشکل را ندارد چون همین بحث convert line breaks را با enter لحاظ کرده. بنابراین در قسمت:
تنظیمات، اصلی، انتخاب ویرایشگر پست ، گزینه «ویرایشگر به روز شده» را انتخاب کنید.

متاسفانه این مورد کلا فرمت متن را به هم می‌ریزد!

هدف من از این بحث، بحث در مورد refactoring متدی بود که رشته‌ای را که دقیقا نام یکی از خاصیت‌های یک کلاس است را قبول می‌کند. می‌تونست یک مثال دیگر باشد. می‌تونست اصلا ربطی به این INPC‌ نداشته باشد.

- یک بررسی علمی (بدون علامت تعجب احساسی در انتهای جمله) اینجا هست: (+)
در «یک میلیون بار» اجرا، حدودا 10 ثانیه تفاوت اجرا است نسبت به حالت بکارگیری رشته‌ها.
البته شما در عمل، نه در محیط آزمایشگاهی، پیدا کنید برنامه‌ای را که یک میلیون بار بخواهد خواصی را مرتبا به روز کند.
- زمانیکه LINQ هم ارائه شد، اولین مقالاتی که در این مورد ... در مورد نقد آن منتشر شد، تمرکز را گذاشتند روی کارآیی؛ که این کمی کند است! البته الان کمتر کسی است که در پروژه‌هایش حداقل از LINQ to Objects استفاده نکند. به این دلایل:
- هدف استفاده از LINQ اصلا مسابقه‌ی سرعت نیست.
- هدف تولید کدهای Strongly typed که این اهمیت‌ها را دارند: تحت نظر کامپایلر هستند، قابلیت refactoring دارند و intellisense خودکاری را به همراه خواهند داشت. تمام این‌ها نگهداری یک پروژه را (که اصل زمان اختصاص داده شده به توسعه یک نرم افزار هم همین قسمت نگهداری است)، ساده‌تر و قابل تحمل‌تر می‌کند.
- کاهش حجم کدهای نوشته شده. شما می‌تونید حجم بالایی از if-else و for و حلقه‌ها و غیره رو با یک سطر LINQ نمایش بدید. این هم در بالابردن خوانایی و همچنین نگهداری ساده‌تر برنامه مؤثر است.
- تبدیل ساده‌تر اطلاعات خام به اشیاء (LINQ to xyz ها)
و ...

شما خیلی از مزایا رو بدست خواهید آورد اما خوب مسلما این‌ها هزینه هم دارند. اما نه آنچنان که کسی بخواهد از آن‌ها صرفنظر کند.

همچنین Raven DB هم مبتنی بر JSON است.

منهای کاربردهای Ajax ایی، هستند برنامه‌هایی که از JSON برای تبادل اطلاعات استفاده می‌کنند (این وب سرویس‌های غنی دات نت که به این سهولت در زبان‌های دیگر در دسترس نیست). مثلا برنامه utorrent یک API مبتنی بر JSON دارد (utorrent web-api). به این ترتیب می‌شود به آن فایل اضافه کرد، کم کرد، درخواست دریافت داد، آمار درصد دریافت فایل‌ها رو گرفت و غیره. اینجا است که نیاز پیدا می‌کنید بتونید JSON رو دقیق Parse کنید.
یا مثلا گوگل یک سری API خاص خودش را دارد و بعضی از این‌ها فقط خروجی JSON دارند: google data

اگر به آدرس‌های فوق دسترسی ندارید می‌تونید از لینک‌های زیر هم استفاده کنید:
part-1
part-2

https://www.dntips.ir/2010/12/subtitle-tools.html