وحید نصیری وحید نصیری
نظرات مطالب
استفاده از نگارش سوم Google Analytics API در سرویس‌های ویندوز یا برنامه‌های وب
«من اکانت ساختم پراپرتی هم درست کردم»
کافی نیست. تمام مراحل باید انجام شوند.
این خطاها صرفا به معنای غیرمعتبر بودن یکی از مراحل است که سبب شده‌اند اطلاعات آن مرحله خاص قابل دریافت نباشد.
‫۱۰ سال و ۳ ماه قبل، سه‌شنبه ۲۱ مرداد ۱۳۹۳، ساعت ۱۴:۴۱
یاسر مرادی یاسر مرادی
نظرات مطالب
ELMAH و حملات XSS
با سلام، در چک لیست ASP.NET MVC مورد زیر وجود دارد 
آیا مورد زیر کماکا معتبر است ؟
- فیلتر پیش فرض مدیریت خطاها حذف و بجای آن از ELMAH استفاده شود. 
با سپاس
‫۱۱ سال و ۹ ماه قبل، شنبه ۲۸ بهمن ۱۳۹۱، ساعت ۱۷:۳۳
میثم خوشبخت میثم خوشبخت
مطالب
معرفی Selector های CSS - قسمت 7
61- :any-link
تمامی تگ‌هایی را انتخاب می‌کند که می‌توانند نقش لینک را در صفحه ایفا کنند. در واقع تگ‌های a، area و link را انتخاب می‌نماید که دارای ویژگی href هستند و به عنوان لینک عمل می‌کنند.
<style>
    :any-link {
        color: red;
    }
</style>
<a href="page1.htm">Link 1</a>
در مثال فوق، متن Link 1 به رنگ قرمز نمایش می‌یابد.
           Selector  نسخه CSS
No No
 No
 No No :any-link  4
62- :local-link
تمامی لینک هایی را انتخاب می‌کند که با آدرس صفحه‌ی جاری یکسان می‌باشند.
<style>
    :local-link {
        color: red;
    }
</style>
<a href="http://www.example.com/article/">Link 1</a>
<a href="http://www.example.com/article">Link 2</a>
<a href="http://www.example.com/article/">Link 3</a>
<a href="http://www.example.com/article/12">Link 4</a>
با فرض اینکه آدرس صفحه‌ی جاری http://www.example.com/article/   می باشد مثال فوق را بررسی می‌کنیم. متن Link 1 و Link3 به رنگ قرمز نمایش می‌یابند، زیرا مشابه آدرس صفحه‌ی جاری می‌باشند.
           Selector  نسخه CSS
No No
 No
 No No :local-link  4 
