قابلیت سفارشی سازی EditorFor در ASP.NET MVC پیش بینی شده‌است و با استفاده از UIHint قابل انتساب به خواص مدل مورد نظر است. البته این مورد برای حالت Code first یا حالتیکه از ViewModels استفاده کنید بیشتر کاربرد دارد.
یک مثال:
فایلی را به نام Upload.cshtml، در مسیر Views/Shared/EditorTemplates با محتوای ذیل ایجاد کنید:
@model string
@Html.Kendo().Upload().Name("@ViewData.ModelMetadata.PropertyName")
سپس برای استفاده از آن فقط کافی است خاصیت مدنظر را با ویژگی UIHint مزین کنید:
[UIHint("Upload")]
public string ImageUrl {set;get;}
‫۱۰ سال و ۵ ماه قبل، چهارشنبه ۱۰ اردیبهشت ۱۳۹۳، ساعت ۰۵:۰۲
کدهای فوق قابل تبدیل به یک Generic handler وب فرم‌ها (فایل‌های ashx) هستند. در اینجا بجای Url.Action فوق برای مقدار دهی img src، خواهید داشت pic.ashx?filename=tst.png.
ضمنا ASP.NET MVC سورس باز است و کدهای متد AddTextWatermark آن‌را در اینجا می‌توانید مطالعه کنید.
‫۱۰ سال و ۵ ماه قبل، سه‌شنبه ۹ اردیبهشت ۱۳۹۳، ساعت ۰۲:۱۰
- How EF6 Enables Mocking DbSets more easily
- Testing with a mocking framework - EF6 onwards 

+ شخصا اعتقادی به Unit tests درون حافظه‌ای، در مورد لایه دسترسی به داده‌ها ندارم. به قسمت «Limitations of EF in-memory test doubles» مراجعه کنید؛ توضیحات خوبی را ارائه داده‌است.
تست درون حافظه‌ی LINQ to Objects با تست واقعی LINQ to Entities که روی یک بانک اطلاعاتی واقعی اجرا می‌شود، الزاما نتایج یکسانی نخواهد داشت (به دلیل انواع قیود بانک اطلاعاتی، پشتیبانی از SQL خاص تولید شده تا بارگذاری اشیاء مرتبط و غیره) و نتایج مثبت آن به معنای درست کار کردن برنامه در دنیای واقعی نخواهد بود. در اینجا Integration tests بهتر جواب می‌دهند و نه Unit tests.