نظرات مطالب
مدیریت محل اعمال Google analytics در ASP.NET MVC
با سلام. امکان دارد در مورد نحوه استخراج اطلاعات از این سرویس و نمایش در سایت کمی راهنمایی کنید؟ باتشکر.
مطالب
ASP.NET Web API - قسمت سوم
در قسمت اول به دلایل ایجاد Web API پرداخته شد و در قسمت دوم مثالی ساده از Web API را بررسی کردیم. در این قسمت، مثال قبل را تست کرده و نحوه‌ی تعامل jQuery با آن را بررسی می‌کنیم.

فراخوانی Web API از طریق مرورگر

با فشردن کلید F5، پروژه را اجرا کنید. شکل ذیل ظاهر می‌شود.


صفحه ای که ظاهر می‌شود، یک View است که توسط HomeController و متد Index آن برگشت داده شده است. برای فراخوانی متدهای موجود در کلاس Controller مثال قسمت قبل که مربوط به Web API است، باید به یکی از آدرس‌های اشاره شده در قسمت قبل برویم. به عنوان مثال، برای به دست آوردن لیست تمامی محصولات، به آدرس http://localhost:xxxx/api/products بروید. xxxx، شماره‌ی پورتی است که Web Server داخلی Visual Studio در هنگام اجرای پروژه به آن اختصاص می‌دهد. آن را نسبت به پروژه‌ی خود تغییر دهید.
نتیجه‌ی دریافتی بستگی به نوع مرورگری دارد که استفاده می‌کنید. Internet Explorer از شما در مورد باز کردن یا ذخیره‌ی فایلی با نام products پرسش می‌کند (شکل ذیل).


محتوای فایل، بدنه‌ی پاسخ دریافتی است. اگر این فایل را باز کنید، خواهید دید که که محتوای آن، لیستی از محصولات با فرمت JSON مانند ذیل است.

[{"Id":1,"Name":"Tomato soup","Category":"Groceries","Price":1.39},{"Id":2,"Name":
"Yo-yo","Category":"Toys","Price":3.75},{"Id":3,"Name":"Hammer","Category":
"Hardware","Price":16.99}]
اما مرورگر Firefox، محصولات را در قالب XML نشان می‌دهد (شکل ذیل).


دلیل تفاوت در نتیجه‌ی دریافتی این است که مرورگر Internet Explorer و Firefox، هر یک مقدار متفاوتی را در هدر Accept درخواست، ارسال می‌کنند. بنابراین، Web API نیز مقدار متفاوتی را در پاسخ برگشت می‌دهد.

حال به آدرس‌های ذیل بروید: 

http://localhost:xxxx/api/products/1
http://localhost:xxxx/api/products?category=hardware

اولین آدرس، باید محصولی با مشخصه‌ی 1 را برگشت دهد و دومین آدرس، لیستی از تمامی محصولاتی که در دسته‌ی hardware قرار دارند را برگشت می‌دهد (در مثال ما فقط یک آیتم این شرط را دارد).

