- روش شما هم خوبه. یعنی نهایتا همان SelectListItem بحث شده در مطلب فوق رو ایجاد و استفاده کردید. مطلبی که عنوان کردم در مورد قسمت اصلی پیاده سازی checkbox list بود.
- ضمن اینکه در کدهای شما به نظر می‌رسه از الگوی واحد کار استفاده نشده. شما در هر متدی یک new دارید. یعنی یک اتصال به بانک اطلاعاتی. این مورد در برنامه‌های وب می‌تونه سرعت کار و بار بانک اطلاعاتی رو (بسته به تعداد کاربر) به شدت بالا ببره.
کار الگوی واحد کار، مدیریت یک Context به ازای تمام متدهای درگیر است. یک کانکشن و یک تراکنش به ازای n متد و n کلاسی که برای انجام یک کار مورد نیاز هستند.
در این مورد قبلا مفصل توضیح دادم .

از توضیحات مطلب فوق ایده بگیرید. مثلا:
این روشی هست برای انتخاب یک گزینه بر اساس شرط. اگر انتخاب شده بود (یا هر شرط دیگری)، چک مارک آن قرار داده می‌شود.

- در ravendb امکان replication به sql server وجود دارد.
- یکی از اهداف مهم ORMها در دات نت، نوشتن کوئری‌های strongly typed است. در ravendb شما از روز اول با کوئری‌های strongly typed سروکار دارید. همچنین از همان ابتدای کار هم با کلاس‌های دات نتی و نگاشت خودکار آن‌ها کار می‌کنید. کلا ravendb برمبنای معماری و همچنین توانمندی و پیشرفت‌های زبان‌های دات نتی تهیه شده.

Reflection اندکی کند است. در حین توسعه برنامه اگر ویژوال استودیو مرتبا بخواهد کوئری‌های مبتنی بر reflection از اسمبلی‌های شما بگیرد، سرعت کار شما کم خواهد شد و نهایتا ممکن است سبب ناپایداری آن هم بشود (اگر پروژه جاری بزرگ باشد).

در کد فوق که از T4MVC استفاده نشده ولی نحوه تعریف Url شما اشتباه است. قبلا هم در مورد نحوه تعریف صحیح Url در ASP.NET MVC مطلب نوشتم. حتما باید از Url.Action استفاده کنید.
برای اینکه بتونید از Url.Action در اسکریپت‌های خودتون استفاده کنید پایین View جاری یک section به نام مثلا JavaScript درست کنید. در اینجا می‌شود داخل کدهای جاوا اسکریپتی هم از Razor استفاده کرد. سپس این section را در layout در قسمت header صفحه include کنید (در قسمت 14 سری MVC این سایت در مورد این تکنیک کاملا توضیح دادم).

توضیحات بالا برای برنامه‌های وب بهینه شده. در آنجا در Application_EndRequest به صورت خودکار کانکشن بسته میشه (با کد ObjectFactory.ReleaseAndDisposeAllHttpScopedObjects  که نوشته شد).
در برنامه‌های ویندوزی این مدیریت رو باید خودتون دستی انجام بدید و چنین مکانیزمی در آن طراحی نشده.

در عمل عموم کدهای native نوشته شده با سی پلاس پلاس این مشکلات را دارند:
- ناپایدار
- دارای نشتی‌های حافظه بالا
- نا امن
- نیاز به کامپایل مجزا برای سیستم‌های 64 بیتی و 32 بیتی
فقط از این کلمه لذت می‌برند: «سرعت»! اما در 4 مورد فوق حرفی برای گفتن ندارند.

ولی خوب بازسازی این پروژه‌ها با دات نت وقت زیادی می‌گیرد به همین جهت کسی طرف تبدیل آن‌ها نرفته. نوشتن یک html parser خوب و تمام عیار، یک پروژه چند میلیون دلاری است که موزیلا، مایکروسافت، اپل، گوگل و غیره درگیر آن هستند!

- از مقادیر پیش فرض استفاده می‌شود. زمانیکه شما می‌نویسید return view و پارامتری را صریحا مشخص نمی‌کنید، از نام متد فراخوان به عنوان view متناظر استفاده می‌گردد. در اینجا هم به همین نحو است. ارسال به کنترلر متناظر با View جاری و متد پیش فرضی که در routing تعریف شده است، صورت می‌گیرد. البته می‌شود تمام این‌ها را هم صریحا تعریف کرد.
- در این حالت می‌شود Model.property1.property2 الی آخر و کار می‌کند. فقط ابزارهای Scaffolding از این نوع خواص پشتیبانی نمی‌کنند، اما به این معنا نیست که کل فریم ورک مشکلی با آن دارد.
- بله. مثال من یک مثال عمومی بود. شما بر اساس context‌های دریافتی در حین پیاده سازی یک binder می‌تونید اون رو تا حد امکان سفارشی سازی کنید که مثلا برای یک کنترلر خاص یا یک مدل خاص فقط عمل کند.

این تکنیک اصطلاحا Url Rewriting نام دارد.

سیلورلایت به صورت مستقیم با هیچ نوع ORM ایی کار نمی‌کند (چون یک فناوری سمت کاربر است). اما شما در سمت سرور می‌تونید به کمک یک WCF سرویس و مشتقات مشابه آن با EF یا NH و غیره کار کنید و سپس نتیجه را در یک برنامه سیلورلایت مصرف کنید.