احساس می‌کنم، کمی از صحبت‌های من اشتباه برداشت شده است. قالب باید HTML باشد، اما مهم نیست که این قالب توسط چه کسی تولید شده است. برای مثال من در پروژه‌ی خودم یک کنترلر تعریف کرده ام که درآن همه‌ی action‌ها فقط partialview بر می‌گردانند. حال قبل از اینکه این فایل‌های cshtml تبدیل به html شوند و به کلاینت برگردانده شوند، من با razor عملیات دلخواه خود را انجام می‌دهم.

- همین پیاده سازی فوق رو با یک برنامه کنسول ویندوزی هم تست کردم، کار می‌کنه. می‌خواهید یک امتحانی بکنید. به نظر در پشت صحنه به صورت خودکار به memory cache سوئیچ میشه. فقط باید ارجاعی را به اسمبلی System.Web اضافه کنید.
- ضمن اینکه در برنامه‌های دسکتاپ این مساله اهمیت آنچنانی نداره؛ چون سطح دوم کش بیشتر جهت ارائه محتوایی یکسان و با دسترسی عمومی، به کاربران همزمان سایت کاربرد داره. عمده اطلاعات برنامه‌های دسکتاپ با سطح دسترسی خصوصی و مخصوص به یک کاربر است؛ در یک چنین مواردی نباید از سطح دوم کش استفاده کرد وگرنه به مشکلات امنیتی و فاش سازی اطلاعاتی که نباید عمومی شوند، منتهی خواهد شد (البته اگر مثلا از یک وب سرویس استفاده شده باشه؛ اگر همه چیز لوکال است، این مساله صادق نخواهد بود؛ اما باز هم نیازی به سطح دوم کش نیست. چون مهم‌ترین هدف آن کاهش بار بانک اطلاعاتی، در مراجعات مکرر کاربران است؛ که در حالت لوکال آنچنان معنی ندارد).

این تعرفه صرفا برای تعیین نرخ نسبی حوزه ی IT در کشور است که برای مقابله با عده ای سودجو که بازار این بخش را به ... کشیده اند و حرمتی که از آن باقی مانده قابل بیان نیست و افرادی که در این حوزه فعال است گاه سود های بسیار کلانی از راه های بسیار ساده کسب می کنند؛ارائه شده است.مشکلات یک فعال در حوزه ی نرم افزار پایه ای تر از این صحبت هاست... .کمی آن سو تر - حقوق سالانه  ی یک مهندس نرم افزار براساس گزارش سایت یاهو چیزی در حدود صد هزار دلار در سال برآورد شده است(10 شغل برتر دنیا - آمار سال 2010).خوب در هیچ صنفی اختلاف تا این حد فاحش نیست و این خود معضل این بخش در کشور را بیانگر است!کاری که (طبق گفته ی  مقاله)"حقیقتا جز کارهای بسیار سخت" است و این سطح درآمد برایش معرفی می شود(واقعا دید مردم از نرم افزار و IT و ... در کشور چیست؟-مشکلات پایه ای ترند!)

بحث اینجا کار تیمی است نه تک نفره و deploy به سرور. به همین جهت صحبت از مخزن کد شد و SVN.
این‌ها مشکلات web deploy است:
-با IIS 6 آنچنان سازگار نیست و IIS7 را طلب می‌کند. (با روش فوق سرور شما آپاچی هم باشد کار می‌کند)
-بحث rollback با webdelpoy اصلا معنی ندارد. اما با سورس کنترل به سادگی انجام می‌شود. فرض کنید الان به اشتباه یک سری کار به مخزن SVN ارسال شده. بلافاصله هم با روش فوق در ریشه سایت قرار گرفته. اصطلاحا revert به نگارش پایدار قبلی در SVN بسیار ساده است.
+ تمام مزیت‌های ورژن کنترل را هم لحاظ کنید. با روش فوق دقیقا مشخص است چه کسانی روی فایل‌ها کار کرده‌اند و چه زمانی. تاریخچه ارسال‌ها موجود است. امکان حرکت بین نگارش‌های مختلف و سوئیچ بین آن‌ها معنا پیدا می‌کند و ...
- روش فوق نیاز آنچنانی به داشتن دسترسی بالا روی سرور ندارد.