63- :local-link(n)
تمامی لینک هایی را انتخاب می‌کند که آدرس آنها با آدرس صفحه‌ی جاری یکسان بوده و n بخش از آدرس آنها با بخش‌های آدرس جاری یکسان باشند. در واقع n، تعداد بخش هایی از آدرس لینک را مشخص می‌کند که با بخش‌های آدرس صفحه‌ی جاری مطابقت داشته باشند. در مطابقت آدرس، از scheme، username، password، port، query string و fragment صرف نظر می‌شود تا یکسان بودن آدرس را تشخیص دهد. سپس تشخیص می‌دهد کدام بخش‌های آدرس با هم یکسان می‌باشند. جهت اطلاع باید عرض کنم که شکل کامل یک آدرس به صورت scheme:[//[user:password@]host[:port]][/]path[?querystring][#fragment] می‌باشد.
<style>
    :local-link {
        color: red;
    }
    :local-link(0) {
        text-decoration: none;
    }
    :local-link(1) {
        text-decoration: overline;
    }
    :local-link(2) {
        background: blue;
    }
</style>
<a href="http://www.example.com">Link 1</a>
<a href="http://www.example.com/2016">Link 2</a>
<a href="http://www.example.com/2016/01">Link 3</a>
<a href="http://www.example.com/2016/01/">Link 4</a>
<a href="http://www.example.com/2016/01/02">Link 5</a>
<a href="https://www.example.com/2016/01/">Link 6</a>
<a href="http://example.com/2016/01">Link 7</a>
با فرض اینکه آدرس صفحه‌ی جاری http://www.example.com/2016/01/ می باشد مثال فوق را بررسی میکنیم. Link 1 تحت تاثیر Selector دوم، بدون زیرخط نمایش می‌یابد. Link 2 تحت تاثیر Selector دوم و سوم، بدون زیرخط و با روخط نمایش می‌یابد. Link 3، Link 5 و Link 6 تحت تاثیر Selector دوم و سوم و چهارم، بدون زیرخط، با روخط و پس زمینه‌ی آبی نمایش می‌یابند. Link 6 به دلیل استفاده از https نمی‌تواند تحت تاثیر Selector اول قرار بگیرد. Link 4 تحت تاثیر Selector اول و دوم و سوم و چهارم، به رنگ قرمز، بدون زیرخط، با روخط و پس زمینه‌ی آبی نمایش می‌یابد. Link 7 هم بدون تاثیر هیچ Selector ی بر روی آن، بدون قالب باقی می‌ماند، زیرا قسمت host لینک با آدرس مطابقت ندارد.
           Selector  نسخه CSS
No No
 No
 No No :local-link(n)  4
64- :active-drop-target
تگی را انتخاب می‌کند که در حال حاضر به عنوان مقصد یک تگ drag (کشیده) شده در نظر گرفته شده است. به عبارت دیگر، تگی را با عمل drag کشیده ایم و بر روی یک تگ مقصد قرار داده ایم، ولی هنوز عمل drop یا رها کردن صورت نگرفته است.
              Selector  نسخه CSS
No No
 No
 No No :active-drop-target   4 
65- :valid-drop-target
تگی را انتخاب می‌کند که در حال حاضر به عنوان مقصد یک تگ drag (کشیده) شده در نظر گرفته شده است و برای عمل drop معتبر می‌باشد. به عبارت دیگر، تگ مقصد امکان پذیرش یک تگ را با عمل Drag & Drop دارد.
              Selector  نسخه CSS
No No
 No
 No No :valid-drop-target   4 
66- :invalid-drop-target
تگی را انتخاب می‌کند که در حال حاضر به عنوان مقصد یک تگ drag (کشیده) شده در نظر گرفته شده است و برای عمل drop معتبر نمی‌باشد. به عبارت دیگر، تگ مقصد امکان پذیرش یک تگ را با عمل Drag & Drop ندارد.
              Selector  نسخه CSS
No No
 No
 No No :invalid-drop-target   4  
<style>
    :active-drop-target {
        background: blue;
    }
    :valid-drop-target {
        border: 1px solid green;
    }
    :invalid-drop-target {
        border: 1px solid red;
    }
    .container {
        width: 200px;
        height: 200px;
    }
</style>
<div class="container"></div>
<img src="image.jpg" draggable="true"/>
در مثال فوق، با Drag نمودن تصویر بر روی تگ div، تحت تاثیر Selector اول، رنگ پس زمینه‌ی div آبی می‌شود. اگر امکان پذیرش img توسط تگ div وجود داشته باشد، کادری سبز رنگ دور تگ div نمایش می‌یابد در غیر اینصورت کادر قرمز رنگ دور آن نمایش خواهد یافت.
67- :current
تگی را انتخاب می‌کند که در حال حاضر در حال نمایش یا ارائه می‌باشد. این Selector در زمان پردازش صوت، تصویر، نمایش زیر نویس و غیره در تگ canvas مورد استفاده قرار می‌گیرد.
              Selector  نسخه CSS
No No
 No
 No No :current   4 
68- :past
تگی را انتخاب می‌کند که قبل از :current نمایش یافته است.
              Selector  نسخه CSS
No No
 No
 No No :past   4 
69- :future
تگی را انتخاب می‌کند که بعد از :current نمایش یافته است.
              Selector  نسخه CSS
No No
 No
 No No :future   4 
هر سه Selector فوق می‌توانند با دریافت آرگومان به صورت مجموعه ای از Selector ها، تگ‌های خاصی را انتخاب کنند یا نتیجه‌ی انتخاب را محدود نمایند. اگر بدون آرگومان به کار روند، تک مورد نظر را بدون در نظر گرفتن محدویت انتخاب می‌نمایند. 
<style>
    :past(div,p) {
        background: red;
    }
    :current(div,p) {
        background: green;
    }
    :future(div,p) {
        background: yellow;
    }
</style>
در مثال فوق، تگ‌های div یا p که در حال حاضر در حال نمایش می‌باشند، با پس زمینه‌ی سبز، تگی که قبل از :current نمایش یافته است با پس زمینه‌ی قرمز و تگی که بعد از :current نمایش خواهد یافت با پس زمینه‌ی زرد نمایش می‌یابد.
70- :placeholder-shown
تمامی تگ‌های input و textarea را انتخاب می‌کند که در حال نمایش یا حاوی placeholder می‌باشند و هنوز متنی در آنها وارد نشده است. در حال حاضر به صورت آزمایشی و با vendor prefix قابل استفاده است.
<style>
    :placeholder-shown {
        color: gray;
    }
</style>
<input placeholder="Enter Username"/>
<input placeholder="Enter Password"/>
در مثال فوق، اگر در هر کدام از تگ‌های input، هیچ متنی وارد نشده باشد، متن‌های Enter Username و Enter Password به رنگ طوسی نمایش می‌یابند.
              Selector  نسخه CSS
-webkit- -wekit-
 -ms-
 -moz- -webkit- :placeholder-shown   4 















‫۸ سال و ۱۰ ماه قبل، سه‌شنبه ۱۵ دی ۱۳۹۴، ساعت ۰۵:۲۵
وحید نصیری وحید نصیری
مطالب دوره‌ها
تامین مقادیر پارامترها در حین نگاشت‌های AutoMapper
متد Project To را می‌توان به عنوان متد پیش فرض حین کار با ORMها درنظر گرفت؛ با این مزایا:
- جلوگیری از Lazy loading اشتباه
- کاهش تعداد فیلدهای بازگشت داده شده‌ی از دیتابیس و محدود ساختن آن‌ها به خواصی که قرار است نگاشت شوند. در حالت معمولی استفاده‌ی از متد Mapper.Map، تمام فیلدهای مدل بارگذاری شده و سپس در سمت کلاینت توسط AutoMapper نگاشت خواهند شد. اما در حالت استفاده‌ی از متد ویژه‌ی Project To، کوئری SQL ارسالی به بانک اطلاعاتی نیز مطابق نگاشت تعریف شده، تغییر کرده و خلاصه خواهد شد.

در این حالت یک چنین سناریویی را درنظر بگیرید. مدل متناظر با جدول بانک اطلاعاتی ما چنین ساختاری را دارد:
public class UserModel
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}
و اطلاعاتی که قرار است در رابط کاربری نمایش داده شوند، به این شکل تعریف شده‌اند:
public class UserViewModel
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string UserIdentityName { get; set; }
}
در اینجا خاصیت UserIdentityName قرار است در زمان اجرا، برای مثال توسط مقدار User.Identity.Name تامین شود و در حالت کلی، خاصیت یا خاصیت‌های ثابتی را داریم که نیاز است در حین نگاشت انجام شده، در زمان اجرا مقدار ثابت خود را دریافت کنند.


