<p>
    <label for="FirstName">First Name:</label>
    <span id="FirstName">@ViewData["FirstName"]</span>
</p>

<p>
    <label for="FirstName">First Name:</label>
    <span id="FirstName">@Model.FirstName</span>
</p>

@if(Model.IsAnonymousUser) {
    <img src="@Url.Content("~/content/images/anonymous.jpg")" />
} else if(Model.IsAdministrator) {
    <img src="@Url.Content("~/content/images/administrator.jpg")" />
} else if(Model.Membership == Membership.Standard) {
    <img src="@Url.Content("~/content/images/member.jpg")" />
} else if(Model.Membership == Membership.Preferred) {
    <img src="@Url.Content("~/content/images/preferred_member.jpg")" />
}

public static string UserAvatar(this HtmlHelper<User> helper)
{
    var user = helper.ViewData.Model;
    string avatarFilename = "anonymous.jpg";
    if (user.IsAnonymousUser)
    {
        avatarFilename = "anonymous.jpg";
    }
    else if (user.IsAdministrator)
    {
        avatarFilename = "administrator.jpg";
    }
    else if (user.Membership == Membership.Standard)
    {
        avatarFilename = "member.jpg";
    }
    else if (user.Membership == Membership.Preferred)
    {
        avatarFilename = "preferred_member.jpg";
    }
    var urlHelper = new UrlHelper(helper.ViewContext.RequestContext);
    var contentPath = string.Format("~/content/images/{0}", avatarFilename)
    string imageUrl = urlHelper.Content(contentPath);
    return string.Format("<img src='{0}' />", imageUrl);
}

@Html.UserAvatar()

ioc.For<IIdentity>().Use(() => HttpContext.Current.User.Identity);
ioc.For<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
ioc.For<HttpServerUtilityBase>().Use(() => new HttpServerUtilityWrapper(HttpContext.Current.Server));
ioc.For<HttpRequestBase>().Use(ctx => ctx.GetInstance<HttpContextBase>().Request);

Would you like help creating single-page applications (SPAs)? Maybe you've worked with tools like jQuery and AJAX, but what about Ember? With a simple syntax and an emphasis on reuse and components, this JavaScript framework can make it very easy to create interactive pages. Get a close look at Ember, plus lots of demos and practical tips with popular experts Adam Tuliper and Christopher Harrison, in this three-hour event for the MVA community 

Jquery یکی از کتابخانه‌های قدرتمند JavaScript است که به طور وسیعی مورد استفاده طراحان وب قرار میگیرد. این کتابخانه از سه دیدگاه بسیار سودمند است؛ ابتدا به دلیل مدیریت قدرتمند Dom که دارد و دوم اینکه ارتباط Ajax را بسیار راحت کرده است و هم اینکه بستر پلاگین نویسی را فراهم ساخته است، به طوری که میلیون‌ها کتابخانه ثالث از روی همین کتابخانه ایجاد شده است. زمانیکه شما به مطالعه این کتابخانه رو آورید و نمونه کدهای مختلفی از آن را بر روی شبکه اینترنت ببینید، ممکن است این کتابخانه در عین سادگی که دارد، ابهاماتی را برای شما ایجاد کند که یکی از آن‌ها نحوه استفاده از رویدادهاست. لیست زیر نمونه‌ای از نحوه رویداد نویسی در جی کوئری است:
دو مورد اول در لیست، یکی هستند و در واقع مورد اول یک میانبر برای مورد دوم محسوب میشود و در پشت صحنه در واقع همان خط دوم مورد استفاده قرار میگیرد. از مزایایی که در مورد bind نسبت به استفاده مستقیم از اسم رویداد میتوان گفت این است که میتواند در یک زمان به چند رویداد متصل شود. به عنوان مثال کد زیر نمونه‌ای از آن است:
در خط بالا المان‌هایی که با کلاس test مزین گشته‌اند، به سه رویداد و یک تابع بایند یا متصل گشته‌اند. برای غیرفعال سازی این رویدادها میتوان از متد unbind استفاده کرد:
برای استفاده از این دو حالت باید در نظر گرفت که تنها المان‌هایی به این رویداد متصل یا بایند میگردند که در زمان بررسی DOM، یعنی بارگذاری اولیه سایت وجود داشته‌اند و در صورتیکه المان جدیدی به صفحه اضافه شود یا اینکه جایگزین المان دیگری شود، بایند نخواهند شد و تنها المان‌های قدیمی کار خواهند کرد و در صورتیکه المانی از روی صفحه حذف شود، این اتصال از بین خواهد رفت.

