کتابخانه‌های جی‌کوئری و کلیه مشتقات آن تقریبا ماهی یکبار شخم زده می‌شوند. اگر به کنسول پاور شل نیوگت در VS.NET مراجعه و دستور update-package را صادر کنید، متوجه حجیم عظیمی از تغییرات خواهید شد. تمام وابستگی‌ها هم اخیرا تغییر کردند. بنابراین اگر از یک مجموعه ناهماهنگ استفاده کنید، درسته ... ممکنه چیزی کار نکند.
مثلا jquery.validate.unobtrusive با jquery.validate و jquery «باید» هماهنگ باشند و اگر نیستند دستور update-package را فراموش نکنید. ضمنا پس از به روز رسانی، «باید» ارجاعات به فایل‌های جدید را در viewهای برنامه درست کنید. مثلا پروژه به نگارش جدید jQuery به روز شده، اما مدخل آن در view شما هنوز به نگارش قدیمی اشاره می‌کند. این‌ها یعنی تداخل و نتیجه آن کار نکردن افزونه‌های جدید است.
به علاوه اگر تعاریف اسکریپت‌ها را دستی در ابتدای فایل تعریف کردید دیگر نباید از Scripts.Render در پایین صفحه استفاده کنید. چون این مورد هم سبب می‌شود یکبار دیگر اسکریپت‌ها در صفحه پیوست شوند.

ضمنا من مجددا همین مثال بحث فوق را (نه مثال یک سایت ثالث را) در MVC4 بازنویسی کردم و بدون مشکل کار می‌کند: Sample13Mvc4.zip

- مقاله عنوان کرده اگر کار شما سورس باز است ترکیب فایده‌ای نداره چون مشخص است چکار کردید. (البته این رو برای ساده‌تر کردن کار خودش عنوان کرده!)
- key stretching یا هر روش دیگری، بحث و هدف اصلی من طرح یک نکته بود: از الگوریتم‌های هش عمومی مستقیما استفاده نکنید. روش پیچ و تاب آن باشد بر اساس روشی که انتخاب می‌کنید.
- من از روش ترکیبی استفاده می‌کنم. حتما هم استفاده می‌کنم. چون دقیقا می‌دونم اون کسانیکه این هش‌ها رو زمانیکه از دیتابیس شما بیرون کشیدند، چه ابزارهایی در اختیار دارند.
- حتی زمانیکه کار شما سورس باز است نیز از روش ترکیبی استفاده کنید. پردازش‌های موازی سنگین و استفاده از GPU برای الگوریتم‌های معمولی و متداول تهیه شده. حتی بانک‌های اطلاعاتی بزرگی که برای نگهداری هش‌های آماده تهیه شدن برمبنای هش‌های عمومی هستند. گیرم حتی اگر کار شما سورس باز باشد، تبدیل الگوریتم‌های ترکیبی آن به الگوریتم‌های بهینه قابل اجرای بر روی GPU کار هرکسی نیست.


استفاده مستقیم از الگور‌یتم‌های هش‌های متداول در یک پروژه عمومی با تعداد کاربر بالا = عین حماقت

- در مورد اصول اولیه لایه بندی یک دوره 11 قسمتی در سایت هست. بحث مفصلی است و نیاز به پایه تئوری داره.
- مشکل بعدی کدهای شما به Html.BeginForm بر می‌گرده. زمانیکه پارامتری رو عنوان نکنید به اکشن متد پیش فرض مشخص شده در سیستم مسیریابی اشاره می‌کنه. بهتره که این موارد رو صریحا ذکر کنید تا مشکل نداشته باشید؛ مانند کد زیر. به علاوه شما نمی‌تونید کل یک حلقه رو داخل یک فرم قرار بدید. الان در صفحه، چندین و چند کنترل دریافت اطلاعات دارای یک Id پیدا کردید. اعضای داخل حلقه باید یک فرم را تشکیل بدن؛ در این حالت شیء ارسالی به سرور مثلا Resume خواهد بود و نه ResumeOfViewModel شما که در عمل یک لیست است. بهتر است داخل حلقه این View شلوغ رو Refactor کنید به یک Partial view با مدلی از جنس Resume تا بهتر بتونید مسایل رو مدیریت کنید.