تعریف نگاشت‌های پارامتری

برای حل این مساله، از روش زیر استفاده می‌شود:
 string userIdentityName = null;
this.CreateMap<UserModel, UserViewModel>()
 .ForMember(d => d.UserIdentityName, opt => opt.MapFrom(src => userIdentityName));
ابتدا یک متغیر خالی را تعریف می‌کنیم. از آن جهت تهیه‌ی یک lambda expression صحیح در قسمت MapFrom استفاده خواهیم کرد. کار این متغیر خالی، تهیه‌ی یک عبارت جایگزین شونده‌ی در زمان اجرا است.
اکنون جهت استفاده‌ی از این متغیر با قابلیت جایگزینی، می‌توان به نحو ذیل عمل کرد:
var uiUsers = users.AsQueryable()
                   .Project()
                   .To<UserViewModel>(new { userIdentityName = "User.Identity.Name Value Here" })
                   .ToList();
در اینجا لیست کاربران بانک اطلاعاتی، به لیست UserViewModel‌ها نگاشت شده و همچنین مقدار خاصیت UserIdentityName آن‌ها نیز از پارامتری که به متد Project To ارسال گردیده‌است، تامین خواهد شد.


کدهای کامل این مثال را از اینجا می‌توانید دریافت کنید.
‫۹ سال و ۵ ماه قبل، چهارشنبه ۳۰ اردیبهشت ۱۳۹۴، ساعت ۰۱:۲۶
وحید نصیری وحید نصیری
مطالب
آشنایی با Refactoring - قسمت 1