نکته: در صورتی که در هنگام فراخوانی هر یک از متدهای Web API با خطای ذیل مواجه شدید، دستور [("AcceptVerbs("GET", "POST] را به ابتدای متدها اضافه کنید.

The requested resource does not support http method 'GET'
 

فراخوانی Web API با استفاده از کتابخانه‌ی jQuery

در قسمت قبل، متدهای Web API را مستقیماً از طریق وارد کردن آدرس آنها در نوار آدرس مرورگر فراخوانی کردیم. اما در اکثر اوقات، این متدها با روش‌های برنامه نویسی توسط یک Client فراخوانی می‌شوند. اجازه بدهید Clientیی ایجاد کنیم که با استفاده از jQuery، متدهای ما را فراخوانی می‌کند.
در Solution Explorer، از پوشه‌ی Views و سپس Home، فایل Index.cshtml را باز کنید.

تمامی محتویات این View را حذف و کدهای ذیل را در آن قرار دهید.  

<!DOCTYPE html>
<html>
<head>
    <title>ASP.NET Web API</title>
    <script src="../../Scripts/jquery-1.7.2.min.js" 
        type="text/javascript"></script>
</head>
<body>
    <div>
        <h1>All Products</h1>
        <ul id='products' />
    </div>
    <div>
        <label for="prodId">ID:</label>
        <input type="text" id="prodId" size="5"/>
        <input type="button" value="Search" onclick="find();" />
        <p id="product" />
    </div>
</body>
</html>


بازیابی لیستی از محصولات

برای بازیابی لیستی از محصولات، فقط کافی است تا یک درخواست از نوع GET به آدرس "/api/products" بفرستید. این کار با jQuery به صورت ذیل انجام می‌شود. 

<script type="text/javascript">
    $(document).ready(function () {
        // Send an AJAX request
        $.getJSON("api/products/",
        function (data) {
            // On success, 'data' contains a list of products.
            $.each(data, function (key, val) {

                // Format the text to display.
                var str = val.Name + ': $' + val.Price;

                // Add a list item for the product.
                $('<li/>', { html: str })    
                .appendTo($('#products'));   
            });
        });
    });
</script>

متد getJSON، یک درخواست AJAX از نوع GET را ارسال می‌کند و پاسخ دریافتی آن نیز با فرمت JSON خواهد بود. دومین پارامتر متد getJSON، یک callback است که پس از دریافت موفقیت آمیز پاسخ اجرا می‌شود.


بازیابی یک محصول با استفاده از مشخصه‌ی آن

برای بازیابی یک محصول با استفاده از مشخصه‌ی آن، یک درخواست از نوع GET به آدرس "api/products/id/" ارسال کنید. id، مشخصه‌ی محصول است. کد ذیل را در ادامه‌ی کد قبل و پیش از تگ <script/> قرار دهید.

function find() {
    var id = $('#prodId').val();
    $.getJSON("api/products/" + id,
        function (data) {
            var str = data.Name + ': $' + data.Price;
            $('#product').html(str);
        })
    .fail(
        function (jqXHR, textStatus, err) {
            $('#product').html('Error: ' + err); 
        });
}


باز هم از متد getJSON استفاده کردیم، اما این بار مقدار id برای آدرس از یک Text Box خوانده و آدرس ایجاد می‌شود. پاسخ دریافتی، یک محصول در قالب JSON است.


اجرای پروژه

پروژه را با فشردن کلید F5 اجرا کنید. پس از نمایش فرم، تمامی محصولات بر روی صفحه نمایش داده می‌شوند. عدد 1 را وارد و بر روی دکمه‌ی Search کلیک کنید، محصولی که مشخصه‌ی آن 1 است نمایش داده می‌شود (شکل ذیل).

اگر مشخصه ای را وارد کنید که وجود ندارد، خطای 404 با مضمون "Error: Not Found" بر روی صفحه نمایش داده می‌شود و در صورتی که به جای عدد، عبارتی غیر عددی وارد کنید، خطای 400 با مضمون: "Error: Bad Request" نمایش داده می‌شود. در Web API، تمامی پاسخ‌ها باید در قالب کدهای وضعیت HTTP باشند (شکل ذیل). این یکی از اصول اساسی کار با وب سرویس‌ها است. وفادار ماندن به مفاهیم پایه‌ی وب، دید بهتری در مورد اتفاقاتی که می‌افتد به شما می‌دهد. 

در قسمت بعد با مفهوم مسیریابی در ASP.NET Web API آشنا می‌شوید.

نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت پنجم - سیاست‌های دسترسی پویا
- آیا در داده‌های شما مشخص است هر رکورد توسط چه شخصی قابل مشاهده است (مثلا به ازای هر رکوردی که ثبت شده، یک فیلد سطوح دسترسی هم هست؛ با رابطه‌ی یک به چند البته)؟ چون عموما کسی چنین کاری را انجام نمی‌دهد (به علت پیچیدگی بیش از حد، نیاز به ثبت اطلاعات بیشتر برای کاربر و اپراتور(؟) و چند سطحی شدن و نیاز به join اضافی و ... آیا باید به اپراتوری که داده‌ها را ثبت می‌کند در این حالت اطمینان کرد که خودش را داخل لیست قرار ندهد؟). روش متداول این است که اگر شخصی به صفحه‌ای دسترسی داشت، یعنی به تمام اجزا و اطلاعات آن دسترسی دارد. یکسری از گزارش‌ها مدیریتی هستند و یکسری عمومی. اگر گزارشی مدیریتی است، نصف آن برای کاربر معمولی نمایش داده نمی‌شود. کل آن برای کاربر معمولی قابل دسترسی نیست. 
- گیرم چنین فیلد اضافی را هم به هر رکورد اضافه و ثبت کردید، روش اعمال خودکار آن همانند بحث‌های soft delete است که در EF Core به صورت توکار پشتیبانی می‌شود.
- همچنین در مورد دیدن یا ندیدن قسمت‌هایی از صفحه که شخص بر اساس نقش‌های او نباید آن‌ها را مشاهده کند، یک tag helper ویژه به نام «SecurityTrimmingTagHelper» طراحی شده‌است که توضیحات آن در متن جاری هست.
مطالب
معماری اطلاعات (Information Architecture)

معماری اطلاعات یا Information Architecture و یا به اختصار IA در یک تیم توسعه نرم‌افزار، یک وظیفه پایه و اساسی است که معمولا بین طراحان، توسعه دهندگان و یا طراحان استراتژی محتوا تقسیم می‌گردد. اما صرف نظر از اینکه چه کسی در یک تیم آن را بر عهده می‌گیرد، IA تخصص خاص خود را نیازمند است که این تخصص که شامل ابزارها و شاخص‌ها و منابعی است که باید به درستی تحقیق و گردآوری گردند. در این مقاله قصد داریم تا به این امر بپردازیم که واقعا IA چیست؟ و چرا یک جنبه‌ی مهم و ارزشمند در طراحی فرآیندهای user experience به شمار می‌رود؟


Information Architecture چیست؟

بیان کردن یک تعریف دقیق برای IA کمی پیچیده‌تر از تعاریف دیگری همچون content strategy و یا interaction design به نظر می‌رسد. بر خلاف content strategy که به وسیله طراحان استراتژی محتوا و یا interaction design که توسط طراحان UI/UX انجام می‌گیرد، IA به ندرت در زمره‌ی یک کار جداگانه قرار می‌گیرد. اما با این وجود، این کار در مهندسی نرم افزار بسیار با ارزش و لازم محسوب می‌گردد. (منبع)

بر اساس تعریف ویکی‌پدیا، IA اینگونه تعریف می‌گردد: "معماری اطلاعات عبارت است از طراحی ساختاری سامانه‌های اشتراک اطلاعات، که با هدف یافت پذیری و کاربرد پذیری انجام می‌شود."

در فرهنگ معماری اطلاعات، مفهوم یافت‌پذیری یا Findability به زبان ساده، شاخصی است که قابلیت یافت شدن و مکان‌یابی یک مجموعه اطلاعات را محک می‌زند. به عنوان مثال سامانه‌های اطلاع‌رسانی مانند وب سایت‌ها باید به گونه‌ای طراحی شوند که مردم در هر سطحی، به سادگی بتوانند اطلاعات مورد نظر خود را پیدا کنند.

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

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

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

بر اساس آنچه که در وب‌سایت UXmatters و webmonkey گفته شده است، IA در شش مرحله صورت می‌گیرد:

1. ارزیابی هدف کسب و کار ( Assess business intent )

2. ارزیابی هدف کاربران ( Assess user intent )

3. ارزیابی محتوا ( Assess content )

4. مدیریت محتوا ( Organize content )

5. برقرارسازی ارتباط میان اطلاعات ( Enable information relationships )

6. فراهم‌سازی فرآیند هدایت محتوا ( Provide navigation )

تصویر زیر که برگرفته از وب‌سایت SitePoint می‌باشد برخی از مراحل فوق را به صورت مختصر و ساده نمایش داده است.

اگر به وب‌سایت رسمی انجمن معماری اطلاعات سری بزنید مطالب مفیدی در زمینه‌ی پیاده سازی IA به دست خواهید آورد.

تصویر زیر ارتباط تنگاتنگ سه مبحث Information Design ، Interaction Design و Sensorial Design را نمایش می‌دهد. همانطور که می‌بینید، محتوا در مرکزیت هر سه موضوع قرار دارد. بنابراین می‌توان اینگونه استنباط کرد که محتوا اصلی‌ترین بخش یک کسب‌وکار نرم‌افزاری را تشکیل می‌دهد. اما در بخش پیشین دیدیم که محتوا به تنهایی نمی‌تواند راهگشای نتیجه‌ی عالی از یک نرم‌افزار باشد. با توجه به دو مفهوم یافت‌پذیری و کاربرد‌پذیری دیدیم برای آنکه بتوانیم در تولید نرم‌افزار بهترین باشیم، بایستی در قدم اول مفهوم یافت‌پذیری را رعایت نماییم. به زبان ساده باید هر چیزی را در جای مورد نظر خود قرار دهیم تا کاربر در مدت زمان خیلی کمی بتواند به آن دسترسی داشته باشد.

همانطور که در تصویر فوق ملاحظه میکنید دو اصطلاح شاید نا آشنای دیگر نیز آورده شده است، Interaction Design و Sensorial Design. در مقاله‌ای دیگر به آنها خواهیم پرداخت.

مطالب
سیستم‌های توزیع شده در NET. - بخش سوم- مهمترین فاکتورها در انتخاب سیستمهای توزیع شده
همیشه نیازمندی‌های ما باعث انتخاب نوع طراحی و پیاده سازی ما می‌شوند و لزوما چیزی که برای ما جذابتر و پیچیده‌تر است، باعث موفقیت سیستمی که طراحی می‌کنیم نمی‌شود. چه بسا که یک انتخاب نادرست و نادیده گرفتن یک یا چند نیازمندی، باعث شود هیچ یک از مواردی که شما برای انتخاب آن نوع طراحی در نظر گرفته بودید، محقق نشوند. هدف من از ارائه این بخش، معرفی مهمترین فاکتورهایی است که شما می‌توانید با استفاده از آنها تصمیم بگیرید که آیا باید سیستم خود را بصورت توزیع شده پیاده سازی کنید یا خیر و شاید بهترین راه برای بدست آوردن درک بهتری از این فاکتور‌ها، ارائه مثالی واقعی از یک سیستم توزیع شده باشد.

یکی از تجربیاتی که من در زمینه طراحی و پیاده سازی سیستم‌های توزیع شده داشته‌ام «سیستم آمارنامه فرآورده‌های دارویی کشور» است. هدف این سیستم، تامین کردن آماری از زنجیره تامین فرآورده‌های دارویی کشور است و در آن همه چیز در قالب رخدادهایی که در این زنجیره اتفاق می‌افتند، بوجود می‌آید. یعنی ما باید تمام رخداد‌ها را  از لحظه‌ای که یک تولید کننده یا وارد کننده، فرآورده را وارد این زنجیره می‌کند، تا لحظه‌ای که فرآورده توسط داروخانه به مشتری تحویل داده می‌شود و از زنجیره خارج می‌شود، ثبت کنیم و در مرحله بعد گزارشات کاملی را از اطلاعات ثبت شده، در اختیار تمام تولید کنندگان، وارد کنندگان، توزیع کنندگان و شعب آنها، داروخانه‌ها، یکسری از ارگانهای دولتی، دانشگاه‌ها و عموم جامعه قرار بدهیم.


نمایی از زنجیره تامین فرآورده‌های دارویی و نحوه فراخوانی سرویس آمارنامه



در این سیستم چالش‌های بسیار مهمی وجود دارند که پس از بررسی‌های انجام شده، برای هر یک راه حلی ارائه خواهد شد:

چالش اول: در دسترس بودن سیستم

در دسترس بودن این سرویس بسیار حیاتی است. یعنی با از دسترس خارج شدن این سرویس، قسمتی از داده‌های اصلی خود را از دست می‌دهیم؛ که باعث می‌شود آمار ارائه شده درست نباشد.

ارائه راه حل:

بدلیل اینکه احتمال از دسترس خارج شدن یک سرور همیشه وجود دارد، این چالش به تنهایی می‌تواند دلیل محکمی برای پیاده سازی سیستم بصورت توزیع شده باشد. برای حل این مشکل می‌توانیم از روش Active/Standby استفاده کنیم. به این صورت که چند کپی از سرویس روی چند سرور داشته باشیم که هر لحظه یکی از این سرور‌ها فعال باشد. با از دسترس خارج شدن سرور Active، یکی از سرور‌های Standby فعال شود و درخواست‌های جدید برای این سرور ارسال شوند.


این روش تنها قابلیت در دسترس بودن سیستم را افزایش می‌دهد و هیچ تاثیری روی کارآیی سیستم ندارد.

 برای رفع مشکل فوق، از روش Replicate روی یک یا چند Cluster استفاده می‌کنیم. یعنی چند کپی از سرویس، روی چند سرور داشته باشیم؛ به این صورت که همه آنها فعال باشند. درخواست‌ها با الگوریتمی که انتخاب می‌کنیم، از طریق Load Balancer بین این Node‌ها پخش می‌شوند. با این روش، هم کارآیی سیستم بالا می‌رود و هم همیشه Nodeهایی وجود دارند که جای Node‌های از دسترس خارج شده را بگیرند.


این روش کارآیی سیستم را افزایش چشمگیری می‌دهد. اما بدلیل اینکه یک Load Balancer داریم، در صورتیکه به هر دلیلی Load balancer از دسترس خارج شود، کل سیستم از دسترس خارج می‌شود.
برای رفع مشکل فوق بصورت ترکیبی، از هر دو روش در قسمتهای مختلف استفاده می‌کنیم که در این روش احتمال از دسترس خارج شدن سیستم به حداقل ممکن می‌رسد و کارآیی سیستم نیز به حداکثر ممکن می‌رسد.



(در هر صورت بهترین راه حل برای این چالش، استفاده از سیستم‌های توزیع شده است.)


چالش دوم: تعداد کاربران و تعداد درخواست بسیار زیاد و همیشه رو به افزایشند

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

به نسبت تعدادکاربران و رو به افزایش بودن آنها، درخواست از این سیستم، هیچگاه قطع نمی‌شود و همیشه رو به افزایش است. با رخ دادن هر Event، یک درخواست برای سیستم ارسال می‌شود. بطور مثال تنها در آخرین مرحله به ازای هر رخداد داروخانه، درخواستی برای سیستم ارسال می‌شود (تنها یکی از رخدادهای داروخانه، رخداد فروش است که با ارائه هر نسخه توسط مشتری اتفاق می‌افتد). با توجه به اینکه در کشور چیزی در حدود 12000 داروخانه وجود دارند، سیستم باید توانایی پاسخ دادن به 12000 درخواست بصورت همزمان و متناوب، آن هم فقط برای رخداد فروش داروخانه‌ها را داشته باشد.

ارائه راه حل:

بدلیل تعداد بسیار زیاد درخواست‌ها و بالا رفتن این تعداد، بصورت لحظه‌ای و حیاتی بودن دسترسی به این سیستم، سیستم باید قابلیت این را داشته باشد که بدون از دسترس خارج شدن، اولا درخواست‌های جاری را پاسخ دهد، دوما همیشه آمادگی لازم را برای افزایش تعداد درخواست‌ها، داشته باشد. یعنی به هیچ وجه Scale-up به‌تنهایی پاسخگوی نیاز ما نیست و برای رفع این مشکل باید از Scale-out کمک بگیریم. یعنی با افزایش تعداد درخواست‌ها، بدون از دسترس خارج شدن سیستم و با کمترین هزینه و پیچیدگی، Node‌هایی به سیستم اضافه کنیم که قسمتی از بار پردازشی در آنها انجام شود.


در این روش ما می‌توانیم به راحتی و با کمترین هزینه، با افزایش تعداد درخواست، Nodeهایی را به Cluster اضافه کنیم تا بار پردازشی اضافی در آنها رفع شود. همچنین برای استفاده بهینه از منابع، با کاهش درخواست، Nodeهایی را از Cluster خارج کنیم. همچنین قابلیت در دسترس بودن این سیستم نیز در بالاترین سطح خود قرار دارد.


چالش سوم: حجم زیاد هر درخواست و زمان زیاد مورد نیاز برای پردازش آن 

روال پاسخ دادن به هر درخواست، شامل دریافت درخواست، گرفتن Log از درخواست، اعمال دسترسی‌های ارسال کننده درخواست، اعتبارسنجی درخواست، پردازش درخواست، ذخیره آن و پاسخ به کاربر  است و بدلیل اینکه هر رخداد می‌تواند شامل اطلاعات بسیار زیادی باشد، انجام همه این اعمال، زمان زیادی را می‌طلبد. همچنین با توجه به تعداد کاربران، تعداد درخواست و حجم داده‌ای که باید ذخیره کنیم - در صورتی که هر درخواست نیز بخواهد در مدت زمان زیادی پردازش شود - سیستم با حجم بسیار زیادی از درخواست مواجه است که هر یک زمانی زیادی را نیز برای پردازش نیاز دارد.

ارائه راه حل: 

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


با تقسیم بندی وظایف و قرار دادن هریک از این وظایف در سخت افزارهای متفاوت، سیستم این قابلیت را دارد که برای کاربر همیشه در دسترس باشد. در کمترین زمان بیشترین تعداد درخواست را بصورت همزمان و با کمترین تاخیر پردازش کند و با افزایش درخواست‌ها، برای هر قسمت می‌توانیم تعداد Node موجود در آن قسمت را افزایش دهیم.


چالش چهارم: حجم بسیار زیاد و رو به افزایش داده‌های سیستم

داده‌های این سیستم ذاتا همیشه و در هر شرایطی رو به افزایش هستند و هیچگاه جریان داده، در این سیستم قطع نمی‌شود. با توجه به تعداد کاربران، تعداد درخواست و نوع داده، ما با حجم داده‌ی بسیار زیادی روبرو هستیم که پایانی ندارند.

ارائه راه حل:

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

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

نتیجه گیری این است که تقریبا تمام چالش‌هایی که برای سرویس وجود داشت، برای Database نیز وجود دارد. به همین دلیل باید Database نیز بصورت توزیع شده پیاده سازی شود:



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

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


مهمترین فاکتورهای انتخاب سیستمهای توزیع شده:

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

2- در دسترس بودن سیستم: گاهی ممکن است یک لحظه از دسترس خارج شدن سیستم، عواقب جبران ناپذیری را برای کل سیستم به‌وجود بیاورد. در این حالت بهترین انتخاب، سیستم‌های توزیع شده است.

3- تعداد یا نوع کاربران سیستم: تعداد کاربرانی که همیشه رو به افزایشند، می‌تواند فاکتور بسیار مهمی در انتخاب یک سیستم توزیع شده باشد. اما مشکلی که وجود دارد این است که همیشه در ابتدای طراحی این تعداد مشخص نیست. گاهی نیاز است نوع طراحی خود را با توجه به نوع کاربران سیستم انتخاب کنید. بطور مثال سیستم شما نیازهای کاربران یک مکان یا سازمان خاص را رفع می‌کند، یا نیازهای یک جامعه را رفع می‌کند. در صورتیکه سیستم شما نیاز کاربران یک محیط بزرگ را رفع کند، همیشه باید منتظر بالا رفتن میزان کاربران سیستم نیز باشید.

4- تعداد درخواست‌های از سیستم: تعداد درخواست‌ها در اکثر موارد وابستگی بسیار زیادی به تعداد یا نوع کاربران دارد. پوشش دادن تعداد زیاد درخواست، بصورت متناوب و رو به افزایش می‌تواند فاکتور بسیار مهمی در انتخاب یک سیستم توزیع شده باشد.

5- نوع و حجم عملیاتی که انجام می‌دهیم: برخی عملیات ممکن است زمان بسیار زیادی برای اجرا نیاز داشته باشند که می‌تواند روی سیستم ما تاثیر بسیار زیادی بگذارند. برای افزایش کارآیی و پردازش تعداد بیشتر درخواست‌ها، گاهی بهتر است یک عملیات را تبدیل به عملیاتی کوچکتر کرد و هرکدام از این عملیات کوچکتر را در یک سخت افزار جداگانه اجرا کرد.

6- نوع و حجم داده‌هایی که نیاز به ذخیره شدن دارند: نوع داده‌هایی که ذاتا همیشه رو به افزایشند می‌تواند فاکتور بسیار مهمی در انتخاب سیستم‌های توزیع شده باشد. البته این مورد نیز همیشه از ابتدای طراحی مشخص نیست. نوع کاربران شما می‌توانند کمک بسیار بزرگی در انتخاب این فاکتور داشته باشند.

7- کارآیی: با یک طراحی و تقسیم بندی درست در قسمتهای مختلف سیستم می‌توان حجم و تعداد بسیار زیادی از پردازش‌ها را بصورت همزمان اجرا کرد. البته کاملا بصورت انعطاف پذیر؛ به صورتیکه با بیشتر شدن تعداد و حجم پردازش، سیستم بدون از دسترس خارج شدن، قادر به پوشش دادن آنها باشد.

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

9- موقعیت جغرافیایی کاربران: گاهی بدلیل تعداد زیاد کاربران نیاز است درخواست‌های هر کاربر، در نزدیکترین سرور به او پردازش شود. این فاکتور در سیستم‌های بسیار بزرگ دلیل بسیار مهمی در انتخاب سیستمهای توزیع شده‌است.

علاوه بر موارد فوق مواردی را مانند Internet of things یا همان IOT  که پایه و اساس آن سیستم‌های توزیع شده‌است، یا مواردی را مانند Machine learning که می‌تواند بصورت توزیع شده پیاده سازی شود، نیز در نظر بگیرید.

با در نظر گرفتن تمام موارد فوق و شرایط اختصاصی سیستمی که طراحی می‌کنید، سعی کنید بهترین انتخاب را انجام دهید.
مطالب
بررسی اینترفیس ICommand در WPF
مدتی هست که مشغول مطالعه و یادگیری WPF از طریق مطالب سایت هستم؛ به همین خاطر تصمیم گرفتم مطلبی را حول محور اینترفیس ICommnad  گردآوری کنم و در اختیار کاربران سایت قرار دهم.

سرفصل‌های این مطلب :
• Command چیست
• اینترفیس ICommand چیست 
• چرا اینترفیس ICommand
• ایجاد UI مورد نیاز 
• چگونگی استفاده از ICommand 
• استفاده از INotifyPropertyChanged

Command چیست ؟
در برنامه نویسی WPF به هر کلاسی که اینترفیس ICommand را پیاده سازی کند، اصطلاحا Commnad گوییم. تفاوت کوچکی بین یک Event و Command وجود دارد. رخداد‌ها برای کنترل‌های UI ساخته و تخصیص داده می‌شوند؛ اما Command‌ها انتزاعی‌تر هستند و تمرکز آنها بر روی نحوه‌ی انجام کارها می‌باشد.
برای تعاملات در برنامه‌ها از Commandها و Event‌ها استفاده می‌کنیم. ما در WPF دو روش برای تعامل با UI داریم:
1- استفاده از Event‌ها و نوشتن کد‌های مورد نیاز در بخش CodeBehind (رعایت نکردن الگوی MVVM).
WPF تعداد زیادی RoutedEvent پیش ساخته (Built In) دارد که از آنها می‌توان در این روش استفاده کرد. 
2- استفاده از Command و درگیر کردن کدهای اجرایی نوشته شده در ViewModel با استفاده از Command ها.
در زمان استفاده از الگوی MVVM مجاز به نوشتن کد در بخش CodeBehind نیستیم. بنابراین از سیستم رخداد‌های طراحی شده‌ی در WPF که RoutedEvent می‌باشد، نمی‌توان استفاده کرد. به این خاطر که رخداد‌ها در ViewModel قابل دسترسی نمی‌باشد.

اینترفیس ICommand:
این اینترفیس سه عضو دارد که آن‌ها را در جدول زیر مشاهده می‌کنید:

نام عضو

توضیحات

Bool CanExecute(object parameter)

این تابع پارامتری از نوع object را دریافت می‌کند و یک مقدار bool را به خروجی تابع می‌فرستد. اگر مقدار خروجی متد، true  باشدcommand  اجرا خواهد شد و در غیر اینصورت اتفاقی رخ نخواهد داد. اغلب ازDelegate  ها به عنوان پارامتر این تابع استفاده می‌شود؛Delegate های پیش ساخته‌ای همچون Action,Predicate,Func

Event EventHandler CanExecuteChanged

این رویداد برای آگاه سازی UI که به Command متصل است، استفاده می‌شود .بر اساس خروجی تابع CanExecute، این رویداد اتفاق می‌افتد.

Void Execute(Object parameter)

این متد کار اصلی را در Command‌ها انجام می‌دهد. این متد تنها زمانی اجرا می‌شود که متدCanExecute  مقدار true را بازگرداند. این تابع پارامتری را از نوع object دریافت می‌کند، اما عموما ما یکDelegate  را به آن ارسال می‌کنیم. Delegate ارجاعی را به متدی، در خود نگاه می‌دارد که انتظار داریم در صورت اجرایcommand ، اجرا شود.


چرا اینترفیس ICommand :
هسته‌ی اصلی Command‌ها در WPF، اینترفیس ICommand می‌باشد. این اینترفیس به‌صورت گسترده‌ای در الگوی MVVM و Prism  استفاده شده است و استفاده‌ی از آن محدود به MVVM نمی‌باشد. تعداد زیادی Commnad بصورت پیش ساخته وجود دارند که این اینترفیس را پیاده سازی کرده‌اند .کلاس پایه RoutedCommand اینترفیس ICommand را پیاده سازی کرده است و WPF فرمان‌های زیر را فراهم کرده است:
• MediaCommnads
• ApplicationCommnads
• NavigationCommands
• ComponentCommnads
• EditingCommnads
که همگی از کلاس RoutedCommand استفاده کرده‌اند.
در این مطلب به دنبال ایجاد برنامه‌ای هستیم که حاصل جمع مفدار دو Textbox را پس از فشردن کلید جمع در یک textblock نمایش دهد.

ساخت UI مورد نیاز :
گام اول : 
با اجرای ویژوال استودیو، برنامه‌ای را با نام ICommnadSample ایجاد کنید. ساختار پروژه به شکل زیر است:
همانطور که می‌بینید View و ViewModel و در نهایت Command‌ها در پوشه‌های مجزایی ساماندهی شده‌اند.

گام دوم:
ابتدا قالب گرافیکی را مشخص می‌کنیم. در پوشه‌ی Views یک UserControl را به نام CalculatorView.xaml ایجاد کرده و کد زیر را در آن نوشتیم:
<Grid DataContext="{Binding Source={StaticResource calculatorVM}}" Background="#FFCCCC">
        <Grid.RowDefinitions>
            <RowDefinition Height="80"/>
            <RowDefinition/>
            <RowDefinition Height="80"/>
            <RowDefinition Height="44"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
            <ColumnDefinition/>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>

        <Label Grid.Row="0" Grid.Column="0" Grid.ColumnSpan="4" FontSize="25"
               VerticalAlignment="Top" HorizontalAlignment="Center" Foreground="Blue" Content="ICommand Sample"/>
        <Label Grid.Row="0" Grid.Column="0" Grid.ColumnSpan="2" 
               Margin="10,0,0,0" VerticalAlignment="Bottom" FontSize="20"  Content="First Input"/>
        <Label Grid.Row="0" Grid.Column="2" Grid.ColumnSpan="2" 
               Margin="10,0,0,0" VerticalAlignment="Bottom" FontSize="20"  Content="Second Input"/>

        <TextBox Grid.Row="1" Grid.Column="0" Grid.ColumnSpan="2" Margin="10,0,0,0" FontSize="20" 
                 HorizontalAlignment="Left" Height="30"  Width="150" TextAlignment="Center" Text="{Binding FirstValue, Mode=TwoWay}"/>
        <TextBox Grid.Row="1" Grid.Column="2" Grid.ColumnSpan="2" Margin="10,0,0,0" FontSize="20"
                 HorizontalAlignment="Left"  Height="30" Width="150" TextAlignment="Center" Text="{Binding SecondValue, Mode=TwoWay}"/>

        <Rectangle Grid.Row="2" Grid.Column="0" Grid.ColumnSpan="4" Fill="LightBlue"/>
        <Button Grid.Row="2" Grid.Column="0" Content="+"  Margin="10,0,0,0" HorizontalAlignment="Left" Height="50" Width="50" FontSize="30" Command="{Binding AddCommand}"/>
        
        <Label Grid.Row="3" Grid.Column="0" Grid.ColumnSpan="2" FontSize="25" Margin="10,0,0,0" HorizontalAlignment="Left" Height="50"  Content="Result : "/>
        <TextBlock Grid.Row="3" Grid.Column="2" Grid.ColumnSpan="2" FontSize="20" Margin="10,0,0,0" Background="BlanchedAlmond"
                   TextAlignment="Center"  HorizontalAlignment="Left" Height="36" Width="150" Text="{Binding Output}"/>
    </Grid>
برای استفاده از این UserControl در پنجره‌ی اصلی برنامه (فایل MainWindows.Xaml) به شکل زیر عمل می‌کنیم:
ابتدا فضای نام View را به فایل MainWindows.xaml اضافه می‌کنیم :
   xmlns:myview="clr-namespace:ICommnadSample.Views"
ایجاد تگ برای استفاده از View تولید شده در  Grid اصلی برنامه :
<Grid>
        <myview:CalculatorView/>
</Grid>

گام سوم :
همانطور که مشاهده می‌کنید، کنترل‌هایی که در عملیات انقیاد داده‌ها (DataBinding) شرکت می‌کنند، از طریق خاصیت Binding و معرفی خصوصیت مورد نظر مشخص می‌شوند.
برای این منظور در پوشه‌ی ViewModels و به کلاس CalculatorViewModel سه خصوصیت به‌همراه فیلد خصوصی، به شکل زیر اضافه می‌کنیم:
private double firstValue; 
private double secondValue;
private double output;
public double FirstValue
        {
            get { return firstValue; }
            set
            {
                firstValue = value;
                OnPropertyChanged("FirstValue");
            }
        }
        public double SecondValue
        {
            get { return secondValue; }
            set
            {
                secondValue = value;
                OnPropertyChanged("SecondValue");
            }
        }
        public double Output
        {
            get { return output; }
            set
            {
                output = value;
                OnPropertyChanged("Output");
            }
        }

چگونگی استفاده‌ی از اینترفیس ICommand :
برای ایجاد ارتباط بین Command ‌ها و UI می‌بایست اینترفیس ICommand توسط کلاس مورد نظر ما پیاده سازی شود. در ابتدا کلاسی با عنوان PlusCommnad  ایجاد و از اینترفیس مورد نظر ارث بری می‌کنیم.
هدف ما شبیه سازی رویداد کلیک دکمه‌ی موجود در صفحه با استفاده از Command می‌باشد.

گام چهارم:
پس از پیاده سازی اینترفیس لازم است تا کمی تغییر در بدنه متد‌ها ایجاد کنیم:
public class PlusCommand : ICommand
{
    private CalculatorViewModel calculatorViewModel;
    public PlusCommand(CalculatorViewModel vm)
    {
        calculatorViewModel = vm;
    }
    public bool CanExecute(object parameter)
    {
        return true;
    }
    public void Execute(object parameter)
    {
        calculatorViewModel.Add();
    }
    public event EventHandler CanExecuteChanged;
}
همانطور که می‌بینید در ابتدا فیلدی از جنس کلاس CalculatorViewModel ایجاد و از طریق سازنده‌ی کلاس آن را مقدار دهی کردیم (قصد داریم نمونه‌ای از ViewModel مورد نظر را به این کلاس ارسال کنیم).
در ادامه بصورت دستی (Hard Code) مقدار بازگردانده شده را برای تابع CanExecute به مقدار true  تغییر دادیم و متد تابع Execute را به شکلی تغییر دادیم تا تابع Add را در CalculatorViewModel، اجرا کند.

گام پنجم:
از کلاس PlusCommand در CalculatorViewModel، یک شیء ساخته و در سازنده‌ی CalculatorViewModel آن را مقدار دهی می‌کنیم: 
        private PlusCommand plusCommand;
        public CalculatorViewModel()
        {
            plusCommand = new PlusCommand(this);
        }

گام ششم:
در فایل CalculatorView ارجاعی را به فضای نام کلاس CalculatorViewModel ایجاد می‌کنیم :
   xmlns:vm="clr-namespace:ICommnadSample.ViewModels"
پس از اضافه کردن فضای نام، از تگ UserControl.Resource برای رجیستر کردن CalculatorViewModel با کلید calculatorVM جهت مشخص کردن منبع داده استفاده کردیم.
 <UserControl.Resources>
        <vm:CalculatorViewModel x:Key="calculatorVM" />
    </UserControl.Resources>

گام هفتم:
اضافه کردن تابع Add در CalculatorViewModel برای عملیات جمع :
public void Add()
{
   Output = firstValue + secondValue;
}

گام هشتم:
تعریف یک Command  برای عملیات جمع به نام AddCommand. این همان خصوصیتی است که باید بجای رویداد کلیک دکمه از طریق خاصیت Command موجود در کنترل و ویژگی Binding به کنترل متصل شود.
  public ICommand AddCommand {
            get
            {
                return plusCommand;
            }
        }

نحوه‌ی استفاده:
   Command="{Binding AddCommand}"
 
گام نهم :
برای تکمیل عملیات انقیاد داده‌ها، کلاسی به نام ViewModelBase تعریف شده است. این کلاس از اینترفیس INotifyPropertyChange ارث بری کرده و اعضای این کلاس را پیاده سازی کرده است.
  public class ViewModelBase:INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }
