نظرات مطالب
ASP.NET MVC #11
- صفحه تعویض پسورد کاربر، چک باکس IsAdmin را ندارد. اما چون Model کامل کاربر در پشت صحنه آپدیت می‌شود، اگر با جعل صفحه یا درخواست ارسالی به سرور، اطلاعات IsAdmin هم ارسال شود، آنگاه Model binder که با model کامل User کار می‌کند، اطلاعات IsAdmin اضافی را هم دریافت کرده و پردازش می‌کند. بنابراین به نحوی باید سطح کلی در معرض عموم قرارگیری model را کاهش داد که روش‌های آن هم ذکر شد.
- در مورد نحوه انجام این حمله توضیحی نخواهم داد... فقط بدونید که سایت github چند وقت قبل بر همین اساس هک شد و سر و صدای زیادی هم به پا کرد: (^)
مطالب
اصلاح شیوه نامگذاری در ReSharper

یکی از روش‌های متداول نام گذاری متدها در سی شارپ به این صورت است که متدهای خصوصی با حروف کوچک شروع شوند یا lower camel case و متدهای عمومی با حرف بزرگ.
ReSharper 4.5 که جزو ابزارهای واجب کاری است، گزینه Naming style را نیز اضافه کرده و اگر شما از اصول نامگذاری متدها، کلاس‌ها ، متغیرها و غیره پیروی نکنید، علایم راهنمایی را به شما ارائه خواهد کرد. در این نگارش تمامی متدها به یک صورت در نظر گرفته می‌شوند: Upper camel case .



برای اصلاح آن می‌توان به برگه گزینه‌های آن مراجعه کرده و در قسمت naming style بر روی دکمه add مربوط به user defined naming rules کلیک و تغییر زیر را اعمال نمود:



پس از اعمال آن اگر یک متد خصوصی را با حرف بزرگ شروع کنید، تصویر زیر نمایش داده خواهد شد:





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

روش‌های مختلفی برای انجام این عملیات وجود دارد بعضی‌ها یک جدول جداگانه با عنوان نگهدارنده تاریخ در نظر می‌گیرند و بعضی‌ها نیز این اطلاعات را در همان جدول اصلی ذخیره کرده و فیلدهای به جدول اضافه می‌کنند که مشخص می‌کند این اطلاعات در چه زمانهایی صحیح است.
اگر امکان دارد مقاله ای در این خصوص تهیه شود تا کاربران نظرات و پیشنهادات و یا تجربیات خود را در این ضمینه ارائه نماییند.
با تشکر
پاسخ به پرسش‌ها
ساخت یک دیتابیس ترکیبی از SQL و فایل های XML
  • آیا سرعت ثبت و به‌روز رسانی اطلاعات، در حالت متداول کار با بانک‌های اطلاعاتی رابطه‌ای بیشتر است از کار با فیلدهای XML؟ بله. چون حداقل یک قسمت serialize و deserialize فیلدهای XML ای را به همراه ندارند؛ به همراه امکان ایندکس‌گذاری، کوئری‌های سریع و تمام مزایای دیگر به همراه این نوع بانک‌های اطلاعاتی که تمام آن‌ها در مورد فیلدهای NoSQL آن‌ها صادق نیست.
  • آیا حجم بانک اطلاعاتی که به صورت متداولی، رابطه‌ای است، کمتر است از نمونه‌ی مشابه NoSQL آن؟ بله. هدف ابتدایی طراحی این نوع بانک‌های اطلاعاتی رابطه‌ای دقیقا همین مورد بوده تا بتوانند اطلاعات بیشتری را در حجم کمتری ذخیره کنند و هزینه‌های به شدت بالای سخت‌افزاری آن زمان را کاهش دهند.
  • برای سیستم‌های بزرگ و داده‌های قابل توجه، شما به مباحثی مانند مقیاس‌پذیری و یا حتی روش‌های دیگری برای کار نیاز خواهید داشت.