مورد سوم، متد معروف live است که هم بر روی المان‌های قدیمی و هم بر روی المان‌های جدید جواب میدهد. ولی نکته‌ای که در مورد live وجود دارد این است که در نسخه‌های اخیر به دلیلی که در جلوتر عنوان میشود حذف شده است و دیگر وجود ندارد. دلیل این حذف هم این میباشد که در واقع متد live برای اینکه افزوده شدن المان‌های جدید را زیر نظر بگیرد، به خود المان متصل نمیشود؛ بلکه به به کل سند HTML یا بدنه وب سایت متصل میشد و کل ناحیه را مورد بررسی قرار میداد تا اگر المان جدیدی اضافه شد، بتواند رویداد مرتبطی را بر روی آن اجرا کند. همچنین در این حالت رویدادی‌هایی از این نوع، در اجداد این المان نیز اجرا میگردند. یعنی رویداد، از المان آغاز شده، سپس به سمت اجدادش انتقال خواهد یافت (به این حالت Bubbling up گفته میشود). پس برای اینکه این ناحیه کوچک‌تر و جزئی‌تر شود، متد دیگری جایگزین آن شد؛ به نام delegate:
این حالت که جایگزین حالت قبلی شده است بدین صورت است که ناحیه‌ای با آی دی area وجود دارد که المان‌هایی با کلاس test در آن قرار میگیرند. پس، از این به بعد، بجای اینکه کل سند بررسی شود، فقط همین بخش مورد بررسی قرار میگیرد و رویداد کلیک، بر روی المانی با کلاس test اجرا میشود و bubbling up کمتری خواهیم داشت و میتوان آن را کنترل کرد. برای حذف رویدادهای live از المان‌های مربوطه، میتوان از die و برای delegate از undelegate همانند unbind استفاده کرد. همچنین حالت استفاده از زنجیره‌ای از متدها در متد live در نظر نگرفته شده، ولی بعد از دلیگیت میتوان از متدهای دیگر، به صورت زنجیره‌ای استفاده کرد.

 از نسخه 1.7 به بعد  توصیه شده‌است به جای تمامی متدهای بالا،  از on استفاده شود که به مراتب کارآایی بهتری دارد و اکثر این متدهای بالا، حذف یا منسوخ شده اعلام گشته‌اند و احتمال حذف آن‌ها در نسخه آتی وجود دارد. به عنوان مثال delegate از نسخه 3 به بعد منسوخ اعلام شده‌است. نحوه صدا زدن on بجای دلیگیت به شکل زیر خواهد بود:


نکته مهم : بعضی‌ها برای راحتی کار بدین شکل کار میکنند ولی این شیوه فرقی با متد live  ندارد.

در حالت Bubbling up این گونه است که اگر کدی به شکل زیر باشد و رویداد کلیک روی text هدف ما باشد، رویداد کلیک به سمت اجداد آن حرکت میکند. یعنی ابتدا رویداد کلیک b اجرا میشود، سپس a و سپس رویداد کلیک div اجرا میشود و الی آخر:
برای حل این مسئله و جلوگیری از این اتفاق میتوان از متد stopPropagation استفاده کرد که در حالت استفاده از متد on جواب میدهد؛ ولی در متد live، استفاده از آن بی فایده است. کد زیر را میتوانید با حالت‌های مختلف بررسی کرده و نتیجه این متد را در کنسول مرورگر خود ببینید:

نکته تکمیلی اینکه در استفاده از دلیگیت و on میتوان رویدادها را به شکل زیر هم مورد استفاده قرار داد:

چند تا از نمونه هایی که عملا به صورت عمیق (درگیر شدن در کد‌های هسته و ماژول‌های آن و توسعه سیستم) با آنها کار کرده ایم:

برای PHP

برای .NET

1. nopCommerce(فروشگاه‌های تا متوسط و عملیات تجاری متوسط) -سفارشی سازی متوسط
   
2. VirtoCommerce(فروشگاه‌های تا سایز بزرگ و عملیات تجاری بزرگ) -سفارشی سازی پیشرفته، زمان بر است ولی برای کارهای بزرگ لازم است.
   

ولی در VirtoCommerce باید تسلط کافی به مفاهیم برنامه نویسی شی گرا، لایه بندی، معماری سرویس گرا، C# و AngularJs و liquid و چندین مورد دیگر داشته باشید تا پروژه جلو برود. اینجا با چند اپلیکیشن طرف هستید و این پروژه برای اجرا شدن روی shared hosting ساخته نشده است.

آن چیزی که مشتری از یک سیستم ecommerce می‌بیند با چیزی که مدیران و پرسنل مجموعه فروشگاه می‌بینند متفاوت است، در اغلب سیستم‌ها چیزی که مستری می‌بیند تقریبا مشابه است ولی پشت صحنه زمین تا آسمان تفاوت دارد.

پشت صحنه یک فروشگاه اتفاقات زیادی می‌تواند در جریان باشد، چیزی که در بخش مدیریت سفارش nopcommerce وجود دارد ساده است، مدیریت امور مالی، مدیریت تحویل کالا، مدیریت اسناد، مدیریت موجودی و ... می‌تواند بسیار پیچیده‌تر باشد و حتی به کمک نرم افزارهای دیگر یا سرویس‌های آنلاین دیگر مدیریت شود.

Delivery, Payment, Tax, Inventory, Warehouse, Localization, Globalization و موارد متعدد دیگری هر کدام در این فروشگاه‌های آماده در حد نیاز پیاده سازی شده اند، و این نیازی که توسط تیم توسعه آن تعریف شده مشتریان هدف آن را مشخص می‌کند. اگر کمی در marketplace هر کدام از این‌ها چرخی بزنید و ماژول‌های مشابه را بررسی کنید صرفا از تفاوت قیمت و سطح پشتیبانی کیفیت هر کدام مشخص می‌شود.

مثلا ما در یکی از پروژه‌ها VirtoCommerce را به عنوان پایه پروژه انتخاب کردیم ولی بر اساس منطق تجاری تعریف شده ماژول‌های زیادی برای آن توسعه داده شد، حتی تغییراتی در هسته آن ایجاد شد. این پروژه 6 ماه با یک تیم 5 (مدیر پروژه+2 نفر دات نت+ گرافیست+1 نفر آندروید+ 1 نفر IOS) نفره طول کشید. در صورتی که مشابه همین کار را با Prestashop برای یک پروژه 15 درصد کوچکتر با یک تیم 3 نفره در مدت 4 ماه انجام دادیم. تازه در virtocommerce هیچ گزارشی وجود ندارد، همه چیز با PowerBi باید انجام شود.

قیمت اولی تقریبا 4 برابر دومی بود. هر دو پروژه وب سایت و نسخه native موبایل داشته اند.

ما درگیر تکنولوژی وابزار نبودیم چون تیم مسلط به هر کدام را داریم، ولی اگر مثلا فقط به .net مسلط هستید در همان حوزه ادامه دهید. البته PHP هزینه‌های کمتری دارد. 

حرف آخر: حتی در مایکروسافت هم چند وقت یک بار میندازن دور از اول می‌نویسند، رسیدن به ebay کار زیادی می‌برد شاید در طول مسیر حتی چند بار تغییر جهت بدهید. دیجی کالا اصلا اندازه ebay نیست. با هم مقایسه نکنید. در حال حاظر متد‌های تجارت الکترونیک در حال پیشرفت و تحول هستند. دیجیکالا فقط چند متد را در خود دارد فروشگا هایی هستند که چندین متد فروش را همزمان پیاده سازی کرده اند و مدیریت آنها به صورت یکپارچه انجام می‌شود.

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