نظرات مطالب
اثر وجود سشن بر پردازش موازی در ASP.NET
در یکی از پروژه هایی که جدیدا باهاش درگیر شده ام دقیقا این مطلب رعایت نشده است. با ASP.NET WebForm نوشته شده و در یک صفحه هم از سشن به کرات استفاده شده برای مقاصد لاگین و متغیرهای سراسری و همچنین از چند ترد برای دریافت موازی اطلاعات از چند وب سرویس.
اما برای دفاع، منبع خوبی پیدا نمی‌کنم برای ارایه به کارفرما. فرومی که لینک دادید هم داخلش یک لینک هست برای mvc اما صفحه ارور ۴۰۳ میده. آیا سند معتبری هم هست برای ارایه به افراد ثالث؟
مطالب
رمزنگاری کانکشن استرینگ در ASP.Net

ذخیره کردن رشته اتصالی به دیتابیس، به صورت یک رشته مشخص در کدهای برنامه، کاری است مزموم. زیرا پس از هر بار تغییر این مورد، نیاز خواهد بود تا تمامی سورس‌ها تغییر کنند و اگر از حالت web application استفاده کرده باشید، مجبور خواهید شد یکبار دیگر برنامه را کامپایل و دایرکتوری bin روی سرور را به روز کنید. به همین جهت، استاندارد برنامه‌های ASP.Net این است که این رشته اتصالی را در فایل web.config ذخیره کنیم تا با هر بار تغییر پارامترهای مختلف آن (مثلا تغییر نام سرور، یا تعویض ماهیانه پسوردها)، مجبور به کامپایل مجدد برنامه نشویم. شبیه به همین مورد در برنامه‌های PHP هم رایج است و عموما این مشخصات در فایل config.php و یا با اسامی شبیه به این صورت می‌گیرد.
در ASP.Net 1.x قسمت خاصی برای کانکشن استرینگ وجود نداشت اما از ASP.Net 2 به بعد ، قسمت ویژه‌ای مخصوص این کار در فایل web.config در نظر گرفته شده است.
خیلی هم خوب! اما این تجربه تلخ کاری را (که یکبار برای من رخ داد) هم همواره در نظر داشته باشید:
امکان خوانده شدن محتوای فایل کانفیگ، توسط همسایه شما در همان هاست اشتراکی که الان از آن دارید استفاده می‌کنید. عموما هاست‌های اینترنتی اشتراکی هستند و نه dedicated و نه فقط مختص به شما. از یک سرور برای سرویس دهی به 100 ها سایت استفاده می‌شود. یکبار در یکی از سایت‌ها دیدم که فایل machine.config سرور را هم محض نمونه خوانده بودند چه برسد به فایل متنی کانفیگ شما! یا تصور کنید که وب سرور هک شود. عموما اس کیوال سرور بر روی سرور دیگری قرار دارد. به همین جهت رمزنگاری این رشته باز هم ضریب امنیت بیشتری را به همراه خواهد داشت.
به همین منظور رمزنگاری قسمت کانکشن استرینگ فایل وب کانفیگ الزامی است، چون آن‌هایی که به دنبال اطلاعاتی اینگونه هستند دقیقا می‌دانند باید به کجا مراجعه کنند.

راه حل‌ها:

الف) از وب کانفیگ برای این‌کار استفاده نکنید. یک فایل class library‌ درست کنید (یک dll مجزا) و ارجاعی از این فایل را به پروژه خود اضافه کنید و از رشته اتصالی قرار گرفته در آن استفاده کنید. این فایل را هم می‌توان با روش‌های obfuscation محافظت کرد تا امنیت اطلاعات داخل آن‌را تا حد قابل قبولی بالا برد. همچنین می‌توان برای این فایل کتابخانه، امضای دیجیتال درنظر گرفت. زیرا امضای دیجیتال سبب می‌شود تا تغییر فایل dll رشته اتصالی، با یک کپی و paste معمولی قابل انجام نباشد (تمامی dll ها و اسمبلی‌های دیگری که ارجاعی از آن‌را در خود دارند باید یکبار دیگر هم کامپایل و به سرور منتقل شوند). این یک نوع اطمینان خاطر است اما در بلند مدت شاید تکرار اینکار خسته کننده باشد.

ب)استفاده از روش استاندارد رمزنگاری قسمت‌های مختلف کانکشن استرینگ فایل web.config
برای مشاهده نحوه انجام اینکار با برنامه نویسی به این مقاله مراجعه نمائید.
مزیت: نیازی به کد نویسی برای رمزگشایی و استفاده از آن نیست و اینکار به صورت خودکار توسط ASP.Net انجام می‌شود.
ایراد:فایل حاصل قابل انتقال نیست. چون رمزنگاری بر اساس کلیدهای منحصربفرد سرور شما ایجاد می‌شوند، این فایل از یک سرور به سرور دیگر قابل انتقال و استفاده نخواهد بود. یعنی اگر بر روی کامپیوتر برنامه نویسی شما این‌کار صورت گرفت، برنامه در سرور کار نخواهد کرد. البته شاید ایراد آنچنانی نباشد و فقط باید یکبار دیگر روی هاست نیز این کار را تکرار کرد. اما باید درنظر داشت که همسایه محترم شما نیز می‌تواند بر روی همان هاست به سادگی فایل شما را رمزگشایی کند! بنابراین نباید اصلا به این روش در هاست‌های اشتراکی دل خوش کرد.

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

د)اگر سرور dedicated است حتما از روش windows authentication استفاده کنید
برای مثال یک سرور dedicated مخصوص کار ویژه‌ای تهیه کرده اید یا در شبکه اینترانت یک شرکت برنامه شما نصب شده است.
روش اعتبار سنجی از نوع ویندوزی برای اتصال به اس کیوال سرور نسبت به حالت sql server authentication امن تر است، زیرا نیازی نیست تا در وب کانفیگ نام کاربری یا پسوردی را مشخص نمائید و همچنین در این حالت پسوردها در شبکه منتقل نمی‌شوند (در حالت sql server authentication اینطور نیست). اما عموما در هاست‌های اشتراکی برای ساده تر کردن کار ، از این روش استفاده نمی‌کنند.
بنابراین در اینجا حتی اگر شخصی به رشته اتصالی شما دسترسی پیدا کند، کار خاصی را نمی‌تواند انجام دهد چون هیچگونه نام کاربری یا پسوردی در آن لحاظ نشده است.
در این روش به صورت پیش فرض از اکانت ASP.Net استفاده می‌شود. یعنی تمام برنامه‌ها محدود به یک اکانت خواهند شد.
برای تغییر این مورد دو کار را می‌توان انجام داد : استفاده از impersonation یا مطالعه قسمت بعد (ه)
توصیه: از روش impersonation به دلیل اینکه باید نام کاربری و کلمه عبور را باز هم به صورت واضحی ذکر نمود اجتناب کنید.