پیاده سازی این اینترفیس سبب می‌شود تا کلاس‌های ViewModel ایی که احتیاج به این اینترفیس برای عملیات انقیاد داده‌ها دارند، تنها با ارث بری، از این ظرفیت استفاده کنند و نیازی به پیاده سازی این اینترفیس در هر کلاس نباشد.

گام دهم:
ارث بری کلاس CalculatorViewModel از کلاس ViewModelBase:
   public class CalculatorViewModel : ViewModelBase
در این مرحله هر کنترلی را که قصد داریم با تغییر منبع داده بروز شود و یا با تغییر وضعیتش منبع داده تغییر کند، اعلام می‌کنیم:
   OnPropertyChanged("FirstValue");
برای هر سه خصوصیت ViewModel کد زیر را در بلاک Set تکرار می‌کنیم (توجه شود که پارامتر ارسالی باید نام پراپرتی مورد نظر باشد)
کد کامل کلاس CalculatorViewModel به شکل زیر است:
public class CalculatorViewModel : ViewModelBase
    {
        private double firstValue;
        private double secondValue;
        private double output;
        private PlusCommand plusCommand;
        public CalculatorViewModel()
        {
            plusCommand = new PlusCommand(this);
        }

        public double FirstValue
        {
            get { return firstValue; }

            set
            {
                firstValue = value;
                OnPropertyChanged("FirstValue");
            }
        }
        public double SecondValue
        {
            get { return secondValue; }
            set
            {
                secondValue = value;
                OnPropertyChanged("SecondValue");
            }
        }
        public double Output
        {

            get { return output; }

            set
            {
                output = value;
                OnPropertyChanged("Output");
            }
        }


        public ICommand AddCommand
        {
            get
            {
                return plusCommand;
            }
        }

        internal void Add()
        {
            Output = firstValue + secondValue;
        }
    }