کارهای سورس باز قابل توجهی از برنامه نویس‌های ایرانی یافت نمی‌شوند؛ عموما کارهای ارائه شده در حد یک سری مثال یا کتابخانه‌های کوچک است و در همین حد. یا گاهی هم انگشت شمار پروژه‌هایی کامل. مثل یک وب سایت یا یک برنامه نصفه نیمه دبیرخانه و امثال آن. این‌ها هم خوب است از دیدگاه به اشتراک گذاری اطلاعات، ایده‌ها و هم ... یک مزیت دیگر را هم دارد و آن این است که بتوان کیفیت عمومی کد نویسی را حدس زد.
اگر کیفیت کدها رو بررسی ‌کنید به یک نتیجه‌ی کلی خواهید رسید: "عموم برنامه نویس‌های ایرانی (حداقل این‌هایی که چند عدد کار سورس باز به اشتراک گذاشته‌اند) با مفهومی به نام Refactoring هیچگونه آشنایی ندارند". مثلا یک برنامه‌ی WinForm تهیه کرده‌اند و کل سورس برنامه همان چند عدد فرم برنامه است و هر فرم بالای 3000 سطر کد دارد. دوستان عزیز! به این می‌گویند «فاجعه‌ای به نام کدنویسی!» صاحب اول و آخر این نوع کدها خودتان هستید! شاید به همین جهت باشد که عمده‌ی پروژه‌های سورس باز پس از اینکه برنامه نویس اصلی از توسعه‌ی آن دست می‌کشد، «می‌میرند». چون کسی جرات نمی‌کند به این کدها دست بزند. مشخص نیست الان این قسمت را که تغییر دادم، کجای برنامه به هم ریخت. تستی ندارند. ساختاری را نمی‌توان از آن‌ها دریافت. منطق قسمت‌های مختلف برنامه از هم جدا نشده است. برنامه یک فرم است با چند هزار سطر کد در یک فایل! کار شما شبیه به کد اسمبلی چند هزار سطری حاصل از decompile یک برنامه که نباید باشد!
به همین جهت قصد دارم یک سری «ساده» Refactoring را در این سایت ارائه دهم. روی سادگی هم تاکید کردم، چون اگر عموم برنامه نویس‌ها با همین موارد به ظاهر ساده آشنایی داشتند، کیفیت کد نویسی بهتری را می‌شد در نتایج عمومی شده، شاهد بود.
این مورد در راستای نظر سنجی انجام شده هم هست؛ درخواست مقالات خالص سی شارپ در صدر آمار فعلی قرار دارد.



Refactoring چیست؟

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


قسمت اول - مجموعه‌ها را کپسوله کنید

برای مثال کلاس‌های ساده زیر را در نظر بگیرید:

namespace Refactoring.Day1.EncapsulateCollection
{
    public class OrderItem
    {
        public int Id { set; get; }
        public string Name { set; get; }
        public int Amount { set; get; }
    }
}

using System.Collections.Generic;

namespace Refactoring.Day1.EncapsulateCollection
{    
    public class Orders
    {
        public List<OrderItem> OrderItems { set; get; }
    }
}

نکته اول: هر کلاس باید در داخل یک فایل جدا قرار گیرد. «لطفا» یک فایل درست نکنید با 50 کلاس داخل آن. البته اگر باز هم یک فایل باشد که بتوان 50 کلاس را داخل آن مشاهده کرد که چقدر هم عالی! نه اینکه یک فایل باشد تا بعدا 50 کلاس را با Refactoring از داخل آن بیرون کشید!

