بهترین ادیتور bootstrap
ASP.NET Web API فریم ورکی برای ساختن APIهای وب بر روی فریم ورک دات نت است. در این مقاله با استفاده از این فریم ورک، API وبی خواهیم ساخت که لیستی از محصولات را بر میگرداند. صفحه وب کلاینت، با استفاده از jQuery نتایج را نمایش خواهد داد.
یک پروژه Web API بسازید
در ویژوال استودیو 2013 پروژه جدیدی از نوع ASP.NET Web Application بسازید و نام آن را "ProductsApp" انتخاب کنید.
در دیالوگ New ASP.NET Project قالب Empty را انتخاب کنید و در قسمت "Add folders and core references for" گزینه Web API را انتخاب نمایید.
می توانید از قالب Web API هم استفاده کنید. این قالب با استفاده از ASP.NET MVC صفحات راهنمای API را خواهد ساخت. در این مقاله از قالب Empty استفاده میکنیم تا تمرکز اصلی، روی خود فریم ورک Web API باشد. بطور کلی برای استفاده از این فریم ورک لازم نیست با ASP.NET MVC آشنایی داشته باشید.
افزودن یک مدل
یک مدل (model) آبجکتی است که داده اپلیکیشن شما را معرفی میکند. ASP.NET Web API میتواند بصورت خودکار مدل شما را به JSON, XML و برخی فرمتهای دیگر مرتب (serialize) کند، و سپس داده مرتب شده را در بدنه پیام HTTP Response بنویسد. تا وقتی که یک کلاینت بتواند فرمت مرتب سازی دادهها را بخواند، میتواند آبجکت شما را deserialize کند. اکثر کلاینتها میتوانند XML یا JSON را تفسیر کنند. بعلاوه کلاینتها میتوانند فرمت مورد نظرشان را با تنظیم Accept header در پیام HTTP Request مشخص کنند.
بگذارید تا با ساختن مدلی ساده که یک محصول (product) را معرفی میکند شروع کنیم.
کلاس جدیدی در پوشه Models ایجاد کنید.
نام کلاس را به "Product" تغییر دهید، و خواص زیر را به آن اضافه کنید.
namespace ProductsApp.Models { public class Product { public int Id { get; set; } public string Name { get; set; } public string Category { get; set; } public decimal Price { get; set; } } }
افزودن یک کنترلر
در Web API کنترلرها آبجکت هایی هستند که درخواستهای HTTP را مدیریت کرده و آنها را به اکشن متدها نگاشت میکنند. ما کنترلری خواهیم ساخت که میتواند لیستی از محصولات، یا محصولی بخصوص را بر اساس شناسه برگرداند. اگر از ASP.NET MVC استفاده کرده اید، با کنترلرها آشنا هستید. کنترلرهای Web API مشابه کنترلرهای MVC هستند، با این تفاوت که بجای ارث بری از کلاس Controller از کلاس ApiController مشتق میشوند.
کنترلر جدیدی در پوشه Controllers ایجاد کنید.
در دیالوگ Add Scaffold گزینه Web API Controller - Empty را انتخاب کرده و روی Add کلیک کنید.
در دیالوگ Add Controller نام کنترلر را به "ProductsController" تغییر دهید و روی Add کلیک کنید.
توجه کنید که ملزم به ساختن کنترلرهای خود در پوشه Controllers نیستید، و این روش صرفا قراردادی برای مرتب نگاه داشتن ساختار پروژهها است. کنترلر ساخته شده را باز کنید و کد زیر را به آن اضافه نمایید.
using ProductsApp.Models; using System; using System.Collections.Generic; using System.Linq; using System.Net; using System.Web.Http; namespace ProductsApp.Controllers { public class ProductsController : ApiController { Product[] products = new Product[] { new Product { Id = 1, Name = "Tomato Soup", Category = "Groceries", Price = 1 }, new Product { Id = 2, Name = "Yo-yo", Category = "Toys", Price = 3.75M }, new Product { Id = 3, Name = "Hammer", Category = "Hardware", Price = 16.99M } }; public IEnumerable<Product> GetAllProducts() { return products; } public IHttpActionResult GetProduct(int id) { var product = products.FirstOrDefault((p) => p.Id == id); if (product == null) { return NotFound(); } return Ok(product); } }
کنترلر ما دو متد برای دریافت محصولات تعریف میکند:
- متد GetAllProducts لیست تمام محصولات را در قالب یک <IEnumerable<Product بر میگرداند.
- متد GetProductById سعی میکند محصولی را بر اساس شناسه تعیین شده پیدا کند.
همین! حالا یک Web API ساده دارید. هر یک از متدهای این کنترلر، به یک یا چند URI پاسخ میدهند:
URI | Controller Method |
api/products/ | GetAllProducts |
api/products/id/ | GetProductById |
برای اطلاعات بیشتر درباره نحوه نگاشت درخواستهای HTTP به اکشن متدها توسط Web API به این لینک مراجعه کنید.
فراخوانی Web API با جاوا اسکریپت و jQuery
در این قسمت یک صفحه HTML خواهیم ساخت که با استفاده از AJAX متدهای Web API را فراخوانی میکند. برای ارسال درخواستهای آژاکسی و بروز رسانی صفحه بمنظور نمایش نتایج دریافتی از jQuery استفاده میکنیم.
در پنجره Solution Explorer روی نام پروژه کلیک راست کرده و گزینه Add, New Item را انتخاب کنید.
در دیالوگ Add New Item قالب HTML Page را انتخاب کنید و نام فایل را به "index.html" تغییر دهید.
حال محتوای این فایل را با لیست زیر جایگزین کنید.
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Product App</title> </head> <body> <div> <h2>All Products</h2> <ul id="products" /> </div> <div> <h2>Search by ID</h2> <input type="text" id="prodId" size="5" /> <input type="button" value="Search" onclick="find();" /> <p id="product" /> </div> <script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-2.0.3.min.js"></script> <script> var uri = 'api/products'; $(document).ready(function () { // Send an AJAX request $.getJSON(uri) .done(function (data) { // On success, 'data' contains a list of products. $.each(data, function (key, item) { // Add a list item for the product. $('<li>', { text: formatItem(item) }).appendTo($('#products')); }); }); }); function formatItem(item) { return item.Name + ': $' + item.Price; } function find() { var id = $('#prodId').val(); $.getJSON(uri + '/' + id) .done(function (data) { $('#product').text(formatItem(data)); }) .fail(function (jqXHR, textStatus, err) { $('#product').text('Error: ' + err); }); } </script> </body> </html>
گرفتن لیستی از محصولات
برای گرفتن لیستی از محصولات، یک درخواست HTTP GET به آدرس "api/products/" ارسال کنید.
تابع getJSON یک درخواست آژاکسی ارسال میکند. پاسخ دریافتی هم آرایه ای از آبجکتهای JSON خواهد بود. تابع done در صورت موفقیت آمیز بودن درخواست، اجرا میشود. که در این صورت ما DOM را با اطلاعات محصولات بروز رسانی میکنیم.
$(document).ready(function () { // Send an AJAX request $.getJSON(apiUrl) .done(function (data) { // On success, 'data' contains a list of products. $.each(data, function (key, item) { // Add a list item for the product. $('<li>', { text: formatItem(item) }).appendTo($('#products')); }); }); });
گرفتن محصولی مشخص
برای گرفتن یک محصول توسط شناسه (ID) آن کافی است یک درخواست HTTP GET به آدرس "api/products/id/" ارسال کنید.
function find() { var id = $('#prodId').val(); $.getJSON(apiUrl + '/' + id) .done(function (data) { $('#product').text(formatItem(data)); }) .fail(function (jqXHR, textStatus, err) { $('#product').text('Error: ' + err); }); }
اجرای اپلیکیشن
اپلیکیشن را با F5 اجرا کنید. صفحه وب باز شده باید چیزی مشابه تصویر زیر باشد.
برای گرفتن محصولی مشخص، شناسه آن را وارد کنید و روی Search کلیک کنید.
اگر شناسه نامعتبری وارد کنید، سرور یک خطای HTTP بر میگرداند.
استفاده از F12 برای مشاهده درخواستها و پاسخ ها
هنگام کار با سرویسهای HTTP، مشاهدهی درخواستهای ارسال شده و پاسخهای دریافتی بسیار مفید است. برای اینکار میتوانید از ابزار توسعه دهندگان وب استفاده کنید، که اکثر مرورگرهای مدرن، پیاده سازی خودشان را دارند. در اینترنت اکسپلورر میتوانید با F12 به این ابزار دسترسی پیدا کنید. به برگه Network بروید و روی Start Capturing کلیک کنید. حالا صفحه وب را مجددا بارگذاری (reload) کنید. در این مرحله اینترنت اکسپلورر ترافیک HTTP بین مرورگر و سرور را تسخیر میکند. میتوانید تمام ترافیک HTTP روی صفحه جاری را مشاهده کنید.
به دنبال آدرس نسبی "api/products/" بگردید و آن را انتخاب کنید. سپس روی Go to detailed view کلیک کنید تا جزئیات ترافیک را مشاهده کنید. در نمای جزئیات، میتوانید headerها و بدنه درخواستها و پاسخها را ببینید. مثلا اگر روی برگه Request headers کلیک کنید، خواهید دید که اپلیکیشن ما در Accept header دادهها را با فرمت "application/json" درخواست کرده است.
اگر روی برگه Response body کلیک کنید، میتوانید ببینید چگونه لیست محصولات با فرمت JSON سریال شده است. همانطور که گفته شده مرورگرهای دیگر هم قابلیتهای مشابهی دارند. یک ابزار مفید دیگر Fiddler است. با استفاده از این ابزار میتوانید تمام ترافیک HTTP خود را مانیتور کرده، و همچنین درخواستهای جدیدی بسازید که این امر کنترل کاملی روی HTTP headers به شما میدهد.
قدمهای بعدی
CREATE TABLE accounts ( user_id INTEGER PRIMARY KEY, balance INTEGER NOT NULL );
INSERT INTO accounts(user_id, balance) VALUES (1, 300);
DECLARE @amount INT; SET @amount = ( SELECT balance FROM accounts WHERE user_id = 1 ); SELECT @amount as 'balance' UPDATE accounts SET balance = @amount - 100 WHERE user_id = 1; SELECT balance as 'balance after shopping' FROM accounts WHERE user_id = 1
- در اینجا مقدار متغیر amount در ابتدای کار، مساوی 300 است که مربوط به همان insert ابتدایی است.
- سپس از این مقدار در کوئری دومی (برای مثال حاصل از خرید شماره یک)، 100 واحد کم میشود (برای مثال قیمت کل خرید است).
- در این حالت نتیجهی آن یا همان موجودی جدید کاربر، 200 خواهد بود.
معادل این عملیات در EF-Core چنین دستورات متداولی است:
var account1 = context.Accounts.First(x => x.UserId == 1); account1.Balance -= 100; context.SaveChanges();
سؤال: اگر کوئریهای فوق را در یک برنامهی ذاتا چند ریسمانی وب، دوبار به صورت همزمان اجرا کنیم، یعنی دو عمل خرید موازی را شبیه سازی کنیم، چه اتفاقی رخ میدهد؟ آیا موجودی نهایی اینبار برای مثال 100 میشود (با فرض 300 بودن موجودی ابتدایی)؟
پاسخ خیر است! و آنرا میتوانید در تصویر زیر مشاهده کنید:
در اینجا برای شبیه سازی اجرای موازی دو کوئری، از دستور WAITFOR TIME استفاده شدهاست که برای برای آزمایش آن میتوانید مقدار آنرا به یک دقیقه بعد تنظیم کرده و سپس آنرا در دو پنجرهی SQL server management studio اجرا کنید.
همانطور که مشاهده میکنید، با اجرای موازی این دو کوئری، یعنی دوبار خرید کردن همزمان، 100 واحد گم شدهاست ! به این مشکل همزمانی read و سپس update رخ داده، یک «race condition» گفته میشود و این روزها که مطالب منتشر شدهی از آسیب پذیریهای برنامههای وب ایرانی را بررسی میکنم، این مورد در صدر آنها قرار دارد!
علت اینجا است که عموما برنامه نویسها، برنامههای وب را در یک تک سشن باز شدهی توسط مرورگر خود آزمایش میکنند و در این حالت، همه چیز خوب است و اعمال آن به ترتیب پیش میروند. اما فراموش میکنند که میتوان قسمتهای مختلف برنامههای وب را به صورت همزمان، موازی و چندباره نیز اجرا کرد؛ حتی اگر آن قسمت متعلق به یک کاربر باشد.
سؤال: آیا استفاده تراکنشها این مشکل را حل نمیکنند؟!
عموما برنامه نویسها تصور میکنند که میتوانند تمام اینگونه مشکلات را با تراکنشها حل کنند:
همانطور که مشاهده میکنید، اینبار هرچند هر دو عملیات خرید داخل BEGIN TRAN و COMMIT TRAN قرار گرفتهاند، اما ... مشکل همزمانی هنوز پابرجا است! چون نوع پیشفرض تراکنش مورد استفاده، READ COMMITTED isolation level است و عدم دقت به آن ممکن است این تصور را ایجاد کند که با تعریف تراکنشها، تمام مشکلات همزمانی برطرف میشوند.
راهحلهای پیشنهادی جهت حل مشکل همزمانی عملیات read/update
برای حل مشکلات مرتبط با race condition و همزمانی درخواستهای read/update، میتوان از یکی از روشهای زیر استفاده کرد:
الف) بجای اینکه یکبار کوئری read و یکبار کوئری update به صورت جداگانه صادر شوند، فقط یکبار کوئری update داشته باشیم.
ب) پیاده سازی Row level locking؛ در صورت پشتیبانی بانک اطلاعاتی مورد استفاده از آن
ج) استفاده از تراکنشهایی از نوع SERIALIZABLE
د) پیاده سازی optimistic locking
این موارد را در ادامه با توضیحات بیشتری بررسی میکنیم.
الف) پرهیز از خواندن و به روز رسانی جداگانه
بجای اینکه مانند اعمال فوق، یکبار select داشته باشیم و یکبار update، بهتر است فقط یک دستور update بکارگرفته شود:
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
اینبار با خلاصه شدن دو دستور select و update به یک دستور update، دیگر پس از دو خرید همزمان، 100 واحد گم شده مشاهده نمیشود (!) و موجودی نهایی صحیح است.
ب) پیاده سازی Row level locking
همیشه امکان تغییر عملیات مورد نیاز، به سادگی حالت الف نیست. در یک چنین حالتهایی جهت حداقل شدن تغییرات مورد نیاز، میتوان از row level locking استفاده کرد:
WAITFOR TIME '13:47:00'; SET NOCOUNT, XACT_ABORT ON; BEGIN TRAN; DECLARE @amount INT; SET @amount = ( SELECT balance FROM accounts WITH (UPDLOCK, HOLDLOCK) WHERE user_id = 1 ); SELECT @amount as 'initial user''s balance' UPDATE accounts SET balance = @amount - 100 WHERE user_id = 1; SELECT balance as 'user''s balance after shopping 1' FROM accounts WHERE user_id = 1; COMMIT TRAN;
در اینجا اضافه شدن WITH (UPDLOCK, HOLDLOCK) را به Select تعریف شده، مشاهده میکنید که به آنها locking hints هم گفته میشود و داخل BEGIN TRAN و COMMIT TRAN عمل میکنند (که نوع پیشفرض آن READ COMMITTED isolation level است). کار UPDLOCK، تبدیل shared lock پیشفرض، به update lock است و کار HOLDLOCK، نگه داشتن قفل صورت گرفته تا پایان کار تراکنش تعریف شدهاست.
با این تغییرات، هر تراکنش همزمان دیگری، تا زمانیکه قفل صورت گرفتهی بر روی ردیف select، رها نشود (یعنی تا زمانیکه تراکنش قفل کننده، به COMMIT TRAN برسد)، نمیتواند آنرا تغییر دهد. به همین جهت است که در تصویر فوق، هرچند هر دو عملیات همزمان اجرا شدهاند، اما یکی موجودی ابتدایی 300 را میبیند و دیگری پس از صبر کردن تا پایان تراکنش و رها شدن قفل، موجودی تغییر یافتهی جدیدی را مشاهده کرده و از آن استفاده میکند. به این ترتیب دیگر 100 واحدی که در اولین تصویر این مطلب مشاهده کردید، گم نشدهاست.
ج) استفاده از تراکنشهایی از نوع SERIALIZABLE
بجای استفاده از روش row level locking یاد شده، روش دیگری را که میتوان استفاده کرد، تغییر نوع پیشفرض تراکنش مورد استفادهاست. برای مثال اگر از یک SERIALIZABLE transaction استفاده کنیم؛ یعنی SET TRANSACTION ISOLATION LEVEL SERIALIZABLE را در ابتدای کار ذکر کنیم و برای مثال دو تراکنش همزمان را اجرا کنیم، اگر در تراکنش اول اطلاعاتی خوانده شود، در هیچ تراکنش دیگری نمیتوان این اطلاعات خوانده شده را تا پایان کار تراکنش اول، تغییر داد:
د) پیاده سازی optimistic locking
پیاده سازی optimistic locking و یا Optimistic concurrency control عموما در سمت برنامه رخ میدهد و توسط ORMها زیاد مورد استفاده قرار میگیرد؛ مانند اضافه کردن ستون اضافی version و یا timestamp به جداول تعریف شده. در این حالت تمام updateها به همراه یک where اضافی هستند تا بررسی کنند که آیا version دریافتی در حین خواندن ردیف در حال به روز رسانی، تغییر کردهاست یا خیر؟ اگر تغییر کردهاست، تراکنش را با خطایی خاتمه خواهند داد. این روش برخلاف حالتهای ب و ج، حتی خارج از یک تراکنش نیز کار میکند و مشکلات قفل کردن طولانی مدت رکوردها توسط آنها را به همراه ندارد.
J (J language) is a high-level, general-purpose, high-performance programming language. J is portable and runs on 32/64-bit Windows/Linux/Mac as well as iOS, Android, and other platforms. J source (required only if Jsoftware binaries don't meet your requirements) is available under both commercial and GPL 3 license. J systems can be installed and distributed for free.
J systems have:
- an integrated development environment
- standard libraries, utilities, and packages
- console, browser, and Qt front ends
- interfaces with other programming languages and applications
- integrated graphics
- memory mapped files for high performance data applications
- Jd
نکته:
برای ایجاد یک پروژهی جدید مایکروسافت Web Application را به شما پیشنهاد میدهد. هرچند در این مبحث، مطالبی را مبنی بر فواید Web Site معرفی خواهد کرد، ولی اکثر توسعه دهندگان وب که Web Site را برگزیده اند سرانجام مضراتی از آن را مییابند که سنگینی آن بیشتر از فوایدش است. برای مثال تمامی خصیصههای (feature فیچر) ASP.net لزومآ برای وب سایت در دسترس نخواهند بود؛ مثلآ از ویژوال استودیوی 2012 به بعد، ابزاری برای تولید پروژههای وب وجود دارد که فقط برای Web Application در اختیار خواهد بود (برای کسب اطلاعات بیشتر میتوانید مطلب Creating an ASP.net Web Project in Visual Studio را مطالعه نمایید).
سناریو :
سناریویی که مبنی برا انتخاب Web Application میباشد به شرح زیر است:
· شما نیاز به استفاده از Edit And Continue در دیباگر ویژوال استودیو دارید.
· تمامی کدها، فایلها و کلاسهایی که با صفحات ASP.net مرتبط هستند، برای تست بصورت واحد و یکپارچه در نظر گرفته میشوند.
· شما برای کلاسهایی که وابسته به صفحات هستند و همچنین برای کنترلها و کلاسهای منحصر آن باید ارجاع داشته باشید.
· وابستگی در حالتی که چندین پروژهی مرتبط به هم را دارید توسط شما مشخص میشود.
· برای کل سایت در هنگام کامپایل فقط یک اسمبلی ساخته میشود.
· کنترل نام اسمبلیها و همچنین شمارهی ورژن ایجاد شدهی برای پروژه در دست شماست.
· برای کامپایل پروژه میتوانید MSBuild و یا Team Build را انتخاب کنید؛ برای مثال میتوانید مراحل Prebuild یا Postbuild را مشخص کنید.
· نیازی به قرار دادن سورس برنامه روی سرور نیست.
سناریویی که مبنی برا انتخاب Web Site میباشد به شرح زیر است:
· یک پروژه در بر دارندهی کدهای #C و هم کدهای Visual Basic میباشد ( درحالیکه بصورت پیشفرض در Web Application فایل پروژه بر مبنای زبان برنامهی شما کامپایل میشود، هرچند میتوان این حالت پیشفرض را تغییر داد؛ ولی این امر میتواند اندکی مشکل باشد).
· شما میتوانید سایت ایجاد شده را بصورت Real Time توسط FTP باز نموده و آپدیت نمایید.
· برای توزیع (deploy) پروژه مجبور به کامپایل صریح آن نیستید.
· اگر پروژه را کامپایل نمایید کامپایلر به ازای هر صفحه و یا هر پوشه، یک فایل اسمبلی جداگانه خواهد ساخت.
· برای تغییر یک فایل به تنهایی میتوانید فقط آنرا تغییر داده و بر روی سرور قرار دهید.
· حتی بعد از کامپایل هم میتوانید صفحات ASP.net را بدون نیاز به کامپایل دوبارهی کل سایت تغییر داده و جایگزین نمایید.
· سورس کامل پروژه برای اجرا باید روی سرور قرار گیرد.
تفاوتها در یک نگاه:
زمینه | پروژههای Web Application | پروژههای Web Site |
ساختار فایل پروژه | فایل برنامه (.csproj / vbproj) دربردارنده اطلاعاتی از جمله لیست فایلها و رفرنسها پروژه به پروژه دیگر خواهد بود. | هیچ فایل برنامه ای وجود ندارد و تمامی فایل هایی که داخل پوشه میباشند جزو فایلهای سایت شناخته میشوند. |
کامپایل | · شما پروژه را در سیستم خود کامپایل میکنید. · بصورت پیشفرض کامپایل کدها در یک اسمبلی قرار میگیرد. |
· سورس کدها بصورت اتوماتیک در سرور توسط Asp.net با اولین درخواست کامپایل میشوند. (البته شما میتوانید کامپایل را در سیستم خود نیز انجام دهید) · بصورت پیشفرض کامپایل برای هر کلاس یک اسمبلی جدا میسازد. |
فضاهای نام | Namespaceها بصورت صریح در صفحات و کلاسها و کنترلها افزوده میشود. | هیچ namespace ای بصورت پیشفرض اضافه نمیشود (شما میتوانید بصورت دستی آنها را اضافه کنید) |
توزیع | اسمبلی تولید شده در مرحله کامپایل را روی سرور قرار میدهید اکثر مراحل کامپایل توسط ابزارهای ارائه شده ویژوال استودیو انجام میشود. | کل سورس پروژه روی سرور قرار میگیرد. اکثر مراحل کامپایل توسط ابزارهای ارائه شده ویژوال استودیو انجام میشود. |
ساختار فایل پروژه:
پروژههای Web Application از فایل پروژه ویژوال استودیو ( .csproj / .vbproj ) برای نگهداری اطلاعات پروژه استفاده میکنند. با این امکان میتوان فایلهایی را که در پروژه دخیل هستند و یا باید کامپایل شوند، به تفکیک مشخص کرد.
در مورد Web Site تمامی فایلهایی که در داخل پوشهی برنامه قرار دارند، به صورت پیش فرض جزیی از برنامه تلقی شده و کامپایل خواهند شد و برای اینکه فایلی را بخواهید مستثنا کنید یا باید آنرا حذف کنید و یا پسوند آنرا به نامی که توسط سرور IIS قابل شناسایی نیست تغییر دهید.
فایدهی فایل پروژه یعنی همان ( .csproj / .vbproj ) در Web Application :
میتوان فایلی را به طور موقت از برنامه حذف کرد، بدون نگرانی از آنکه فایل بصورت کلی حذف شود. چرا که فایل در ساختار برنامه باقیست. برای مثال اگر صفحهای برای توزیع آماده نیست، میتوانید به راحتی آنرا از برنامه خارج کنید ( Exclude ) و برنامه را کامپایل نمایید و بعد از اینکه این صفحه هم آماده شد، دوباره آن را وارد پروژه نمایید ( include ) که اهمیت این امر در مواردی که از برنامههای کنترل سورس استفاده میکنید، دوچندان میشود.
فایدهی عدم استفاده از فایل پروژهی برنامه در Web Site :
شما مجبور به کنترل و شخصی سازی ساختار فایل برنامه در ویژوال استودیو نیستید و به راحتی هر فایل یا صفحهای را که میخواهید، با کپی کردن به پوشه و یا حذف کردن از آن توسط فایل اکسپلورر انجام میدهید.
کامپایل:
برای برنامههای Web Application شما بصورت معمول پروژه را Build مینمایید و تمامی کدهای صفحات و همچنین کلاسها به صورت یک فایل اسمبلی در پوشهی bin ذخیره میگردد.
برای Web Site شما مجبور به کامپایل دستی پروژه نیستید و میتوانید از Batch-Compile استفاده کنید و همچنین به ازای هر صفحه و کلاسریال شما یک فایل اسمبلی خواهید داشت.
مزایای کامپایل در Web Application :
· میتوانید از MSBuild استفاده کنید.
· میتوانید خصیصههای اسمبلی، از جمله نام و ورژن را به راحتی مدیریت نمایید.
· کامپایل قبل از توزیع برنامه این مزیت را دارد که کاربران مجبور نیستند منتظر کامپایل برنامه در سرور باشند.
· مدیریت دقیقی بر روی فایلها و ساختار برنامه و همچنین کلاسها و ارجاعات خواهید داشت.
مزایای کامپایل در Web Site :
· میتوانید هر صفحهای را که نیاز دارید بدون در نظر گرفتن آماده شدن دیگر صفحات تست و اجرا نمایید.
· آپدیت و جایگزینی فایلها به راحتی صورت میگیرد؛ چرا که اسمبلی تمام فایلها بصورت منحصر همان صفحه ایجاد خواهد شد.
· ایجاد شدن چند اسمبلی میتواند در برخی پروژهها به نفع برنامه بوده و performance را بالا ببرد. برای مثال در حالتیکه یک سایت با صفحات زیاد دارید و برخی صفحات به نسبت دیگر صفحات خیلی کمتر درخواست میشوند.
نکته:
هیچ فرقی بین Web Application , و web Site از نظر performance وجود ندارد مگر درحالت ذکر شده در بالا و در سایتهای خیلی بزرگ.
توزیع : ( Deployment )
در web Site کل فایلهای پروژه را بر روی سرور قرار میدهید؛ درحالی که در Web Application فایلهای برنامه بصورت اسمبلیها ( .dll ) روی سرور قرار میگیرند. همین امر میتواند در برخی حالتها مثلآ زمانی که از هاست share شده استفاده میکنید، خیال شما را از بابت سورس برنامه مطمئن سازد.
برای Web Site نیز این مزیت وجود دارد که برای انجام تغییرات کوچک مجبور به کامپایل و آپلود دوبارهی کل پروژه نیستید.
ماخذ
- موقعی که کلاینت درخواست خود را مبنی بر یکی از منابع سرور ارسال میکند، Http.sys این درخواست را میگیرد.
- http.sys با WAS تماس گرفته و درخواست میکند تا اطلاعات پیکربندی یا تنظیمات IIS را برای نحوهی برخورد با درخواست، برایش بفرستد.
- WAS هم اطلاعات پیکربندی شده را از محل ذخیره دادهها که applicationHost.config هست، میخواند.
- WWW Service که یک آداپتور برای Http.sys هست، اطلاعات را از WAS دریافت میکند. این اطلاعات شامل پیکربندی application pool و سایت میباشد.
- WWW Service اطلاعات را برای Http.sys میفرستد.
- WAS یک پروسه کارگر را در application pool ایجاد میکند تا درخواست رسیده مورد پردازش قرار بگیرد.
- پروسههای کارگر درخواست را پردازش کرده و خروجی یا response مورد نظر را تولید میکنند.
- Http.sys نتیجه را دریافت و برای کلاینت میفرستد.
حال بیایید ببینیم موقعی که درخواست وارد پروسهی کارگر میشود چه اتفاقی میافتد؟
در پروسههای کارگر، یک درخواست از مراحل لیست شده ای به ترتیب عبور میکند. در هسته وب سرور، رویدادهایی را فراخوانی میکند که در هر رویداد چندین ماژول native برای کارهایی چون authentication یا events logs دارد و در صورتیکه درخواستی نیاز به یک ماژول مدیریت شده CLR داشته باشد، از ماژول native managedEngine کمک گرفته و یک app domain را ایجاد میکند تا ماژولهای مدیریت شده، عملیات لازم خودشان را انجام دهند. مثل authentication form و ...
موقعی هم که درخواست، از تمامی این رویدادها عبور کند، response برای http.sys ارسال میشود تا به کلاینت بازگشت داده شود. شکل زیر نحوه ورود یک درخواست به پروسه کارگر را نشان میدهد.
از نسخه 7 به بعد، IIS از یک معماری ماژولار استفاده میکند و این ویژگی، سه فایده دارد:
- Componentization یا کامپوننت سازی
- Extensibility یا توسعه پذیری یا قابل گشترش
- ASP.NET Integration
Componentization
- باعث کاهش attack surface میشود که در نتیجه امنیت سیستم را بالا میبرد. با ویژگی حذف کامپوننتها شما میتوانید ویژگیهای غیرقابل استفاده IIS را حذف کنید تا وروردیهای سیستم کاهش یابد. پس با کاهش ویژگیهایی که از آن هرگز استفاده نخواهید کرد، مدخل ورود هکر را از بین برده تا امنیت سرور بالاتر برود.
- افزایش کارآیی و کاهش مصرف حافظه. با حذف ویژگیهایی که هرگز استفاده نمیکنید، در مصرف حافظه و بهینه استفاده شدن منابع سرور صرفه جویی کنید.
- با وجود ویژگی افزودن و جایگزینی کامپوننتها، ناخودآگاه ذهن ما به سمت کاستوم سازی یا خصوصی سازی کشیده میشود. با این کار شما به راحتی یک custom server ایجاد میکنید که این سرور بر اساس علایق شما کارش را انجام میدهد و به راحتی امکاناتی چون افزودن third partyها را به توسعه دهنده میدهد.
Extensibility
- قدرت بخشی به برنامههای وب. امکانات و قدرتی که میتواند در این حالت به برنامههای در حال اجرا داد به مراتب بیشتر از استفاده از لایههای داخلی خود برنامه هست. برای اینکار شما میتوانید کدهای خود را با ASP.Net نوشته یا از کدهای native چون ++C استفاده کنید.
- تجربهای از توسعه پذیری سادهتر و راحت تر
- استفاده از قدرت و تمامی امکانات را به شما میدهد و میتوانید تمام دستورات را برای همه منابع حتی فایلهای ایستا، CGI ، ASP و دیگر منابع اجرا کنید.
ASP.NET Integration