حال می‌توانید برنامه را اجرا و تست کنید:



برای درک بهتر عملیات انقیاد دادها می‌توانید به این مقاله مراجعه کنید.

نظرات مطالب
نمایش فرم‌های مودال Ajax ایی در ASP.NET MVC به کمک Twitter Bootstrap
این مورد پیش بینی شده در این مثال. اگر به خروجی اکشن متد دقت کنید، چنین چیزی است:
return Json(new { success = true });
همین مورد یعنی بررسی مقدار success دریافتی، جایی که عملیات Ajax ایی ارسال اطلاعات پایان می‌یابد انجام شده:
if (result.success) {
                            $('#dialogDiv').modal('hide');
                            if (options.completeHandler)
                                options.completeHandler();
بنابراین تنها کاری که باید انجام بدید، قرار دادن کدهای نمایش اطلاعات نهایی در callbackهای completeHandler ویا errorHandler مربوط به افزونه  $.bootstrapModalAjaxForm است. اینجا دست شما باز است. اگر علاقمند بودید از یک alert ساده استفاده کنید یا از همین روش نمایش صفحات مودال به نحوی دیگر یا از صدها افزونه jQuery موجود برای نمایش پیام‌ها.

نظرات مطالب
اعمال تزریق وابستگی‌ها به مثال رسمی ASP.NET Identity
- UpdateSecurityStamp دقیقا همین کار را انجام می‌دهد. اجبار به اعتبارسنجی مجدد کوکی و در صورت نیاز، لاگین مجدد، پس از تغییر قسمت‌های مهم اکانت شخص.
- روش دیگر آ‌ن‌را برای NET Core. در اینجا توضیح دادم: «سفارشی سازی ASP.NET Core Identity - قسمت چهارم - User Claims» . قسمت «چگونه پس از ویرایش اطلاعات کاربر، اطلاعات کوکی او را نیز به روز کنیم؟ »