- من هر نوع طراحی رو تائید نمی‌کنم. چرا یک برنامه باید چندین DbContext داشته باشد؟ نیازی نداره. چرا باید چندین ماژول کنترلر داشته باشه؟ 
- سؤال شما خارج از موضوع بحث است (در اینجا بحثی در مورد طراحی «افزونه پذیر» مطرح نشده). برای طراحی افزونه پذیر می‌تونید به مباحث زیر مراجعه کنید:
ابتدا فقط و فقط یک DbContext مرکزی را در کل برنامه تعریف کنید. بعد تنظیمات نگاشت‌ها را به صورت پویا یافته و به آن اضافه کنید. سپس موجودیت‌های مهیا را به صورت پویا یافته و به Context مرکزی اضافه نمائید.
+ در EF نمی‌تونید در عمل چندین DbContext داشته باشید مرتبط با یک دیتابیس. Change tracking در EF بر مبنای یک DbContext کار می‌کند. اگر قرار باشد چندین وهله از DbContextهای مختلف مثلا در طی یک درخواست وجود داشته باشند، یعنی چندین اتصال باز شده به دیتابیس و چندین تراکنش مجزا در حال انجام است (کل بحث جاری از ابتدا). به علاوه قابلیت کار کردن با چندین موجودیت را به صورت همزمان در طی یک تراکنش از دست می‌دهید.
- برای اینکه در حین کار با Structure Map خطای Circular dependency را مشاهده نکنید، نیاز است یک کتابخانه یا حتی یک کلاس واسط طراحی کنید تا مشترکات در آن قرار گیرند.

- نیاز به نمایش دهنده PDF نوشته شده با سیلورلایت دارید. یک سری کار تجاری از تلریک و امثال آن (^، ^) برای اینکار هست.
- حجم فایل نهایی به اندازه کافی فشرده شده است. استفاده از تصاویر یا تعداد صفحات بالا، حجم را بیشتر خواهند کرد به همراه بالا بردن مدت زمان تولید فایل. همچنین یک سری پیوست/خروجی جانبی نیز به فایل اضافه می‌شوند، مانند خروجی اکسل، xml و csv. هر کدام از این‌ها را که مورد نیاز نیستند، در حین تهیه گزارش ذکر نکنید تا فایل نهایی حجم کمتری داشته باشد. بدیهی است تولید هر کدام نیز زمانی را به خود اختصاص خواهند داد.
- مثالی که موجود بود را تست کردم حدود 1 ثانیه بیشتر طول نکشید؛ نه 20 ثانیه.
روشی وجود دارد به نام warmup برای خیلی از کارهای دات نتی. در پشت صحنه سیستم، حین اجرای اولیه برنامه یک گزارش خالی را تولید کنید. به این صورت سیستم JIT دات نت مجبور خواهد شد سریعتر وارد عمل شود (نه در زمان نیاز). در دفعه بعد فراخوانی گزارشات، نتیجه کار بسیار سریع خواهد بود.

بهتر است که model یک view با domain model یکی نباشد. هر view ممکن است در عمل  فقط به تعدادی فیلد محدود نیاز داشته باشد. این‌ها با entityهای تعریف شده یکی نیستند و ضرورتی هم ندارد یکی باشند. حتی ممکن است جهت ارائه یک View تعدادی خاصیت جدید را هم تعریف کنید، اما از حاصل محاسباتی خاص بر روی آن‌ها، یک نتیجه را در بانک اطلاعاتی ثبت کنید.
ضمن اینکه تا این سری 15 قسمتی که به عمد با برنامه کنسول جلو رفته رو تموم نکنید، درک صحیحی از اجزای مختلف آن پیدا نخواهید کرد.
هر زمانی هم خواستید مطلبی را در این سطح آموزش دهید با برنامه‌ی کنسول کار کنید چون هدف در اینجا نحوه نمایش آن با سیلورلایت یا asp.net یا winforms و غیره نیست. هدف آشنایی با زیرساخت‌های اصلی یک فناوری است؛ صرفنظر از نحوه نمایش آن به کاربر.
چگونه باید کلاس‌ها را به بانک اطلاعاتی نگاشت کرد. چگونه باید پس از تغییر کلاس‌ها، بانک اطلاعاتی را با برنامه هماهنگ کرد. چطور باید حالت‌های یک به چند و امثال آن‌را تعریف کرد. چطور باید یک Context را صحیح مدیریت کرد و غیره. هدف این سری، این نوع مباحث پایه‌ای بوده نه فناوری نمایش نهایی آن.

فرم ادیت رو به صورت strongly typed از نوع یک partial view مستقل درست کنید.
سپس در کنترلر مرتبط، یک اکشن متد را مخصوص رندر کردن این partial view در نظر بگیرید. کار آن دریافت اطلاعات مرتبط با Model ارسالی به همین partial view است. سپس در آخر کار آن هم خواهیم داشت:

حالا فراخوانی این اکشن متد توسط jQuery Ajax سبب پر شدن خودکار فیلدهای فرم strongly typed شما هم می‌شود. در حین درخواست، اطلاعات مدل از بانک اطلاعاتی دریافت شده و به Partial view ارسال می‌شود. چون strongly typed است، فیلدهای آن به صورت خودکار پر شده و نهایتا کل partial view به صورت یک رشته آماده شده در اختیار شما خواهد بود. بنابراین، قسمت عمده‌ای از کدهای سمت کاربر فوق کاهش پیدا می‌کنند. چون یک view کامل حاضر و آماده از سرور دریافت شده است که باید به صفحه توسط jQuery اضافه شود.

+
لطفا اینجا رو تبدیل به یک انجمن عمومی نکنید. عنوان بحث ساخت Url بود ... بعد تغییر جهت پیدا کرد به یک عنوان دیگر.
با تشکر از توجه شما.
 

پایه و اساس طراحی سیلورلایت، WPF و WinRT در ویندوز 8 یکی است.
بنابراین از یادگیری سیلورلایت هیچ ضرری نخواهید کرد؛ حتی اگر مستقیما از آن استفاده نکنید. برای مثال کسی که با سیلورلایت آشنا هست راحت می‌تونه به WinRT ویندوز 8 کوچ کنه چون در ویندوز 8 برنامه نویسی برای WinRT «با» دات نت فقط به استفاده از XAML و یکی از زبان‌های دات نتی خلاصه میشه. البته امکان استفاده از HTML خاص WinRT هم هست (که انتقال پذیر نیست و مخصوص کار با زیرساخت‌های WinRT یک سری اضافاتی رو داره) ولی کار با دات نت در این ویندوز برای تولید برنامه‌های مترو، پایه و اساسش همین سیلورلایت و WPF است.
من یک دوره WinRT رو زیرنویس دار کردم (^ ). نکته مهمش این است که در سراسر دوره عمده بحث بررسی تفاوت‌های WinRT با سیلورلایت و WPF است. یعنی اساس یکی است و چیزی دور ریخته نشده. فقط یک سری موارد کم شده چند کنترل زیاد شده، یک سری مباحث برنامه نویسی غیرهمزمان به آن اضافه شده و از این مباحث.

من امیدی به این جماعت ندارم! همین الان حداقل 2 دو شبکه مخصوص برنامه نویس‌ها در این دور و اطراف هست که ... دارند خاک می‌خورند. یک نمونه idevcenter.com است و نمونه دیگر pspcommunity.org . هر دو توسط تعدادی کمتر از 2 تا 3 نفر سرپا نگه داشته شدن. هر دو هم شاید هفته‌ای یک مطلب یا ماهی 4 تا 5 مطلب جدید داشته باشند. این جماعت خیر و برکت نداره! دست و باز و گشاده‌ای نداره.
اما ... تنها راهی رو که عده‌ای تجربه کردن و جواب داده فعالیت‌های محدود، بسته و غیرعمومی است. همین الان هم هست؛ شاید باور نکنید که لینک‌های referrer در کنترل پنل این وبلاگ به یک سری انجمن و سایت غیرعمومی برنامه نویسی ایرانی داره ختم میشه. حتی انجمن‌های عمومی که نمی‌خوام نام ببرم، قسمت‌های خصوصی دارند؛ و قسمت عمومی آن‌ها جهت بهره کشی از عموم کاربران است. مطالب به درد بخور، در قسمت‌های خصوصی و بسته مطرح می‌شود. آری! اینچنین است، بردار!

با سلام،
دوست عزیز. من اکیداً پیشنهاد می کنم سعی در فارسی کردن دانش رایانه نکنید. این خیانت است به آینده علمی کشور. محافظت از زبان پارسی وظیفه تک تک ما ایرانیان است. اما با راه و روش درستش. این علم و اکثر متون فنی آن به زبان انگلیسی بوده و کاربرد روزانه لغات فنی به زبان اصلی، باعث بالا بردن امکان مطالعه مطالب روز توسط تمام سطوح کارشناسان کشور و دانشجویان در این رشته و در سطوح مختلف آن می شود. چه علاقه ای به ریختن آب در چرخ مترجمان دارید ؟؟ آنها کار با ارزشی می کنند. اما ترجمه متون فنی کار عجیبی است وقتی می توان این مسئله را به خصوص در مورد زبانهای فنی حل کرد. واقعاً به نظر شما "دایر کردن فرو رفتنی" کاربردی زیبا و معنا دار است ؟ خواهش می کنم بجز حفظ زبان پارسی به آینده و حال علم کامپیوتر در ایران نیز بیاندیشید. سایت بسیار جالب و به روزی دارید. خسته نباشید و متشکرم.