به همین جهت برای کار حرفه‌ای با web deploy از برنامه team city و یک سری مخلفات دیگر استفاده می‌کنند. یک سری 5 قسمتی رو اینجا می‌تونید پیدا کنید: (+)
و پس از مطالعه به این نتیجه خواهید رسید که روش فوق پایدارتر و دردسر کمتری دارد. حتی روی یک سرور لینوکسی هم قابل پیاده سازی است

این مشکلات زمان VB6 (مرحوم) هم بود (مثلا هنگام انتخاب فونت برای یک متن فارسی باید script آن را در صفحه انتخاب فونت روی Arabic گذاشت تا درست نمایش داده شود). قبل از دات نت. قبل از یونیکد شدن رشته‌ها در سیستم‌های متداول دات نت به صورت پیش فرض از نگارش یک آن.
دلفی‌های جدید هم به نظر رشته یونیکد را پیش فرض خود کرده‌اند (نگارش‌های بعد از 2007). بهتر است برنامه خودتون رو به این نگارش‌ها ارتقاء بدید (تا به صورت خودکار همه چیز منجمله کامپوننت‌ها(ی جدید) بر مبنای رشته‌های یونیکد کار کنند)، همچنین بانک اطلاعاتی هم باید واقعا رشته‌های یونیکد را ساپورت کند. مثلا در SQL Server ، بین نوع‌های varchar و nvarchar تفاوت وجود دارد.
در کل من با این صفحه کلید و برنامه‌های دات نت، نه مشکلی در ثبت دارم و نه مشکلی در نمایش (چند سال هست). همچنین نیم فاصله هم جهت تایپ فارسی پشتیبانی می‌شود + ساپورت فونت‌های قدیمی هم لحاظ شده.

سلام و عرض ادب
اگر کلیت مشکل فارسی و عربی را بررسی کنیم به گمانم به 3 سطح زیر میرسیم
1- تبدیل در ویندوز
2- تبدیل در UI
3- تبدیل در بانک اطلاعاتی

در تایید فرمایش شما ، شخصا چون صدها کاربر با میلیونها رکورد پراکند در سطح کشور دارم که همگی از هر دو ویندوز XP و 7 میخواهند استفاده کنند و هزینه تبدیل اطلاعات قبلی به فارسی بسیار بالاست ، ترجیح میدهم ادامه ورود اطلاعاتم روی عربی باشد .

اما در سطح بانک اطلاعاتی بدلیل کنترلهای فراوان و احتمال خطا زیاد موافق نیستم (اگر نیاز است میتوانم توضیح بیشتری بدهم )

در سطح UI هم همانگونه که فرمودید مشکلات عدیده ایی وجود دارد

در سطح ویندوز بهترین راه حل است ..اما نمیدانم چگونه میتوانم انرا پیاده کنم . اگر بتوانید راهنمایی بفرمایید من در مورد پیاده سازی و یا سرمایه گذاری روی پیاده سازی مشکلی ندارم

مرسی

وکیلی

Javan_Soft@Yahoo.com

