‫۱۱ سال و ۱۲ ماه قبل، جمعه ۷ مهر ۱۳۹۱، ساعت ۱۷:۳۴
خیر. مشکلی نداره. Guid قابل حدس زدن نیست. همچنین زمان دریافت آن، برای تعیین اعتبار ورودی دریافتی، از نکته زیر استفاده کنید:
var code = new Guid(inputGuid);
اگر معتبر نباشد و فرمت صحیحی نداشته باشد یک exception صادر خواهد شد که ... خوب است چون ادامه پروسه و پردازش رو متوقف خواهد کرد.

‫۱۱ سال و ۱۲ ماه قبل، پنجشنبه ۶ مهر ۱۳۹۱، ساعت ۱۶:۰۷
ممنون. مطلب جالبی است. یک راه حل عمومی دیگر مبتنی بر jQuery :
//--------------انتخاب خودکار لینک‌های بالای صفحه به ازای صفحه جاری
$(document).ready(function () {
    $("#headermenu a").each(function () {
        var $a = $(this);
        var href = $a.attr("href");
        if (href && (location.pathname.toLowerCase() == href.toLowerCase())) {
            //صفحه جاری را یافتیم
            $a.css({
                "color": "Yellow",
                "border-bottom": "1px solid"                 
             });
        }
    });
});
این روش بر اساس آدرس صفحه جاری و یافتن آن در ناحیه headermenu و سپس رنگی کردن آن کار می‌کند.
‫۱۱ سال و ۱۲ ماه قبل، پنجشنبه ۶ مهر ۱۳۹۱، ساعت ۰۴:۱۵
این یک عادت خوب در EF است. زمانیکه خروجی کار شما IEnumerable باشد، هر بار دسترسی به نتیجه آن، یکبار رفت و برگشت به بانک اطلاعاتی را سبب خواهد شد. برای نمونه در مثال زیر دوبار رفت و برگشت به بانک اطلاعاتی خواهیم داشت (یکبار در حلقه اول و یکبار در حلقه دوم). اما با استفاده از ToList فقط یکبار رفت و برگشت صورت گرفته و اطلاعات اصطلاحا materialized خواهند شد.
var list = ctx.ProjectStatus.Select(...);

foreach (var item in list)
{...}

foreach (var item in list)
{...}
‫۱۱ سال و ۱۲ ماه قبل، چهارشنبه ۵ مهر ۱۳۹۱، ساعت ۲۱:۱۳
 IEnumerable فقط خواندنی است.
ICollection یک IEnumerable است که قابلیت Add و Remove به آن اضافه شده.
IList یک ICollection است که به اعضای آن از طریق ایندکس‌ها می‌توان دسترسی اتفاقی داشت.
در تمام مثال‌های EF Code first این سایت از
ICollection برای معرفی خواص راهبری استفاده شده چون EF برای انجام اعمال داخلی خودش به مجموعه‌هایی که قابلیت افزودن یا حذف عناصر را داشته باشند، نیاز دارد. به علاوه اگر به سورس EF هم مراجعه کنید برای تشخیص روابط بین کلاس‌ها به دنبال ICollection می‌گردد.
همچنین رسم است حین انتخاب اینترفیس‌هایی از این دست که از هم مشتق می‌شوند، روال انتخاب «the least specific abstraction» رعایت شود. یعنی انتخاب کوچکترین پیاده سازی با حداقل نیازهایی که کاربرد مورد نظر را برآورده می‌کند.

‫۱۱ سال و ۱۲ ماه قبل، چهارشنبه ۵ مهر ۱۳۹۱، ساعت ۱۵:۰۶
خیر. به ازای هر SaveChanges یک تراکنش خاتمه یافته و تراکنش جدیدی آغاز می‌شود (این موارد رو می‌تونید با SQL Server Profiler دقیقا مشاهده کنید). 
+ ضرورتی ندارد در یک تراکنش، از چندین و چند SaveChanges استفاده کنید؛ از این جهت که EF از مکانیزم Tracking برخوردار است و می‌تواند با یک SaveChanges ، چندین و چند عملیات insert و update را (بهینه‌ترین حالتی را که محاسبه کرده) با هم در طی یک تراکنش بر اساس مواردی که ردیابی کرده، انجام دهد.  

‫۱۱ سال و ۱۲ ماه قبل، چهارشنبه ۵ مهر ۱۳۹۱، ساعت ۱۳:۳۳
طراحی EF Code first مبتنی است بر روان بودن و سادگی؛ هر چند پشت صحنه ساده‌ای ندارد. هر وهله از DbContext به صورت خودکار یک تراکنش را تشکیل می‌دهد و در زمان بسته شدن و dispose، این تراکنش را commit می‌کند (همچنین متد SaveChanges در پشت صحنه از تراکنش‌ها بهره می‌گیرد). هر استثنایی این بین رخ دهد، تراکنش rollback خواهد شد. به همین جهت الگوی واحد کار مطرح شده تا تعداد وهله‌های زیادی از DbContext هربار ایجاد نشوند و کل عملیات در یک DbContext یا یک تراکنش انجام شود.