قطعه کد فوق، یکی از روش‌های مرسوم کد نویسی است. مجموعه‌ای به صورت یک List عمومی در اختیار مصرف کننده قرار گرفته است. حال اجازه دهید تا با استفاده از برنامه FxCop برنامه فوق را آنالیز کنیم. یکی از خطاهایی را که نمایش خواهد داد عبارت زیر است:

Error, Certainty 95, for Do Not Expose Generic Lists

بله. لیست‌های جنریک را نباید به همین شکل در اختیار مصرف کننده قرار داد؛ چون به این صورت هر کاری را می‌توانند با آن انجام دهند، مثلا کل آن را تعویض کنند، بدون اینکه کلاس تعریف کننده آن از این تغییرات مطلع شود.
پیشنهاد FxCop این است که بجای List از Collection یا IList و موارد مشابه استفاده شود. اگر اینکار را انجام دهیم اینبار به خطای زیر خواهیم رسید:

Warning, Certainty 75, for Collection Properties Should Be ReadOnly

FxCop پیشنهاد می‌دهد که مجموعه تعریف شده باید فقط خواندنی باشد.

چکار باید کرد؟
بجای استفاده از List جهت ارائه مجموعه‌ها، از IEnumerable استفاده کنید و اینبار متدهای Add و Remove اشیاء به آن‌را به صورت دستی تعریف نمائید تا بتوان از تغییرات انجام شده بر روی مجموعه ارائه شده، در کلاس اصلی آن مطلع شد و امکان تعویض کلی آن‌را از مصرف کننده گرفت. برای مثال:

using System.Linq;
using System.Collections.Generic;

namespace Refactoring.Day1.EncapsulateCollection
{
    public class Orders
    {
        private int _orderTotal;
        private List<OrderItem> _orderItems;

        public IEnumerable<OrderItem> OrderItems
        {
            get { return _orderItems; }
        }

        public void AddOrderItem(OrderItem orderItem)
        {
            _orderTotal += orderItem.Amount;
            _orderItems.Add(orderItem);
        }

        public void RemoveOrderItem(OrderItem orderItem)
        {
            var order = _orderItems.Find(o => o == orderItem);
            if (order == null) return;

            _orderTotal -= orderItem.Amount;
            _orderItems.Remove(orderItem);
        }
    }
}


اکنون اگر برنامه را مجددا با fxCop آنالیز کنیم، دو خطای ذکر شده دیگر وجود نخواهند داشت. اگر این تغییرات صورت نمی‌گرفت، امکان داشتن فیلد _orderTotal غیر معتبری در کلاس Orders به شدت بالا می‌رفت. زیرا مصرف کننده مجموعه OrderItems می‌توانست به سادگی آیتمی را به آن اضافه یا از آن حذف کند، بدون اینکه کلاس Orders از آن مطلع شود یا اینکه بتواند عکس العمل خاصی را بروز دهد.