با اینکه معمولا از نوشته های شما استفاده می کنم اما عموما با نظر شما در استفاده از استانداردها مخالفم.
اینکه ما استاندارد منقرض شده ۲۹۰۱ و از آن بدتر ترکیب ی و ک عربی را استفاده کنیم نه بجاست و نه ارزشی دارد.
اصولا همین محتوایی هم که وجود دارد اشتباه است و این همه اشتباه را نباید ادامه داد. اینکه هیچ کیبورد فارسی کلمه پ و ژ را مطاق استاندارد ندارد دلیلی بر عدم استفاده نیست. خود من روی لپ تاپم هیچ حرف فارسی نوشته نشده و براحتی ا آن کار می کنم و به هیچ کسی هم جواب نمیدهم که چرا جای حروف به فلان شکل است.
در ضمن جهت اطلاع عرض کنم که جای پ و ژ در استاندارد ۲۹۰۱ هم دقیقا همین جایی بود که در ۹۱۴۷ هست و این دو کلید که شما ذکر کردید جای دیگری ندارد.
تا آنجا هم که من اطلاع دارم در اولین سرویس پک ویندوز ۷ قالب استاندارد ۹۱۴۷ جانشین قالب کیبورد فارسی غیر استاندارد ویندوز می شود و خود بخود یک بخش عظیمی از مشکلات حل می شود.
از شما هم خواهش می کنم که کلمه ۲۰۹۱ را با ۲۹۰۱ عوض کنید که خوانندگانی که اطلاع کافی راندارند و به خودشان هم برای مطالعه زحمت نمی دهند در آینده دچار مشکل نشوند.
در ضمن امیدوارم بزودی شاهد ستفاده شما از استاندارد ۹۱۴۷ باشیم و کیبوردی هم برایآن تولید شود

در NHibernate سنتی کار ساخت نگاشت‌ها توسط یک سری فایل xml صورت می‌گیرد که ممکن است حین تهیه اولیه پر از اشتباهات تایپی و غیره باشند.این نوع فایل‌ها تحت کنترل کامپایلر نبوده و در حین کار مشکلات آن‌ها مشخص می‌شود.
در Fluent NHibernate کار تعریف نگاشت‌ها با استفاده از کدهای strongly typed دات نتی صورت می‌گیرد که بلافاصله تحت کنترل کامپایلر هستند. همچنین مبحث Auto Mapping آن را می‌توانید در قسمت‌های بعد مطالعه کنید. امکان unit test نوشتن برای نگاشت‌های این روش بدون حتی درج یک رکورد در دیتابیس میسر است که باز هم در طی چند قسمت به آن پرداخته شده. با توجه به اینکه در روش دوم تعریف نگاشت‌ها، بلافاصله تحت نظر کامپایلر است امکان refactoring ساده‌تر آن نیز مهیا است.
در روش Fluent اگر علاقمند بودید که این فایل‌های XML را هم مشاهده کنید به قسمت Mappings در Fluently.Configure خود، متد ExportTo را اضافه کنید.

سؤال شما به موضوع بحث مرتبط نیست. آیا جایی در مقاله به typed dataset‌ اشاره شده یا کار نقد orm های مختلف صورت گرفته؟ ... بگذریم.

در مورد typed dataset ها ، بله نسبتا تا حدودی و تا حد نازلی بله! شبه ORM هستند که این مشکلات را دارند:
- مشکل Synchronization بین آن‌ها و دیتابیس مساله ساز است که در یک ORM‌ خوب باید این مساله حل شده باشد.
- join table queries در طراح آن کار نمی‌کند!
- query syntax استانداردی نداشته و هنگام کار با دیتابیس‌های مختلف (نوع‌های مختلف) این مورد مساله ساز می‌شود.
- typed dataset کمتر حال و هوای یک ORM واقعی و دنیای شیء گرایی با اشیایی که وابستگی کمی به دیتابیس دارند را ارائه می‌دهد.
- کلا dataset اشیایی با سربار بالا در دات نت فریم ورک مطرح هستند و زمانیکه کارآیی مطرح هست سعی می‌شود به روش‌هایی دیگری کوچ شود.
همچنین از لحاظ مباحث serialization هم بسیار ضعیف و کند عمل می‌کنند.
- زمانیکه از typed dataset استفاده می‌کنید عملا مدل رابطه‌ای دیتابیس خود را با business layer مخلوط کرده‌اید.