ه)ایجاد application pool مجزا به ازای هر برنامه ASP.Net در ویندوزهای سرور
Application pool که برای اولین بار در ویندوز سرور 2003 معرفی شده جهت ایزوله کردن برنامه‌های ASP.Net بکار برده می‌شود. به این صورت می‌شود برای هر pool یک اکانت ویندوزی مجزا تعریف کرد. حال می‌توان به این اکانت در اس کیوال سرور دسترسی داد. به این صورت برنامه‌های مختلف تحت یک اکانت واحد (یوزر asp.net) کار نکرده (می‌توانند هم کار کنند، اما امکان تعریف identity جدید برای کاربر آن در IIS‌ وجود دارد) و ضریب امنیتی بالاتری را تجربه خواهید کرد (در تکمیل روش (د))


مسیرراه‌ها
NHibernate
      مطالب
      ساخت تم سفارشی در انگیولار متریال ۲ - بخش دوم

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

      ساخت تم اضافی در کنار تم اصلی

      ساخت تم اضافی در انگیولار متریال ۲ بسیار ساده است. شما می‌توانید با استفاده مجدد از تابع angular-material-theme داخل یک کلاس CSS، صاحب یک تم اضافی دیگر شوید. برای نمونه در اینجا فایل my-custom-theme.scss را باز کرده و به شکل زیر تغییر می‌دهیم.

      @import '~@angular/material/theming';
      @include mat-core();
      $my-app-primary: mat-palette($mat-teal);
      $my-app-accent: mat-palette($mat-amber, 500, A100, A400);
      $my-app-warn: mat-palette($mat-deep-orange);
      
      $my-app-theme: mat-light-theme($my-app-primary, $my-app-accent, $my-app-warn);
      
      @include angular-material-theme($my-app-theme);
      
      /*تعریف تم اضافی در کنار تم اصلی*/
      $alternate-primary: mat-palette($mat-light-blue);
      $alternate-accent: mat-palette($mat-yellow, 500);
      $alternate-warn: mat-palette($mat-red, 500);
      $alternate-theme: mat-dark-theme($alternate-primary, $alternate-accent);
      .alternate-theme {
        @include angular-material-theme($alternate-theme);
      }

      با این‌کار در کنار تم روشن اصلی، یک تم مشکی به صورت اضافی داخل کلاس CSS به نام alternate-theme تعریف کرده‌ایم. در این حالت تمامی کامپوننتهایی که داخل المنت با کلاس alternate-theme قرار گرفته‌اند، از تم مشکی تعریف شده استفاده خواهند کرد.

      با تغییر فایل app.component.html به شکل زیر: 

      <md-card>
        <md-card-header>
          <md-card-title>تم اصلی</md-card-title>
        </md-card-header>
        <button md-raised-button color="primary">
          Primary
        </button>
        <button md-raised-button color="accent">
          Accent
        </button>
        <button md-raised-button color="warn">
          Warning
        </button>
      </md-card>
      
      <div>
        <md-card>
          <md-card-header>
            <md-card-title>تم اضافی</md-card-title>
          </md-card-header>
          <md-card-content>
            <button md-raised-button color="primary">
              Primary
            </button>
            <button md-raised-button color="accent">
              Accent
            </button>
            <button md-raised-button color="warn">
              Warning
            </button>
          </md-card-content>
        </md-card>
      </div>

      تصویر زیر را در خروجی خواهید داشت.

       

      به همین روش می‌توانید تعداد دلخواهی از تم‌ها را بسازید. همچنین می‌توانید هر تم اضافی را در یک فایل Sass تعریف کنید و از این طریق تم‌های مختلف را از هم جدا کنید. در این حالت به این نکته توجه داشته باشید که نباید mat-core@ در سرتاسر برنامه بیش از یکبار بارگذاری شده باشد. 

      ساخت تم به ازای هر کامپوننت

      با استفاده از mixin به نام angular-material-theme خروجی تولید شده بر روی تمامی کامپوننت‌های انگیولار متریال ۲ اعمال خواهد شد. اگر از تمامی کامپوننت‌های انگیولار متریال ۲ استفاده نمی‌کنید، می‌توانید برای کاهش حجم فایل CSS تولید شده از mixin مخصوص به هر کامپوننت استفاده کنید. همچنین برای ساخت تم‌های متفاوت به ازای هر کامپوننت نیز می‌توانید از این روش استفاده کنید. 

      برای این کار تمامی مراحلی که برای ساخت تم مورد نیاز بود، باید طی شود. فقط به جای استفاده از mixin به نام angular-material-theme بایستی به طریق زیر عمل شود. 

      اول: بارگذاری mixin با نام mat-core-them. این mixin تمامی استایل‌های مشترک رفتاری (مانند موج (ripple) در هنگام کلیک) برای کامپوننت‌ها را در بر دارد. این mixin خروجی تابع mat-light-theme یا mat-dark-theme را به عنوان ورودی دریافت می‌کند.

      دوم: بارگذاری mixin مربوط به هر کامپوننت. برای مثال برای دکمه از mixin به نام mat-button-theme و برای checkbox از mixin به نام mat-checkbox-theme می‌توانید استفاده کنید. در زیر لیست mixin‌ها به ازای کامپوننت‌های مختلف ذکر شده است. 

      mat-autocomplete-theme
      mat-button-theme
      mat-button-toggle-theme
      mat-card-theme
      mat-checkbox-theme
      mat-chips-theme
      mat-datepicker-theme
      mat-dialog-theme
      mat-grid-list-theme
      mat-icon-theme
      mat-input-theme
      mat-list-theme
      mat-menu-theme
      mat-progress-bar-theme
      mat-progress-spinner-theme
      mat-radio-theme
      mat-select-theme
      mat-sidenav-theme
      mat-slide-toggle-theme
      mat-slider-theme
      mat-tabs-theme
      mat-toolbar-theme
      mat-tooltip-theme

      در مثال زیر می‌خواهیم تمامی کامپوننت‌ها به جز کامپوننت دکمه، تم سبز(در گروه Primary) و دکمه‌ها نیز تم آبی داشته باشند. کافی است کدهای زیر را در فایل Sass خود وارد کنید. 

      @import '~@angular/material/theming';
      @include mat-core();
      $my-app-primary: mat-palette($mat-teal);
      $my-app-accent: mat-palette($mat-amber, 500, A100, A400);
      $my-app-warn: mat-palette($mat-deep-orange);
      $my-app-theme: mat-light-theme($my-app-primary, $my-app-accent, $my-app-warn);
      @include mat-material-theme($my-app-theme);
      
      /* تعریف تم برای دکمه */
      $button-primary: mat-palette($mat-light-blue);
      $button-accent: mat-palette($mat-yellow, 500);
      $button-warn: mat-palette($mat-red, 500);
      $button-theme: mat-light-theme($button-primary, $button-accent);
      @include mat-button-theme($button-theme);

      با توجه به اینکه mat-material-theme در داخل خود mat-button-theme را بارگذاری می‌کند دو نتیجه زیر را می‌توان گرفت.

      اول: اگر mat-material-theme بعد از هر کدام از mixinهای مربوط به کامپوننت‌ها نوشته شود، تمامی Cssهای تولید شده به ازای کامپوننت را دوباره نویسی کرده و عملا هیچ کدام کارایی نخواهند داشت. برای مثال کافی است فایل Sass خود را به شکل زیر تغییر دهید. در این صورت تم مربوط به دکمه کاریی نخواهد داشت. 

      @import '~@angular/material/theming';
      @include mat-core();
      
      /* تعریف تم برای دکمه */
      $button-primary: mat-palette($mat-light-blue);
      $button-accent: mat-palette($mat-yellow, 500);
      $button-warn: mat-palette($mat-red, 500);
      $button-theme: mat-ligth-theme($button-primary, $button-accent);
      @include mat-button-theme($button-theme);
      
      $my-app-primary: mat-palette($mat-teal);
      $my-app-accent: mat-palette($mat-amber, 500, A100, A400);
      $my-app-warn: mat-palette($mat-deep-orange);
      $my-app-theme: mat-light-theme($my-app-primary, $my-app-accent, $my-app-warn);
      @include mat-material-theme($my-app-theme);

      دوم: همانطور که گفتیم mat-button-theme در mat-material-theme قبلا بارگذاری شده است. با بارگذاری دوباره توسط mat-button-theme کدهای CSS که قبلا برای دکمه تولید شده‌اند را از نو دوباره می‌نویسد و این باعث بزرگ شدن حجم فایل Css تولید شده خواهد شد. پس بهتر است هنگام استفاده از mixinهای مختص کامپوننت‌ها از mat-material-theme استفاده نکنیم. 

        جهت بهبود کدهای قبلی بهتر است از کدهای زیر استفاده کنیم. 
      @import '~@angular/material/theming';
      @include mat-core();
      $my-app-primary: mat-palette($mat-teal);
      $my-app-accent: mat-palette($mat-amber, 500, A100, A400);
      $my-app-warn: mat-palette($mat-deep-orange);
      $my-app-theme: mat-light-theme($my-app-primary, $my-app-accent, $my-app-warn);
      
      $button-primary: mat-palette($mat-light-blue);
      $button-accent: mat-palette($mat-yellow, 500);
      $button-warn: mat-palette($mat-red, 500);
      $button-theme: mat-light-theme($button-primary, $button-accent);
      
      @include mat-core-theme($my-app-theme);
      @include mat-autocomplete-theme($my-app-theme);
      
      @include mat-button-theme($button-theme);
      
      @include mat-button-toggle-theme($my-app-theme);
      @include mat-card-theme($my-app-theme);
      @include mat-checkbox-theme($my-app-theme);
      @include mat-chips-theme($my-app-theme);
      @include mat-datepicker-theme($my-app-theme);
      @include mat-dialog-theme($my-app-theme);
      @include mat-grid-list-theme($my-app-theme);
      @include mat-icon-theme($my-app-theme);
      @include mat-input-theme($my-app-theme);
      @include mat-list-theme($my-app-theme);
      @include mat-menu-theme($my-app-theme);
      @include mat-progress-bar-theme($my-app-theme);
      @include mat-progress-spinner-theme($my-app-theme);
      @include mat-radio-theme($my-app-theme);
      @include mat-select-theme($my-app-theme);
      @include mat-sidenav-theme($my-app-theme);
      @include mat-slide-toggle-theme($my-app-theme);
      @include mat-slider-theme($my-app-theme);
      @include mat-tabs-theme($my-app-theme);
      @include mat-toolbar-theme($my-app-theme);
      @include mat-tooltip-theme($my-app-theme);

      تعویض تم از طریق کد

      فرض کنید یک تم پیش فرض و یک تم اضافی به نام alternate-theme دارید. برای تعویض تم از طریق کد کافی است کلاس المنت پدر در صفحه html خود را از طریق [ngClass] با نام تم، مقدار دهی کنید. کدهای داخل app.component.ts را به شکل زیر تغییر می‌دهیم. 

      import { Component } from '@angular/core';
      
      @Component({
        selector: 'app-root',
        templateUrl: './app.component.html',
        styleUrls: ['./app.component.css']
      })
      export class AppComponent {
        themes = [
          {value: 'alternate-theme', text: 'تم مشکی'},
          {value: '', text: 'تم سفید'},
        ];
        activeTheme = '';
      }

      آرایه‌ای جهت نمایش در کامپوننت md-select با دو مقدار تم پیش فرض و تم با نام 'alternate-theme تعریف می‌کنیم. همچنین متغیری با نام activeTheme را تعریف می‌کنیم. این متغیر در هر لحظه نام تم اعمال شده را در خود نگهداری می‌کند. مقدار اولیه این متغیر تم اصلی است.

      کامپوننت md-select را به شکل زیر به فایل app.component.html به تگ main اضافه می‌کنیم. 

      <md-select dir="rtl" [(ngModel)]="activeTheme" placeholder="تعویض تم">
          <md-option *ngFor="let theme of themes" [value]="theme.value">
                  {{ theme.text }}
          </md-option>
      </md-select>
      حالا کافی است کل تگهای موجود در app.component.html را داخل یک تگ div به شکل زیر قرار دهیم. 
      <div [ngClass]="activeTheme">
      بعد از اجرای برنامه می‌توانید با تعویض تم از طریق کامپوننت md-select، تم صفحه را تعویض کنید. 

      کدهای این قسمت را، از اینجا دریافت کنید: ساخت تم سفارشی در انگولار متریال ۲ - بخش دوم
      مطالب
      مدیریت Join در NHibernate 3.0

      مباحث eager fetching/loading (واکشی حریصانه) و lazy loading/fetching (واکشی در صورت نیاز، با تاخیر، تنبل) جزو نکات کلیدی کار با ORM های پیشرفته بوده و در صورت عدم اطلاع از آن‌ها و یا استفاده‌ی ناصحیح از هر کدام، باید منتظر از کار افتادن زود هنگام سیستم در زیر بار چند کاربر همزمان بود. به همین جهت تصور اینکه "با استفاده از ORMs دیگر از فراگیری SQL راحت شدیم!" یا اینکه "به من چه که پشت صحنه چه اتفاقی می‌افته!" بسی مهلک و نادرست است!
      در ادامه به تفصیل به این موضوع پرداخته خواهد شد.

      ابزار مورد نیاز

      در این مطلب از برنامه‌ی NHProf استفاده خواهد شد.
      اگر مطالب NHibernate این سایت را دنبال کرده باشید، در مورد لاگ کردن SQL تولیدی به اندازه‌ی کافی توضیح داده شده یا حتی یک ماژول جمع و جور هم برای مصارف دم دستی نوشته شده است. این موارد شاید این ایده را به همراه داشته باشند که چقدر خوب می‌شد یک برنامه‌ی جامع‌تر برای این نوع بررسی‌ها تهیه می‌شد. حداقل SQL نهایی فرمت می‌شد (یعنی برنامه باید مجهز به یک SQL Parser تمام عیار باشد که کار چند ماهی هست ...؛ با توجه به اینکه مثلا NHibernate از افزونه‌های SQL ویژه بانک‌های اطلاعاتی مختلف هم پشتیبانی می‌کند، مثلا T-SQL مایکروسافت با یک سری ریزه کاری‌های منحصر به MySQL متفاوت است)، یا پس از فرمت شدن، syntax highlighting به آن اضافه می‌شد، در ادامه مشخص می‌کرد کدام کوئری‌ها سنگین‌تر هستند، کدامیک نشانه‌ی عدم استفاده‌ی صحیح از ORM مورد استفاده است، چه مشکلی دارد و از این موارد.
      خوشبختانه این ایده‌ها یا آرزوها با برنامه‌ی NHProf محقق شده است. این برنامه برای استفاده‌ی یک ماه اول آن رایگان است (آدرس ایمیل خود را وارد کنید تا یک فایل مجوز رایگان یک ماهه برای شما ارسال گردد) و پس از یک ماه، باید حداقل 300 دلار هزینه کنید.


      واکشی حریصانه و غیرحریصانه چیست؟

      رفتار یک ORM جهت تعیین اینکه آیا نیاز است برای دریافت اطلاعات بین جداول Join صورت گیرد یا خیر، واکشی حریصانه و غیرحریصانه را مشخص می‌سازد.
      در حالت واکشی حریصانه به ORM خواهیم گفت که لطفا جهت دریافت اطلاعات فیلدهای جداول مختلف، از همان ابتدای کار در پشت صحنه، Join های لازم را تدارک ببین. در حالت واکشی غیرحریصانه به ORM خواهیم گفت به هیچ عنوان حق نداری Join ایی را تشکیل دهی. هر زمانی که نیاز به اطلاعات فیلدی از جدولی دیگر بود باید به صورت مستقیم به آن مراجعه کرده و آن مقدار را دریافت کنی.
      به صورت خلاصه برنامه نویس در حین کار با ORM های پیشرفته نیازی نیست Join بنویسد. تنها باید ORM را طوری تنظیم کند که آیا اینکار را حتما خودش در پشت صحنه انجام دهد (واکشی حریصانه)، یا اینکه خیر، به هیچ عنوان SQL های تولیدی در پشت صحنه نباید حاوی Join باشند (lazy loading).


      چگونه واکشی حریصانه و غیرحریصانه را در NHibernate 3.0 تنظیم کنیم؟

      در NHibernate اگر تنظیم خاصی را تدارک ندیده و خواص جداول خود را به صورت virtual معرفی کرده باشید، تنظیم پیش فرض دریافت اطلاعات همان lazy loading است. به مثالی در این زمینه توجه بفرمائید:

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


      using System.Collections.Generic;
      namespace CustomerOrdersSample.Domain
      {
      public class Customer
      {
      public virtual int Id { get; set; }
      public virtual string Name { get; set; }
      public virtual IList<Order> Orders { get; set; }
      }
      }

      using System;
      using System.Collections.Generic;
      namespace CustomerOrdersSample.Domain
      {
      public class Order
      {
      public virtual int Id { get; set; }
      public virtual DateTime OrderDate { set; get; }
      public virtual Customer Customer { get; set; }
      public virtual IList<OrderItem> OrderItems { set; get; }
      }
      }

      namespace CustomerOrdersSample.Domain
      {
      public class OrderItem
      {
      public virtual int Id { get; set; }
      public virtual Product Product { get; set; }
      public virtual int Quntity { get; set; }
      public virtual Order Order { set; get; }
      }
      }

      namespace CustomerOrdersSample.Domain
      {
      public class Product
      {
      public virtual int Id { set; get; }
      public virtual string Name { get; set; }
      public virtual decimal UnitPrice { get; set; }
      }
      }

      که جداول متناظر با آن به صورت زیر خواهند بود:
          create table Customers (
      CustomerId INT IDENTITY NOT NULL,
      Name NVARCHAR(255) null,
      primary key (CustomerId)
      )

      create table Orders (
      OrderId INT IDENTITY NOT NULL,
      OrderDate DATETIME null,
      CustomerId INT null,
      primary key (OrderId)
      )

      create table OrderItems (
      OrderItemId INT IDENTITY NOT NULL,
      Quntity INT null,
      ProductId INT null,
      OrderId INT null,
      primary key (OrderItemId)
      )

      create table Products (
      ProductId INT IDENTITY NOT NULL,
      Name NVARCHAR(255) null,
      UnitPrice NUMERIC(19,5) null,
      primary key (ProductId)
      )

      alter table Orders
      add constraint fk_Customer_Order
      foreign key (CustomerId)
      references Customers

      alter table OrderItems
      add constraint fk_Product_OrderItem
      foreign key (ProductId)
      references Products

      alter table OrderItems
      add constraint fk_Order_OrderItem
      foreign key (OrderId)
      references Orders

      همچنین یک سری اطلاعات آزمایشی زیر را هم در نظر بگیرید: (بانک اطلاعاتی انتخاب شده SQL CE است)

      SET IDENTITY_INSERT [Customers] ON;
      GO
      INSERT INTO [Customers] ([CustomerId],[Name]) VALUES (1,N'Customer1');
      GO
      SET IDENTITY_INSERT [Customers] OFF;
      GO
      SET IDENTITY_INSERT [Products] ON;
      GO
      INSERT INTO [Products] ([ProductId],[Name],[UnitPrice]) VALUES (1,N'Product1',1000.00000);
      GO
      INSERT INTO [Products] ([ProductId],[Name],[UnitPrice]) VALUES (2,N'Product2',2000.00000);
      GO
      INSERT INTO [Products] ([ProductId],[Name],[UnitPrice]) VALUES (3,N'Product3',3000.00000);
      GO
      SET IDENTITY_INSERT [Products] OFF;
      GO
      SET IDENTITY_INSERT [Orders] ON;
      GO
      INSERT INTO [Orders] ([OrderId],[OrderDate],[CustomerId]) VALUES (1,{ts '2011-01-07 11:25:20.000'},1);
      GO
      SET IDENTITY_INSERT [Orders] OFF;
      GO
      SET IDENTITY_INSERT [OrderItems] ON;
      GO
      INSERT INTO [OrderItems] ([OrderItemId],[Quntity],[ProductId],[OrderId]) VALUES (1,10,1,1);
      GO
      INSERT INTO [OrderItems] ([OrderItemId],[Quntity],[ProductId],[OrderId]) VALUES (2,5,2,1);
      GO
      INSERT INTO [OrderItems] ([OrderItemId],[Quntity],[ProductId],[OrderId]) VALUES (3,20,3,1);
      GO
      SET IDENTITY_INSERT [OrderItems] OFF;
      GO

      دریافت اطلاعات :
      می‌خواهیم نام کلیه محصولات خریداری شده توسط مشتری‌ها را به همراه نام مشتری و زمان خرید مربوطه، نمایش دهیم (دریافت اطلاعات از 4 جدول بدون join نویسی):

      var list = session.QueryOver<Customer>().List();

      foreach (var customer in list)
      {
      foreach (var order in customer.Orders)
      {
      foreach (var orderItem in order.OrderItems)
      {
      Console.WriteLine("{0}:{1}:{2}", customer.Name, order.OrderDate, orderItem.Product.Name);
      }
      }
      }

      خروجی به صورت زیر خواهد بود:
      Customer1:2011/01/07 11:25:20 :Product1
      Customer1:2011/01/07 11:25:20 :Product2
      Customer1:2011/01/07 11:25:20 :Product3
      اما بهتر است نگاهی هم به پشت صحنه عملیات داشته باشیم:



      همانطور که مشاهده می‌کنید در اینجا اطلاعات از 4 جدول مختلف دریافت می‌شوند اما ما Join ایی را ننوشته‌ایم. ORM هرجایی که به اطلاعات فیلدهای جداول دیگر نیاز داشته، به صورت مستقیم به آن جدول مراجعه کرده و یک کوئری، حاصل این عملیات خواهد بود (مطابق تصویر جمعا 6 کوئری در پشت صحنه برای نمایش سه سطر خروجی فوق اجرا شده است).
      این حالت فقط و فقط با تعداد رکورد کم بهینه است (و به همین دلیل هم تدارک دیده شده است). بنابراین اگر برای مثال قصد نمایش اطلاعات حاصل از 4 جدول فوق را در یک گرید داشته باشیم، بسته به تعداد رکوردها و تعداد کاربران همزمان برنامه (خصوصا در برنامه‌های تحت وب)، بانک اطلاعاتی باید بتواند هزاران هزار کوئری رسیده حاصل از lazy loading را پردازش کند و این یعنی مصرف بیش از حد منابع (IO بالا، مصرف حافظه بالا) به همراه بالا رفتن CPU usage و از کار افتادن زود هنگام سیستم.
      کسانی که پیش از این با SQL نویسی خو گرفته‌اند احتمالا الان منابع موجود را در مورد نحوه‌ی نوشتن Join در NHibernate زیر و رو خواهند کرد؛ زیرا پیش از این آموخته‌اند که برای دریافت اطلاعات از دو یا چند جدول مرتبط باید Join نوشت. اما همانطور که پیشتر نیز عنوان شد، اگر با جزئیات کار با NHibernate آشنا شویم، نیازی به Join نویسی نخواهیم داشت. اینکار را خود ORM در پشت صحنه باید و می‌تواند مدیریت کند. اما چگونه؟
      در NHibernate 3.0 با معرفی QueryOver که جایگزینی از نوع strongly typed همان ICriteria API قدیمی است، یا با معرفی Query که همان LINQ to NHibernate می‌باشد، متدی به نام Fetch نیز تدارک دیده شده است که استراتژی‌های lazy loading و eager loading را به سادگی توسط آن می‌توان مشخص نمود.

      مثال: دریافت اطلاعات با استفاده از QueryOver

      var list = session
      .QueryOver<Customer>()
      .Fetch(c => c.Orders).Eager
      .Fetch(c => c.Orders.First().OrderItems).Eager
      .Fetch(c => c.Orders.First().OrderItems.First().Product).Eager
      .List();

      foreach (var customer in list)
      {
      foreach (var order in customer.Orders)
      {
      foreach (var orderItem in order.OrderItems)
      {
      Console.WriteLine("{0}:{1}:{2}", customer.Name, order.OrderDate, orderItem.Product.Name);
      }
      }
      }

      پشت صحنه:



      اینبار فقط یک کوئری حاصل عملیات بوده و join ها به صورت خودکار با توجه به متدهای Fetch ذکر شده که حالت eager loading آن‌ها صریحا مشخص شده است، تشکیل شده‌اند (6 بار رفت و برگشت به بانک اطلاعاتی به یکبار تقلیل یافت).

      نکته 1: نتایج تکراری
      اگر حاصل join آخر را نمایش دهیم، نتایجی تکراری خواهیم داشت که مربوط است به مقدار دهی customer با سه وهله از شیء مربوطه تا بتواند واکشی حریصانه‌ی مجموعه اشیاء فرزند آن‌را نیز پوشش دهد. برای رفع این مشکل یک سطر TransformUsing باید اضافه شود:
      ...
      .TransformUsing(NHibernate.Transform.Transformers.DistinctRootEntity)
      .List();


      دریافت اطلاعات با استفاده از LINQ to NHibernate3.0
      برای اینکه بتوان متدهای Fetch ذکر شده را به LINQ to NHibernate 3.0 اعمال نمود، ذکر فضای نام NHibernate.Linq ضروری است. پس از آن خواهیم داشت:
      var list = session
      .Query()
      .FetchMany(c => c.Orders)
      .ThenFetchMany(o => o.OrderItems)
      .ThenFetch(p => p.Product)
      .ToList();

      اینبار از FetchMany، سپس ThenFetchMany (برای واکشی حریصانه مجموعه‌های فرزند) و در آخر از ThenFetch استفاده خواهد شد.

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


      نکته 2: خطاهای ممکن
      ممکن است حین تعریف متدهای Fetch در زمان اجرا به خطاهای Antlr.Runtime.MismatchedTreeNodeException و یا Specified method is not supported و یا موارد مشابهی برخورد نمائید. تنها کاری که باید انجام داد جابجا کردن مکان بکارگیری extension methods است. برای مثال متد Fetch باید پس از Where در حالت استفاده از LINQ ذکر شود و نه قبل از آن.

      نظرات مطالب
      مقابله با XSS ؛ یکبار برای همیشه!
      کاری که ماژول مایکروسافت انجام می‌ده علاوه بر حذف موارد زائد، تبدیل متن به XHTML استاندارد است و همچنین اعمال انواع و اقسام encoding؛ به همین جهت این نوع تبدیلات رو شما مشاهده می‌کنید ولی ... مطلوب کار ما نیست. در کل به خاطر این مسایل من ماژول مایکروسافت رو کنار گذاشتم (هر چند از لحاظ تشخیص حملات عالی است اما فعلا قابل تنظیم نیست و یک ضرب هر کاری که دوست دارد انجام می‌دهد). از یک روش دیگر استفاده کردم که سبک‌تر است و این مشکلات را هم ندارد(+). این روش بر اساس white list عمل می‌کند. یعنی می‌گه یک سری تگ html از نظر من مجاز است و مابقی خطرناک‌ها همه باید حذف شوند.
      مثال به روز شد لطفا آن‌را دریافت کنید.
      مطالب
      ساخت یک Web API که از عملیات CRUD پشتیبانی می کند
      در این مقاله با استفاده از ASP.NET Web API یک سرویس HTTP خواهیم ساخت که از عملیات CRUD پشتیبانی می‌کند. CRUD مخفف Create, Read, Update, Delete است که عملیات پایه دیتابیسی هستند. بسیاری از سرویس‌های HTTP این عملیات را بصورت REST API هم مدل سازی می‌کنند. در مثال جاری سرویس ساده ای خواهیم ساخت که مدیریت لیستی از محصولات (Products) را ممکن می‌سازد. هر محصول شامل فیلدهای شناسه (ID)، نام، قیمت و طبقه بندی خواهد بود.

      سرویس ما متدهای زیر را در دسترس قرار می‌دهد.

       Relative URl
       HTTP method
       Action
       api/products/  GET  گرفتن لیست تمام محصولات
       api/products/id/  GET  گرفتن یک محصول بر اساس شناسه
       api/products?category=category/  GET  گرفتن یک محصول بر اساس طبقه بندی
       api/products/  POST  ایجاد یک محصول جدید
       api/products/id/  PUT  بروز رسانی یک محصول
       api/products/id/  DELETE  حذف یک محصول

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

      http://hostname/api/products/28

      منابع

      سرویس ما آدرس هایی برای دستیابی به دو نوع منبع (resource) را تعریف می‌کند:

      URI
       Resource
       api/products/  لیست تمام محصولات
       api/products/id/  یک محصول مشخص

      متد ها

      چهار متد اصلی HTTP یعنی همان GET, PUT, POST, DELETE می‌توانند بصورت زیر به عملیات CRUD نگاشت شوند:

      • متد GET یک منبع (resource) را از آدرس تعریف شده دریافت می‌کند. متدهای GET هیچگونه تاثیری روی سرور نباید داشته باشند. مثلا حذف رکوردها با متد اکیدا اشتباه است.
      • متد PUT یک منبع را در آدرس تعریف شده بروز رسانی می‌کند. این متد برای ساختن منابع جدید هم می‌تواند استفاده شود، البته در صورتی که سرور به کلاینت‌ها اجازه مشخص کردن آدرس‌های جدید را بدهد. در مثال جاری پشتیبانی از ایجاد منابع توسط متد PUT را بررسی نخواهیم کرد.
      • متد POST منبع جدیدی می‌سازد. سرور آدرس آبجکت جدید را تعیین می‌کند و آن را بعنوان بخشی از پیام Response بر می‌گرداند.
      • متد DELETE منبعی را در آدرس تعریف شده حذف می‌کند.

      نکته: متد PUT موجودیت محصول (product entity) را کاملا جایگزین میکند. به بیان دیگر، از کلاینت انتظار می‌رود که آبجکت کامل محصول را برای بروز رسانی ارسال کند. اگر می‌خواهید از بروز رسانی‌های جزئی/پاره ای (partial) پشتیبانی کنید متد PATCH توصیه می‌شود. مثال جاری متد PATCH را پیاده سازی نمی‌کند.

      یک پروژه Web API جدید بسازید

      ویژوال استودیو را باز کنید و پروژه جدیدی از نوع ASP.NET MVC Web Application بسازید. نام پروژه را به "ProductStore" تغییر دهید و OK کنید.

      در دیالوگ New ASP.NET Project قالب Web API را انتخاب کرده و تایید کنید.

      افزودن یک مدل

      یک مدل، آبجکتی است که داده اپلیکیشن شما را نمایندگی می‌کند. در ASP.NET Web API می‌توانید از آبجکت‌های Strongly-typed بعنوان مدل هایتان استفاده کنید که بصورت خودکار برای کلاینت به فرمت‌های JSON, XML مرتب (Serialize) می‌شوند. در مثال جاری، داده‌های ما محصولات هستند. پس کلاس جدیدی بنام Product می‌سازیم.

      در پوشه Models کلاس جدیدی با نام Product بسازید.

      حال خواص زیر را به این کلاس اضافه کنید.

      namespace ProductStore.Models
      {
          public class Product
          {
              public int Id { get; set; }
              public string Name { get; set; }
              public string Category { get; set; }
              public decimal Price { get; set; }
          }
      }

      افزودن یک مخزن

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

      روی پوشه Models کلیک راست کنید و گزینه Add, New Item را انتخاب نمایید.

      نوع آیتم جدید را Interface انتخاب کنید و نام آن را به IProductRepository تغییر دهید.

      حال کد زیر را به این اینترفیس اضافه کنید.

      namespace ProductStore.Models
      {
          public interface IProductRepository
          {
              IEnumerable<Product> GetAll();
              Product Get(int id);
              Product Add(Product item);
              void Remove(int id);
              bool Update(Product item);
          }
      }
      حال کلاس دیگری با نام ProductRepository در پوشه Models ایجاد کنید. این کلاس قرارداد IProductRepository را پیاده سازی خواهد کرد. کد زیر را به این کلاس اضافه کنید.

      namespace ProductStore.Models
      {
          public class ProductRepository : IProductRepository
          {
              private List<Product> products = new List<Product>();
              private int _nextId = 1;
      
              public ProductRepository()
              {
                  Add(new Product { Name = "Tomato soup", Category = "Groceries", Price = 1.39M });
                  Add(new Product { Name = "Yo-yo", Category = "Toys", Price = 3.75M });
                  Add(new Product { Name = "Hammer", Category = "Hardware", Price = 16.99M });
              }
      
              public IEnumerable<Product> GetAll()
              {
                  return products;
              }
      
              public Product Get(int id)
              {
                  return products.Find(p => p.Id == id);
              }
      
              public Product Add(Product item)
              {
                  if (item == null)
                  {
                      throw new ArgumentNullException("item");
                  }
                  item.Id = _nextId++;
                  products.Add(item);
                  return item;
              }
      
              public void Remove(int id)
              {
                  products.RemoveAll(p => p.Id == id);
              }
      
              public bool Update(Product item)
              {
                  if (item == null)
                  {
                      throw new ArgumentNullException("item");
                  }
                  int index = products.FindIndex(p => p.Id == item.Id);
                  if (index == -1)
                  {
                      return false;
                  }
                  products.RemoveAt(index);
                  products.Add(item);
                  return true;
              }
          }
      }

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


      افزودن یک کنترلر Web API

      اگر قبلا با ASP.NET MVC کار کرده باشید، با مفهوم کنترلر‌ها آشنایی دارید. در ASP.NET Web API کنترلر‌ها کلاس هایی هستند که درخواست‌های HTTP دریافتی از کلاینت را به اکشن متدها نگاشت می‌کنند. ویژوال استودیو هنگام ساختن پروژه شما دو کنترلر به آن اضافه کرده است. برای مشاهد آنها پوشه Controllers را باز کنید.

      • HomeController یک کنترلر مرسوم در ASP.NET MVC است. این کنترلر مسئول بکار گرفتن صفحات وب است و مستقیما ربطی به Web API ما ندارد.
      • ValuesController یک کنترلر نمونه WebAPI است.

      کنترلر ValuesController را حذف کنید، نیازی به این آیتم نخواهیم داشت. حال برای اضافه کردن کنترلری جدید مراحل زیر را دنبال کنید.

      در پنجره Solution Explorer روی پوشه Controllers کلیک راست کرده و گزینه Add, Controller را انتخاب کنید.

      در دیالوگ Add Controller نام کنترلر را به ProductsController تغییر داده و در قسمت Scaffolding Options گزینه Empty API Controller را انتخاب کنید.

      حال فایل کنترلر جدید را باز کنید و عبارت زیر را به بالای آن اضافه نمایید.

      using ProductStore.Models;
      یک فیلد هم برای نگهداری وهله ای از IProductRepository اضافه کنید.
      public class ProductsController : ApiController
      {
          static readonly IProductRepository repository = new ProductRepository();
      }

      فراخوانی ()new ProductRepository طراحی جالبی نیست، چرا که کنترلر را به پیاده سازی بخصوصی از این اینترفیس گره می‌زند. بهتر است از تزریق وابستگی (Dependency Injection) استفاده کنید. برای اطلاعات بیشتر درباره تکنیک DI در Web API به این لینک مراجعه کنید.


      گرفتن منابع

      ProductStore API اکشن‌های متعددی در قالب متدهای HTTP GET در دسترس قرار می‌دهد. هر اکشن به متدی در کلاس ProductsController مرتبط است.

       Relative URl
       HTTP Method
       Action
       api/products/  GET  دریافت لیست تمام محصولات
       api/products/id/  GET  دریافت محصولی مشخص بر اساس شناسه
       api/products?category=category/  GET  دریافت محصولات بر اساس طبقه بندی

      برای دریافت لیست تمام محصولات متد زیر را به کلاس ProductsController اضافه کنید.

      public class ProductsController : ApiController
      {
          public IEnumerable<Product> GetAllProducts()
          {
              return repository.GetAll();
          }
          // ....
      }
      نام این متد با "Get" شروع می‌شود، پس بر اساس قراردادهای توکار پیش فرض به درخواست‌های HTTP GET نگاشت خواهد شد. همچنین از آنجا که این متد پارامتری ندارد، به URl ای نگاشت می‌شود که هیچ قسمتی با نام مثلا id نداشته باشد.

      برای دریافت محصولی مشخص بر اساس شناسه آن متد زیر را اضافه کنید.
      public Product GetProduct(int id)
      {
          Product item = repository.Get(id);
          if (item == null)
          {
              throw new HttpResponseException(HttpStatusCode.NotFound); 
          }
          return item;
      }

      نام این متد هم با "Get" شروع می‌شود اما پارامتری با نام id دارد. این پارامتر به قسمت id مسیر درخواست شده (request URl) نگاشت می‌شود. تبدیل پارامتر به نوع داده مناسب (در اینجا int) هم بصورت خودکار توسط فریم ورک ASP.NET Web API انجام می‌شود.

      متد GetProduct در صورت نامعتبر بودن پارامتر id استثنایی از نوع HttpResponseException تولید می‌کند. این استثنا بصورت خودکار توسط فریم ورک Web API به خطای 404 (Not Found) ترجمه می‌شود.

      در آخر متدی برای دریافت محصولات بر اساس طبقه بندی اضافه کنید.
      public IEnumerable<Product> GetProductsByCategory(string category)
      {
          return repository.GetAll().Where(
              p => string.Equals(p.Category, category, StringComparison.OrdinalIgnoreCase));
      }

      اگر آدرس درخواستی پارامتر‌های query string داشته باشد، Web API سعی می‌کند پارامتر‌ها را با پارامتر‌های متد کنترلر تطبیق دهد. بنابراین درخواستی به آدرس "api/products?category=category" به این متد نگاشت می‌شود.

      ایجاد منبع جدید

      قدم بعدی افزودن متدی به ProductsController برای ایجاد یک محصول جدید است. لیست زیر پیاده سازی ساده ای از این متد را نشان می‌دهد.

      // Not the final implementation!
      public Product PostProduct(Product item)
      {
          item = repository.Add(item);
          return item;
      }
      به دو چیز درباره این متد توجه کنید:

      • نام این متد با "Post" شروع می‌شود. برای ساختن محصولی جدید کلاینت یک درخواست HTTP POST ارسال می‌کند.
      • این متد پارامتری از نوع Product می‌پذیرد. در Web API پارامترهای پیچیده (complex types) بصورت خودکار با deserialize کردن بدنه درخواست بدست می‌آیند. بنابراین در اینجا از کلاینت انتظار داریم که آبجکتی از نوع Product را با فرمت XML یا JSON ارسال کند.

      پیاده سازی فعلی این متد کار می‌کند، اما هنوز کامل نیست. در حالت ایده آل ما می‌خواهیم پیام HTTP Response موارد زیر را هم در بر گیرد:

      • Response code: بصورت پیش فرض فریم ورک Web API کد وضعیت را به 200 (OK) تنظیم می‌کند. اما طبق پروتکل HTTP/1.1 هنگامی که یک درخواست POST منجر به ساخته شدن منبعی جدید می‌شود، سرور باید با کد وضعیت 201 (Created) پاسخ دهد.
      • Location: هنگامی که سرور منبع جدیدی می‌سازد، باید آدرس منبع جدید را در قسمت Location header پاسخ درج کند.

      ASP.NET Web API دستکاری پیام HTTP response را آسان می‌کند. لیست زیر پیاده سازی بهتری از این متد را نشان می‌دهد.

      public HttpResponseMessage PostProduct(Product item)
      {
          item = repository.Add(item);
          var response = Request.CreateResponse<Product>(HttpStatusCode.Created, item);
      
          string uri = Url.Link("DefaultApi", new { id = item.Id });
          response.Headers.Location = new Uri(uri);
          return response;
      }
      توجه کنید که حالا نوع بازگشتی این متد HttpResponseMessage است. با بازگشت دادن این نوع داده بجای Product، می‌توانیم جزئیات پیام HTTP response را کنترل کنیم. مانند تغییر کد وضعیت و مقدار دهی Location header.

      متد CreateResponse آبجکتی از نوع HttpResponseMessage می‌سازد و بصورت خودکار آبجکت Product را مرتب (serialize) کرده و در بدنه پاسخ می‌نویسد. نکته دیگر آنکه مثال جاری، مدل را اعتبارسنجی نمی‌کند. برای اطلاعات بیشتر درباره اعتبارسنجی مدل‌ها در Web API به این لینک مراجعه کنید.


      بروز رسانی یک منبع

      بروز رسانی یک محصول با PUT ساده است.

      public void PutProduct(int id, Product product)
      {
          product.Id = id;
          if (!repository.Update(product))
          {
              throw new HttpResponseException(HttpStatusCode.NotFound);
          }
      }
      نام این متد با "Put" شروع می‌شود، پس Web API آن را به درخواست‌های HTTP PUT نگاشت خواهد کرد. این متد دو پارامتر می‌پذیرد، یکی شناسه محصول مورد نظر و دیگری آبجکت محصول آپدیت شده. مقدار پارامتر id از مسیر (route) دریافت می‌شود و پارامتر محصول با deserialize کردن بدنه درخواست.


      حذف یک منبع

      برای حذف یک محصول متد زیر را به کلاس ProductsController اضافه کنید.

      public void DeleteProduct(int id)
      {
          Product item = repository.Get(id);
          if (item == null)
          {
              throw new HttpResponseException(HttpStatusCode.NotFound);
          }
      
          repository.Remove(id);
      }
      اگر یک درخواست DELETE با موفقیت انجام شود، می‌تواند کد وضعیت 200 (OK) را بهمراه بدنه موجودیتی که وضعیت فعلی را نمایش می‌دهد برگرداند. اگر عملیات حذف هنوز در حال اجرا است (Pending) می‌توانید کد 202 (Accepted) یا 204 (No Content) را برگردانید.

      در مثال جاری متد DeleteProduct نوع void را بر می‌گرداند، که فریم ورک Web API آن را بصورت خودکار به کد وضعیت 204 (No Content) ترجمه می‌کند.
      نظرات مطالب
      سری فیبوناچی و دات نت 4 !
      بخوبی یادم میاد که در درس طراحی الگوریتم خونده بودیم که نوشتن دنباله فیبوناچی بصورت بازگشتی صحیح نیست و بهتره که از روش های ساده یعنی استفاده از یک حلقه ساده برای بدست آوردن جواب استفاده کرد. که شما هم درواقع برنامه رو بصورت یک حلقه ساده نوشتید و با yield مقدار نهایی رو برگردوندید. کار بسیار خوبیه و از شما سپاسگذارم که این موارد رو یادآوری می کنید. اینها نشون میده که نوشتن یک متد بصورت اشتباه چقدر کارایی برنامه رو پایین میاره. امیدوارم در آینده الگوریتم های دیگری رو هم بررسی کنید.
      اشتراک‌ها
      async scripts کدامند؟
      مرورگرهای جدید بارگذاری غیرهمزمان اسکریپت‌های صفحه را پشتیبانی می‌کنند
      <script async src="...">
      async scripts کدامند؟