نظرات نظرسنجی‌ها
از چه روشی برای مدیریت ارتباطات و هماهنگی بین Application هایتان استفاده می کنید؟
فکر می‌کنم اگر گزینه‌ی استفاده از «وب سرویس‌ها» را هم اضافه کنید بهتر باشد (این روش در دنیای دات نت حداقل مرسوم‌تر است). برای مثال اگر نیاز به اطلاعات برنامه‌ی دیگری باشد، با ایجاد یک وب سرویس (asmx، wcf یا web api و امثال آن)، سطح مناسبی را در اختیار مصرف کننده قرار می‌دهیم. همچنین این وب سرویس‌ها حالت اجرایی هم می‌توانند داشته باشند؛ مثلا فراخوانی یک متد در یک برنامه‌ی دیگر.
علاوه بر روش وب سرویس‌ها که خیلی مرسوم هست، روش دیگر اینکار در شبکه‌های داخلی سازمانی، استفاده از Linked serverهای SQL Server هستند (برای به اشتراک گذاری اطلاعات در بین برنامه‌ها). پیاده سازی Linked serverهای SQL Server هم یکی دیگر از روش‌های نوشتن برنامه‌های توزیع شده‌ی داخل سازمانی هستند.
نظرات نظرسنجی‌ها
برای قیمت گذاری پروژه های خود از کدام یک از قواعد زیر استفاده می کنید
صحبت شما صحیح است. اما تناقضی که به آن اشاره فرمودید در ذهن کسی که قصد ارائه قیمت داره پیش نمیاد. اصولاً فرد تعداد بیشتر فرم و ... را به نوعی به صورت نیاز به زمان و زحمت بیشتر در ذهن خود تفسیر می‌کند. همچنین با توجه به این که نرم افزار مانند کالاهای دیگر دارای کیفیت‌های گوناگونی می‌باشد با توجه به حضور احتمالی رقبا معمولاً گزینه سوم هم مورد بررسی قرار می‌گیرد تا مشخص شود نرم افزار با چه کیفیت و کمیتی را باید در نظر بگیرید و بر اساس زمان و سایر پارامتر‌ها در همان محدوده کیفی و کمی قیمت را تعیین کنید. پس به نوعی هر سه مورد می‌تواند موثر باشد. به شخصه اگر خود را به جای مشتری قرار بدم هیچ یک از این روش‌های تعیین قیمت را دقیق و صحیح نمی‌دانم و اولین قدم برای کاهش مشکلاتی از این دست را تقویت تیم‌های Presentation می‌دانم.
مطالب
مفاهیم پایه سیستم های کنترل نسخه؛ قسمت دوم : SVN
در قسمت قبلی، اهمیت استفاده از سیستم‌های کنترل نسخه را بیان کردیم و مفاهیم پایه‌ای گیت را مورد بررسی قرار دادیم. در این قسمت مفاهیم پایه‌ای SVN را مورد بررسی قرار می‌دهیم.
SVN مخفف عبارت SubVersion هست و یک سیستم کنترل نسخه‌ی رایگان و متن باز است که توسط شرکت  کلاب نت حمایت می‌شود. به تعدادی از این سیستم‌ها، سیستم‌های «مدیریت پیکربندی نرم افزار»   (Software Configuration Manager (SCM هم اطلاق می‌شود.
در این سیستم فایل‌ها در یک مخزن Repository مرکزی ذخیره می‌شوند و با هر تغییری که در فایل‌ها و دایرکتوری‌ها ایجاد می‌شود، آن‌ها را ثبت می‌کند. این امکان به ما این اجازه را می‌دهد که نسخه‌ی قدیمی فایل‌ها را بازیابی کرده و تاریخچه‌ی اینکه فایل‌ها چگونه و چه موقع و توسط چه کسی تغییر کرده‌اند، به ما نشان دهد. تصویر سلسله مراتبی زیر به خوبی نحوه ارتباط کلاینت‌ها را به این مخزن نشان می‌دهد.
SVN برای مدیریت چندین نسخه از فایل ها، از مدل «کپی، ویرایش، ادغام» Copy-Modify-Merge استفاده می‌کند. در این مدل که هر کاربری در مخزن عمل خواندن را انجام می‌دهد، یک کپی جداگانه و کاملا شخصی برای او گرفته شده و سپس کپی‌های شخصی خودش را ویرایش می‌کند. بعد از اینکه ویرایش تکمیل شد، کپی شخصی خودش را با یک فایل جدید و نهایی ادغام می‌کند.
این روش به شدت از روش «قفل کردن، ویرایش، آزادسازی» »Lock-Modify-Unlock کارآمدتر است و دیگر نیازی نیست که یک کاربر در یک زمان به این ساختار دسترسی داشته باشد و آن را ویرایش کند.

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


سناریو بالا با احتساب وجود تصادم

اگر همین سناریوی بالا را فرض کنیم که تغییراتی که هری روی فایل‌ها داده است همان تغییراتی است که سالی قبلا روی مخزن اصلی روی همان فایل‌ها  اعمال کرده است، آیا در این حالت دریافت به روزرسانی‌های جدید باعث ایجاد تصادم می‌شود؟

هری درخواست ادغام آخرین تغییرات مخزن را با کپی خودش می‌کند. از آنجا که فایل A تصادم دارد یک فلگ flag از این وضعیت می‌گیرد. حال هری میتواند تفاوت‌های ایجاد شده را ببیند و بین آن‌ها یکی را انتخاب کند. در این وضعیت هری همپوشانی‌های کدها را برطرف می‌کند و شاید هم بحثی در مورد این تصادم با سالی داشته باشد تا بهترین تغییر کد انتخاب گردد و نهایتا به روشی کاملا امن و مطمئن، با مخزن اصلی ادغام می‌شود.

پی نوشت : نرم افزارها نمی‌توانند موضوع تصادم را به طور خودکار اعمال کنند. از آنجا که نیاز به تصمیم گیری و درک هوشمند دارد این کار به صورت انسانی باید بررسی گردد.

مطالب
تغییر PartCreationPolicy پیش فرض در MEF
تشریح مسئله : در MEF به صورت پیش فرض نوع نمونه ساخته شده از اشیا به صورت Singleton است. در صورتی که بخواهیم یک نمونه جدید از اشیا به ازای هر درخواست ساخته شود باید PartCreationPolicyAttribute رو به ازای هر کلاس مجددا تعریف کنیم و نوع اون رو به NonShared تغییر دهیم. در پروژه‌های بزرگ این مسئله کمی آزار دهنده است. برای تغییر رفتار Container در MEF هنگام نمونه سازی Object‌ها باید چه کار کرد؟

نکته: آشنایی با مفاهیم MEF برای درک بهتر مطالب الزامی است.

*در صورتی که با مفاهیم MEF آشنایی ندارید می‌توانید از اینجا شروع کنید.

در MEF سه نوع PartCreationPolicy وجود دارد:
#1 Shared : آبجکت مورد نظر فقط یک بار در کل طول عمر Composition Container ساخته می‌شود.(Singleton)
#2 NonShared : آبجکت مورد نظر به ازای هر درخواست دوباره نمونه سازی می‌شود.
#3 Any : از حالت پیش فرض CompositionContainar برای نمونه سازی استفاده میشود که همان مورد اول است(Shared)

در اکثر پروژه‌ها ساخت نمونه اشیا به صورت Singleton میسر نیست و باعث اشکال در پروژه می‌شود. برای حل این مشکل باید PartCreationPolicy رو برای هر شی مجزا تعریف کنیم. برای مثال
    [Export]
    [PartCreationPolicy( CreationPolicy.NonShared )] 
    internal class ShellViewModel : ViewModel<IShellView>
    {
        private readonly DelegateCommand exitCommand;


        [ImportingConstructor]
        public ShellViewModel( IShellView view )
            : base( view )
        {
            exitCommand = new DelegateCommand( Close );
        }
    }
حال فرض کنید تعداد آبجکت شما در یک پروژه بیش از چند صد تا باشد. در صورتی که یک مورد را فراموش کرده باشید  و  UnitTest قوی و مناسب در پروژه تعبیه نشده باشد قطعا در طی پروژه مشکلاتی به وجود خواهد آمد و امکان Debug سخت خواهد شد.
برای حل این مسئله بهتر است که رفتار Composition Container رو در هنگام نمونه سازی تغییر دهیم. یعنی آبجکت‌ها به صورت پیش فرض به صورت NonShared تولید شوند و در صورت نیاز به نمونه Shared این Attribute رو در کلاس مورد نظر استفاده کنیم. کافیست از کلاس Composition Container که قلب MEF محسوب می‌شود ارث برده و رفتار مورد نظر را Override کنیم. برای نمونه :
public class CustomCompositionContainer : CompositionContainer
{
    public CustomCompositionContainer(ComposablePartCatalog catalog)
        : base(catalog)
    {
    }

    protected override IEnumerable<Export> GetExportsCore(ImportDefinition definition)
    {
        definition = AdaptDefinition(definition);
        
        return base.GetExportsCore(definition);
    }

    private ImportDefinition AdaptDefinition(ImportDefinition definition)
    {
        ContractBasedImportDefinition namedDefinition = definition as ContractBasedImportDefinition;
        if (namedDefinition != null && namedDefinition.RequiredCreationPolicy == CreationPolicy.Any)
        {   
            definition = new ContractBasedImportDefinition(namedDefinition.ContractName,
                                                           namedDefinition.RequiredMetadata,
                                                           namedDefinition.Cardinality,
                                                           namedDefinition.IsRecomposable,
                                                           namedDefinition.IsPrerequisite,
                                                         CreationPolicy.NonShared);
        }

        return definition;
    }
}
مشاهده می‌کنید که متد GetExportCore در کلاس بالا Override شده است و توسط متد AdaptDefinition اگر PartCreationPolicy به صورت Any بود نمونه ساخته شده به صورت NonShared ایجاد می‌شود.
حال فقط کافیست در پروژه به جای استفاده از CompositionContainer از CustomCompositionContainer استفاده کنیم.
مطالب
WCF Method Overloading
تشریح مسئله : چگونه متد‌های سرویس WCF را Overload کنیم.

نکته : آشنایی با مفاهیم اولیه WFC برای فهم بهتر مفاهیم الزامی است.

همانطور که می‌دانیم امکان Overload کردن متد‌ها در سرویس‌های WCF وجود ندارد. یعنی نمی‌توان 2 متد با نام و پارامتر‌های متفاوت داشت. به مثال زیر دقت کنید.
ابتدا یک Contract به صورت زیر تعریف کنید
 [ServiceContract]
    public interface ISampleService
    {
        [OperationContract]
        int Sum( int number1, int number2 );

        [OperationContract]
        float Sum( float number1, float number2 );
    }
در Contract بالا دو متد با یک نام ولی آرگومان‌های متفاوت داریم. حالا یک سرویس برای این Contract می‌نویسیم.
   public class SampleService : ISampleService
    {
        public int Sum( int number1, int number2 )
        {
            return number1 + number1;
        }

        public float Sum( float number1, float number2 )
        {
            return number1 + number1;
        }
    }
اگر پروژه را کامپایل کنید پروژه بدون هیچ گونه مشکلی کامپایل خواهد شد. ولی اگر قصد استفاده از این سرویس را داشته باشیم با خطا روبرو خواهیم شد. از روش AddServiceReference استفاده کنید و سرویس مورد نظر را سمت کلاینت اضافه کنید. با خطای زیر روبرو خواهید شد.
Cannot have two operations in the same contract with the same name, 
methods Sum and Sum in type Service.ISampleService violate this rule. 
You can change the name of one of the operations by changing the method name 
or by using the Name property of OperationContractAttribute.
در این خطا به صورت کامل روش حل این مسئله گفته شده است. برای حل این مسئله باید از خاصین Name در OperationContractAttribute استفاده کرد. Contract بالا را به صورت زیر تغییر دهید.
[ServiceContract]
    public interface ISampleService
    {
        [OperationContract( Name = "SumByIntNumbers" )]
        int Sum( int number1, int number2 );

        [OperationContract( Name = "SumByFloatNumbers" )]
        float Sum( float number1, float number2 );
    }
حال اگر سرویس مورد نظر را به پروژه سمت کلاینت اضافه کنیم دو متد با نام‌های SumByIntNumbers و SumByFloatNumbers خواهیم داشت. البته اگر از روش Self Hosted استفاده کنیم دقیقا دو متد با نام Sum خواهیم داشت و Overloading را سمت سرور و کلاینت خواهیم داشت ولی در روش IIS Hosting و استفاده از AddServiceReference  از خاصیت Name برای این کار استفاده میشود.

موفق باشید.
نظرات مطالب
به دست آوردن اطلاعات کد اجراکننده یک متد
اضافه شدن ویژگی CallerArgumentExpression به C#10.0

ویژگی [CallerArgumentExpression] امکان دریافت آرگومان ارسالی به یک متد را به صورت رشته‌ای میسر می‌کند. برای مثال:
public static void LogExpression<T>(
    T value, 
    [CallerArgumentExpression("value")] string expression = null)
{
    Console.WriteLine($"{expression}: {value}");
}
با ورودی زیر:
var person = new Person("Vahid", "N.");
LogExpression(person.FirstName);
چنین خروجی را تولید می‌کند:
person.FirstName: Vahid

پارامتری که توسط ویژگی [CallerArgumentExpression] معرفی می‌شود، اختیاری بوده و به صورت خودکار توسط کامپایلر مقدار دهی می‌شود. یعنی کامپایلر فراخوانی فوق را به صورت زیر انجام می‌دهد:
LogExpression(person.FirstName, "person.FirstName");
وجود یک چنین قابلیتی، نویسندگان کتابخانه‌ها را از بکارگیری <<Expression<Func<T‌ها یا همان استاتیک ریفلکشن، رهایی می‌بخشد.

یک نمونه کاربرد دیگر آن در بررسی نال بودن مقدار پارامترهای ارسالی است که می‌توان آن‌ها را به صورت زیر خلاصه کرد:
public static void EnsureArgumentIsNotNull<T>(
   T value, 
   [CallerArgumentExpression("value")] string expression = null)
{
    if (value is null)
        throw new ArgumentNullException(expression);
}

public static void Foo(string name)
{
    EnsureArgumentIsNotNull(name); // if name is null, throws ArgumentNullException: "Value cannot be null. (Parameter 'name')"
    ...
}
پیشتر می‌بایستی با استفاده از nameof، نام پارامتر را مشخص کرد. در اینجا کامپایلر قادر است این مقدار را مشخص کند و دیگر نیازی به استفاده از روش زیر نیست:
    if (name is null)
    {
        throw new ArgumentNullException(nameof(name));
    }
البته NET 6.0. به همراه متد جدید زیر که از قابلیت فوق استفاده می‌کند، هست:
ArgumentNullException.ThrowIfNull(name);
و متد ThrowIfNull آن به صورت زیر تعریف شده‌است:
public static void ThrowIfNull(
    [NotNull] object? argument,
    [CallerArgumentExpression("argument")] string? paramName = null)

سؤال: چرا آرگومان اول این متد، هم nullable تعریف شده‌است و هم با ویژگی NotNull مزین گشته‌است؟
nullable بودن آن از این جهت است که ممکن است مقدار ارسالی به آن نال باشد. ویژگی NotNull آن به کامپایلر اعلام می‌کند که اگر این متد با موفقیت به پایان رسید، در سطرهای پس از آن، مقدار این شیء دیگر نال نیست و نیازی نیست تا به استفاده کنند اعلام کند که باید مراقب نال بودن آن باشد.