‫۱۳ سال و ۱ ماه قبل، سه‌شنبه ۱۲ مهر ۱۳۹۰، ساعت ۱۳:۱۶
وحید نصیری وحید نصیری
نظرات اشتراک‌ها
دوراهی انتخاب NHibernate و Entityframework
استفاده از NH در مقابل EF Code first سورس باز اشتباه است؛ به دلایل زیر:
- توهم پشتیبانی از بانک‌های اطلاعاتی مختلف توسط NH . به شخصه با حداقل یک مورد نیم بند آن سروکار داشتم: SQL-CE. تقریبا بیشتر از نیمی از توانایی‌های این بانک اطلاعاتی در NH لحاظ نشده و حتی یک کوئری ساده از تاریخ تا تاریخ را توسط آن نمی‌توانید تهیه کنید. این مورد برعکس EF Code first است. کامل و بی‌نقص کار می‌کند. کلا تمام محصولات مایکروسافت به همین نحو هستند. اگر عنوان می‌کنند این محصول دو قابلیت دارد، واقعا این دو قابلیت، درست کار می‌کنند. نه اینکه عنوان کنند 100 قابلیت را ارائه می‌دهیم و فقط 10 تای آن کامل پیاده سازی شده باشند.
- تیم مدیریتی به شدت مغرور و ناراحت NH. باز هم برای این تیم ناراحت، جهت تکمیل نقایص کار با SQL-CE بیشتر از یکسال قبل وصله‌ای رو ارسال کردم. تا به امروز حتی یک پاسخ که آیا خوبه، بده ... ارسال نشده. با اکثر همکاری‌ها هم به همین نحو رفتار می‌کنند.
خلاصه حال و هوای یک پروژه سالم سورس باز را ندارد.
- پس از ارائه EF Code first این پروژه تقریبا غیرفعال شده: (^)
- نیم بند بودن پشتیبانی از LINQ. باز هم اگر تصور می‌کنید که راحت می‌تونید مثل EF از کوئری‌های LINQ در اینجا استفاده کنید، سخت در اشتباه هستید.
- دیر به روز شدن کتابخانه‌های جانبی آن. این مساله هم به مدیریت بد پروژه NH بر می‌گردد. شاید بیشتر از 10 مورد افزونه برای NH هست، مانند کش و اعتبار سنجی و غیره. اما ... صاحبان آن مشخص نیستند! امروز NH3 ارائه می‌شود، سه ماه بعد کتابخانه اعتبارسنجی متناظر با آن. تیم NH هم حاضر نشده تمام این‌ها رو کنار هم قرار بده و یک کار یکپارچه رو ارائه کنه. NH اعتبار خودش رو از این افزونه‌های موجود در NH Contrib کسب می‌کنه، اما حاضر نیستند مدیریت و نگهداری یکپارچه آن‌ها را قبول کنند.
- ناسازگاری با اکوسیستم دات نت. اگر از NH استفاده کنید مدام در حال جنگ با دات نت هستید. مثلا سیستم اعتبار سنجی EF با سیستم اعتبار سنجی سمت کلاینت و سرور MVC یکپارچه است. با NH اینطور نیست و از این نوع مثال‌ها زیاد است. همین مساله حجم کاری شما را چندبرابر می‌کند.
- طراحی زمخت NH در مقابل طراحی روان EF. برای مثال در EF Code first شما به ندرت نیاز خواهید داشت که نگاشت‌ها را تعریف یا حتی سفارشی سازی کنید. یک سری پیش فرض بسیار عالی در آن به صورت توکار (و نه به شکل افزونه) وجود دارد که حجم کاری شما را به شدت کاهش می‌دهند. در NH کتابخانه fluent nh سعی کرده که اینکار را انجام دهد اما جالب اینجا است که این کتابخانه از طرف تیم اصلی NH اصلا تحویل گرفته نشده و ... دست آخر هم یک روش دیگر را برای نوشتن نگاشت‌ها با کد تهیه کردند.
- مستندات NH کامل نیست. برای مثال شاید یک سری بلاگ‌های متفرقه را پیدا کنید که در مورد روش تهیه نگاشت‌ها با کد مطلب نوشته باشند ... نه توسط کسانی که این کتابخانه را تهیه کرده‌اند! این روند رو مقایسه کنید با وبلاگ EF مثلا : (^) این بلاگ تا این حد کامل است که مرجع بسیاری از مطالب آموزشی و کتاب‌های مرتبط با EF می‌باشد.
- سیستم migration موجود در EF Code first نسبت به نمونه NH بسیار کاملتر است؛ با قابلیت سفارشی سازی، مقایسه هش مدل‌ها با جداول جهت جلوگیری از تداخلات و اشتباهات، تولید اسکریپت آپدیت بانک اطلاعاتی و غیره.

یک زمانی بود دات نت ORM قابل ملاحظه‌ای نداشت. زمان دات نت2. در آن موقع NH حرف برای گفتن داشت اما ... نه الان.
‫۱۱ سال و ۱۱ ماه قبل، یکشنبه ۱۲ آذر ۱۳۹۱، ساعت ۱۷:۰۷