استفاده از Castle ActiveRecord در پروژه های تحت وب

در سری آموزشی Castle ActiveRecord با یک پروژه مثال تحت ویندوز پیش رفتیم و همانطور که مشاهده کردید نکته خاصی در مورد نوع پروژه که تحت ویندوز بود وجود نداشت. اما استفاده از یک ORM در پروژه های تحت وب به علت ماهیت خاص وب، استراتژی خاصی را نیز می طلبد. در یک پروژه تحت وب، ممکن است کاربران زیادی وجود داشته باشند که هر کدام درخواست هایی را برای برنامه ما می فرستند که اکثر این درخواست ها مربوط به دسترسی به داده ها باشند.

ساده ترین روش برای استفاده از Castle ActiveRecord در یک برنامه تحت وب اضافه کردن خاصیت isWeb=»true» در بخش کانفیگ CAR در فایل web.config است. این کار باعث می شود تا CAR مجبور به استفاده از استراتژی متفاوتی برای نگهداری نمونه های Sessionهای NHibernate بکار بگیرد. در اینجا قصد نوشتن توضیحات اضافه را ندارم، بهتر است نمونه کانفیگ ActiveRecord برای یک برنامه تحت وب را مشاهده کنید :

<activerecord
 isWeb="true"
 isDebug="true"
 threadinfotype="Castle.ActiveRecord.Framework.Scopes.HybridWebThreadScopeInfo, Castle.ActiveRecord">
 <config>
 <add key="connection.driver_class"
 value="NHibernate.Driver.SqlClientDriver"/>
 <add key="dialect"
 value="NHibernate.Dialect.MsSql2008Dialect"/>
 <add key="connection.provider"
 value="NHibernate.Connection.DriverConnectionProvider"/>
 <add key="connection.connection_string"
 value="Data Source=.\SQLEXPRESS;Initial Catalog=RegisterUsers;Integrated Security=True;Pooling=False"/>
 <add key="proxyfactory.factory_class"
 value="NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle"/>
 <add key="SessionScopeWebModule"
 value="Castle.ActiveRecord.Framework.SessionScopeWebModule"
 name="SessionScopeWebModule"
 type="Castle.ActiveRecord.Framework.SessionScopeWebModule"/>
 </config>
 </activerecord>
 

برای اینکه بتوانیم از الگوی Session per Request استفاده کنیم (همانطور که برای NHibernate پیاده سازی می کنند) باید یک کلاس با کدهای زیر به پروژه خودمان اضافه کنیم :

public class SessionModule : HttpApplication
{
 public SessionModule()
 {
 BeginRequest += new EventHandler(OnBeginRequest);
 EndRequest += new EventHandler(OnEndRequest);
 }

 protected void Application_Start(Object sender, EventArgs e)
 {
 BeginRequest += new EventHandler(OnBeginRequest);
 EndRequest += new EventHandler(OnEndRequest);
 }

 public void OnBeginRequest(object sender, EventArgs e)
 {
 HttpContext.Current.Items.Add("ar.sessionscope", new SessionScope());
 }

 public void OnEndRequest(object sender, EventArgs e)
 {
 try
 {
 SessionScope scope = HttpContext.Current.Items["ar.sessionscope"] as SessionScope;

 if (scope != null)
 {
 scope.Dispose();
 }
 }
 catch (Exception ex)
 {
 HttpContext.Current.Trace.Warn("Error", "EndRequest: " + ex.Message, ex);
 }
 }
}

و البته خطوط زیر را به بخش system.web فایل web.config اضافه کنیم :

<httpModules>
 <add name="ar.sessionscope"
 type="Castle.ActiveRecord.Framework.SessionScopeWebModule, Castle.ActiveRecord"/>
</httpModules>

هنوز کارمان تمام نشده. باید ActiveRecord را در فقط برای اولین اجرای برنامه راه اندازی کنیم. اگر یادتان باشد در یک برنامه تحت ویندوز، راه اندازه اولیه ActiveRecord را در هنگام اجرای برنامه در متد main فایل Program.cs می نوشتیم. در یک برنامه تحت وب این کار را باید در Application_Start انجام دهیم. این متد در یک برنامه تحت وب فقط یکبار و در زمان اجرای اولیه صدا زده می شود و بهترین مکان برای راه اندازی اولیه فریم ورک ActiveRecord است. این متد زمانی که یک فایل Global.asax به پروژه خود اضافه می کنید ایجاد می شود. بدنه این متد برای راه اندازی اولیه ActiveRecord چیزی شبیه کدهای زیر می تواند باشد :

protected void Application_Start(object sender, EventArgs e)
{
 IConfigurationSource configSource = ConfigurationManager.GetSection("activerecord")
 as IConfigurationSource;
 ActiveRecordStarter.Initialize(typeof(User).Assembly, configSource);
}

برای درک بهتر مطلب می توانید پروژه مثال این مطلب را از اینجا دریافت کنید.

Advertisements

استفاده از jQuery UI Dialog در ASP.NET

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

خوشبختانه کتابخانه jQuery UI دارای یک کامپوننت Dialog مناسب برای استفاده در محیط وب است که با تمامی مرورگرهای مدرن سازگاری کامل دارد و به علت اینکه بر روی کتابخانه jQuery کار می کند در تمام پلت فرم های توسعه وب قابل استفاده است.

برای استفاده از این Dialog در یک صفحه ASP.NET باید کتابخانه های jQuery و jQuery UI را دانلود کنید و در صفحه مورد نظر خود به آن ها ارجاع اسکریپتی بدهید. در این مطلب یک مثال ساده در مورد استفاده از jQuery UI Dialog  را توضیح خواهیم داد. پروژه مثال این مطلب را از اینجا دریافت کنید. قصد ندارم تمام کدهای نوشته شده در این پروژه مثال را توضیح بدهم، فقط نکات مهم مربوط به موضوع بحث را خواهید خواند. خواندن سورس کد و مشاهده مثال بهتر از توضیحات متنی به شما کمک می کند.

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

jQuery UI Dialog Exampleدکمه Cancel دیالوگ را می بندد و دکمه OK برچسب های روی صفحه را با مقادیر تکست باکس ها هماهنگ می کند. jQuery UI Dialog در حالت معمول بعد از تگ form در ASP.NET رندر می شود که این باعث می شود تا دکمه های موجود در دیالوگ هیچ Post Backی به صفحه نداشته باشند که البته این مشکل به راحتی حل می شود. برای اینکه دکمه های موجود در دیالوگ بدون رفرش شدن صفحه کار خود را انجام بدهند، محتویات دیالوگ را درون یک UpdatePanel قرار می دهیم. مهمترین کدهایی که در مورد آن ها بحث می کنیم، کدهای جاوا اسکریپت زیر هستند :

<script type="text/javascript">
 $(document).ready(function () {
 $('#divValues').dialog({
 autoOpen: false,
 draggable: true,
 maxHeight: 440,
 width: 400,
 modal: true,
 title: "Enter values",
 open: function (type, data) {
 $(this).parent().appendTo("form");
 }
 });
 });

 function openDialog(id) {
 $('#' + id).dialog("open");
 }

 function closeDialog(id) {
 $('#' + id).dialog("close");
 }

 </script>

در واقع این کدهای بالا هستند که دیالوگ jQuery را می سازند و آن را باز و بسته می کنند. علامت $ که در ابتدای کد بکار رفته نشان دهنده این است که در حال استفاده از توابع کتابخانه jQuery هستیم. تابع اول دیالوگ را با خصوصیات مشخص شده مقدار دهی می کند. لیست کامل این خصوصیات را می توانید اینجا مشاهده کنید و بر اساس نیاز خود تغییر دهید. بعد از اجرای برنامه، تا زمانی که تابع openDialog صدا زده نشود، دیالوگ ما هم نشان داده نخواهد شد و در واقع jQuery آن را از دید کاربر مخفی نگه خواهد داشت. محتویات یک دیالوگ باید در یک div قرار بگیرند که نام آن باید برای dialog مشخص شود. نکته ای که شما به عنوان یک برنامه نویس ASP.NET در این مورد باید بدانید این است که حتماً UpdatePanel دیالوگ را داخل این div قرار دهید تا کدهایتان به درستی کار کند.

ویژگی خوب کتابخانه jQuery UI سبک بودن و سازگار بودن با اکثر مرورگرهای مدرن امروزی است. برای تغییر ظاهر دیالوگ هم دست شما بسیار باز است و می توانید از تم های آماده jQuery UI استفاده کنید و یا حتی استایل خود را برای آن بسازید.

دریافت پروژه مثال

مزیت های ASP.NET MVC نسبت به ASP.NET WebForms

ASP.NET MVC یک فریم ورک کاملاً جدید برای ساختن اپلیکیشن های ASP.NET است که با هدف جداسازی شفاف لایه های برنامه و قابلیت تست پذیری بالا بوجود آمده است. برنامه نویسان دات نت با استفاده از ASP.NET MVC می توانند رفتار Stateless وب را درک کنند و بر روی کدهای HTML خروجی صفحات خود کنترل کامل داشته باشند. در فریم ورک ASP.NET MVC بر خلاف ASP.NET WebFroms آدرس های صفحات وب سایت به فایل های فیزیکی aspx وابسته نیستند. در این مطلب اشاره ای کوتاه خواهیم داشت به مزیت های کلی ASP.NET MVC نسبت به ASP.NET WebForms :

1) Separation of Concern : فریم ورک ASP.NET MVC شما را مجبور می کند تا یک جداسازی شفاف از قسمت های مهم اپلیکیشن خود داشته باشید. شما باید کدهای مربوط به دسترسی به داده ها را در قسمت Model و کدهای مربوط به رابط کاربری را در قسمت View بنویسید و برای ایجاد ارتباط میان این دو لایه از Controllerها استفاده کنید. با این جداسازی شفاف، پیچیدگی های پروژه کمتر شده و نگهداری پروژه در درازمدت و انجام تغییرات بر روی آن آسان تر می شود.

2) کنترل کامل بر روی HTML خروجی : با استفاده از ASP.NET MVC شما می توانید درخواست های کاربر را پردازش کنید و خروجی مناسب HTML را به مرورگر بفرستید. کدهای HTML خروجی شما کاملاً تمیز هستند و از کدهای عجیب و غریبی که ASP.NET WebForms برای شما ایجاد می کند خبری نیست!

3) ایجاد URLهای RESTful : با کامپوننت های URL Mapping در این فریم ورک می توانید URLهایی بدون پسوند، واضح و قابل جستجو بسازید. این URLها از قوانین نام گذاری REST پشتیبانی می کنند و از نظر SEO در موتورهای جستجوگر امتیاز خوبی می گیرند.

4) قابلیت تست پذیری : یکی از اهداف مهم طراحی فریم ورک ASP.NET MVC قابلیت تست پذیری بوده است. به علت جدا سازی شفاف میان کدهای منطق برنامه و کدهای مربوط به رابط کاربری، تست کردن اجزای مختلف وب اپلیکیشن های ASP.NET MVC آسان است. ASP.NET MVC با تمام فریم ورک های Testing که برای دات نت ساخته شده اند کار می کند.

5) عدم استفاده از PostBack و ViewState : در ASP.NET MVC خبری از فرم های تحت سرور (یا همان runat=»server» معروف) نیست. شما رویدادی به نام PostBack ندارید و حالت کنترل های شما با استفاده از ViewState حفظ نخواهد شد! این یک مزیت است زیرا باعث ایجاد خروجی واضح تر و صفحات سبک تر می شود.

6) آسان تر کردن کار تیمی : به علت جداسازی واضح میان قسمت های مختلف پروژه و قابلیت تست آسان، کار کردن به صورت تیمی را آسان تر می کند. هر یک از اعضای تیم بر اساس نوع تخصص خودشان می توانند قسمت هایی از پروژه (Model یا View) را طراحی کنند و با استفاده از Controllerها ارتباط میان لایه ها را بسازند.

7) اجبار در کدنویسی مبتنی بر الگوی طراحی : ASP.NET MVC توسعه دهندگان را مجبور به رعایت الگوی طراحی MVC می کند. این اجبار باعث ایجاد یک وب اپلیکیشن با ساختار استاندارد می شود که نگهداری و توسعه آن در دراز مدت آسان خواهد بود.

8 ) کدباز بودن : سورس کد فریم ورک ASP.NET MVC با مجوز Ms-pl که یک مجوز اوپن سورس از شرکت مایکروسافت است، منتشر می شود. کدباز بودن این فریم ورک باعث شده تا شرکت مایکروسافت فیدبک های دقیق تر و سودمندتری از جامعه توسعه دهندگان ASP.NET دریافت کند ودر نتیجه باعث پیشرفت سریعتر آن شده است.

9) سرعت بیشتر در بارگذاری صفحات : همانطور که اشاره شده، با حذف کنترل های تحت سرور، PostBack و ViewState که باعث ایجاد کدهای اضافی جاوا اسکریپت می شود، سرعت لود صفحات وب در ASP.NET MVC به مراتب بیشتر از وب فرم هاست.

farasun.wordpress.com

Subcribe to Farasun feedمشترک فراسان شويد

farasun.wordpress.com

WebMatrix توسعه وب را آسان تر می کند

مایکروسافت به تازگی ابزار جدیدی برای توسعه دهندگان وب به نام WebMatrix ارائه کرده است که سفارشی کردن وب اپلیکیشن های موجود یا ساخت یک وب سایت جدید را با امکانات خوب و راه حل های ساده، آسان می کند. این ابزار سبک به افراد کمک می کند تا به راحتی برنامه نویسی با ASP.NET را شروع کنند و خیلی زود در آن پیشرفت کنند. WebMatrix شامل ابزارهای مهم مایکروسافت برای توسعه وب  است. این ابزارها شامل :

  • IIS Developer Express : یک وب سرور سبک و رایگان که با تمام نسخه های ویندوز و نسخه کامل IIS سازگار است.
  • ASP.NET : یک فریم ورک رایگان شامل کلاس های پایه برای توسعه وب.
  • SQL Server Compact : یک نسخه embedded و بسیار سبک و رایگان از SQL Server که بر اساس فایل کار می کند.
  • Razor Syntax : یک View Engine جدید و ساده برای ASP.NET که کدهای سمت سرور سی شارپ یا ویژوال بیسیک را با کدهای HTML ترکیب می کند (مانند  PHP) و یادگیری آن ساده و لذت بخش است.

وب ماتریکس

WebMatrix با استفاده از تکنولوژی های بالا، یک محیط مجتمع ساده و در عین حال قدرتمند برای ساخت وب سایت های داینامیک و مطابق با استاندرادهای جدید به ساده ترین شکل ممکن در اختیار کاربر خود قرار می دهد. شما با وب ماتریکس می توانید یک وب اپلیکیشن اوپن سورس مثل BlogEngine.NET را انتخاب کنید، آن را بر اساس نیاز خود سفارشی کنید و به راحتی آن را بر روی هاست خود پابلیش کنید. پروسه استفاده از وب اپلیکیشن های اوپن سورس در اینترنت با WebMatrix بسیار آسان خواهد بود. شما با وب ماتریکس حتی قادر به انتخاب CMSهای نوشته شده با PHP مثل وردپرس، جوملا و Drupal نیز هستید و حتی می توانید آن ها را با ابزارهای موجود در وب ماتریکس توسعه داده و از همانجا بر روی هاست خود پابلیش کنید.

برای شروع شما می توانید WebMatrix را از اینجا دانلود کنید. اگر دات نت فریم ورک 4.0 را نصب نداشته باشید، کمی حجم دانلود وب ماتریکس بالا خواهد بود، در غیر این صورت با دانلود 15 تا 20 مگابایت WebMatrix را در اختیار خواهید داشت. پس از اجرای آن با یک محیط ساده مواجه خواهید شد که فقط 4 انتخاب را پیش روی شما می گذارد. می توانید یک سایت جدید خالی ایجاد کنید یا از وب اپلیکیشن های موجود در گالری مایکروسافت برای شروع استفاده کنید. هر طور که شروع کنید، وب ماتریکس به شما اجازه مدیریت بر صفحات سایت و تغییر آن ها، مدیریت بر فایل های وب سایت، مدیریت بر دیتابیس سایت و در نهایت پابلیش سایت بر روی سرور را می دهد.

Microsoft Web Gallery

همانطور که اشاره شد، شما در وب ماتریکس می توانید از سینتاکس Razor برای نوشتن کدهای سی شارپ و ویژوال بیسیک در میان کدهای HTML بهر ببرید. یادگیری سینتاکس Razor خیلی آسان است. شما کدهای خود را با یک علامت @ آغاز می کنید و بلاک کد خود را در سی شارپ با { و } محصور می کنید. هر جا که از علامت @ استفاده کنید یعنی می خواهید یک کد سمت سرور را بنویسید. از متغیرها بدون تعیین نوع آن ها استفاده می کنید، سپس ASP.NET خودش بهترین تصمیم را برای تعیین نوع متغیر بر اساس مقداری که درون آن ذخیره می شود خواهد گرفت. صفحاتی که دارای کد Razor هستند دارای پسوندهای مخصوص cshtml یا vbhtml خواهند بود. سینتاکس Razor تمام قدرت ASP.NET را با قواعدی آسان تر در اختیار مبتدیان قرار می دهد، اما حرفه ای ها نیز می توانند به بهترین شکل برای بالا بردن کارایی خود از آن استفاده کنند. یک کد بسیار ساده با سینتاکس Razor را ببینید :


<html>
<head>
<title>Razor Syntax Sample</title>
</head>
<body>

@{
var message = «Hello World.»;
var today = DateTime.Now.ToString();
}

<p>Message : @message</p>
<p>Today is : @today</p>
</body>
</html>

اینطور که پیداست مایکروسافت راه درستی را انتخاب کرده و باید منتظر تکنولوژی های جدیدتر و بهترش در زمینه توسعه وب باشیم. اینکه نظر مایکروسافت در این چند سال اخیر نسبت به نرم افزارهای اوپن سورس تغییرات مثبت زیادی داشته خیلی خوب و سازنده است. مایکروسافت نیز اهمیت استفاده از وب اپلیکیشن های اوپن سورس را در توسعه وب به خوبی می داند و به همین دلیل Microsoft Web Gallery را راه اندازی کرده و توسعه دهندگان را به جای باز تولید اپلیکیشن های تکراری به استفاده و توسعه وب اپلیکیشن های اوپن سورس موجود تشویق می کند. Web Platform Installer و WebMatrix دو ابزار مهم مایکروسافت در زمینه توسعه وب هستند که به صورت توکار از وب اپلیکیشن های اوپن سورس پشتیبانی می کنند و قادرند آن ها را دانلود، تنظیم و پابلیش کنند. تکنولوژی های تحت وب هرچه بازتر باشند بیشتر مورد تایید و مورد اعتماد توسعه دهندگان وب خواهند بود، این را مایکروسافت به خوبی می داند. بدون شک در آینده ای نه چندان دور از WebMatrix و Razor Syntax بیشتر خواهیم شنید.

منابع بیشتر در مورد WebMatrix

PHP برای برنامه نویسان ASP.NET – قسمت هشتم

قسمت اولقسمت دوم قسمت سوم قسمت چهارم قسمت پنجمقسمت ششم قسمت هفتم

شیء گرایی در PHP

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

class Human
{
private string _name;
public string Name;
public string Family;
public int Height;
public int Weight;
public int Age;

public Human()
{
Console.WriteLine("a Human Created.");
}
}

class Student: Human
{
public long ID { get; set; }
public string Grade;

public Student()
{
Console.WriteLine("a Student Created.");
}

public void DisplayInformations()
{
Console.WriteLine(this.ID.ToString());
Console.WriteLine(this.Name);
Console.WriteLine(this.Family);
Console.WriteLine(this.Age);
Console.WriteLine(this.Grade);
}

~Student()
{
Console.WriteLine("a Student Destroyed.");
}
}

اگر برنامه نویس سی شارپ باشید به راحتی منظور کدهای بالا را می فهمید. یک کلاس پایه به نام Human با چند فیلد و یک متد سازنده ساختیم، سپس یک کلاس به نام Student را از آن مشتق کردیم. کلاس فرزند نیز دارای چند فیلد، یک سازنده و یک متد برای چاپ مقادیر فیلدهایش است. حالا می خواهیم این دو کلاس را در PHP پیاده سازی کنیم.

<?php
class Human {
private $_name;
public $Name;
public $Family;
public $Height;
public $Weight;
public $Age;

function __construct() {
print "a Human Created.";
}
}

class Student extends Human {
public $ID;
public $Grade;

function __construct() {
parent::__construct();
print "a Student Created.";
}

function DisplayInformations() {
print $this->ID;
print $this->Name;
print $this->Family;
print $this->Age;
print $this->Grade;
}

function __destruct() {
print "a Student Destroyed.";
}
}
?>

همانطور که می بینید سینتاکس PHP برای تعریف یک کلاس شبیه به سی شارپ است. خب به هر حال هر دو از خانواده زبان C هستند! در PHP نیز شما می توانید از private, public و protected برای تعیین چگونگی دسترسی به متغیرها (فیلدها) و توابع استفاده کنید. هنگامی که هیچکدام از این ها را در خط تعریف متغیر یا تابع ذکر نکنید به صورت پیش فرض آن عضو به عنوان public در نظر گرفته خواهد شد. در PHP هر کلاس تشکیل شده از تعدادی متغیر و تابع و در صورت نیاز سازنده و مخرب. سازنده یا Constructor کلاس در سی شارپ متد همنام با خود کلاس است. همانطور که در مثال بالا مشاهده می کنید، هر دو کلاس متدی همنام با خودشان دارند که هنگام ساخته شدن در زمان اجرا صدا زده می شوند. در PHP نسخه های قبل از 5، تعریف سازنده کلاس به همین صورتی که در سی شارپ است، بود. در نسخه 5 شما باید تابعی به نام __construct() برای پیاده سازی سازنده کلاس تعریف کنید.

برای ارث بری از یک کلاس در PHP ازکلمه کلیدی extends به همان صورتی که در مثال مشاهده می کنید، استفاده می کنیم. این یعنی کلاس Student تمام خاصیت ها (در اینجا متغیرها) و توابع کلاس پدر خود یعنی کلاس Human را به علاوه متغیرها و توابعی که در بلاک خودش تعریف شده را دارد. برای اینکه هنگام ساخته شدن کلاس Student تابع سازنده کلاس پدرش Human نیز اجرا شود باید آن را به صورت parent::__construct() صدا بزنید. تابع مخرب در PHP نیز بوسیله نوشتن تابع __destruct() امکان پذیر است.

استفاده از کلاس

برای استفاده از یک کلاس به راحتی همانند سی شارپ ابتدا از آن بوسیله کلمه new نمونه سازی کنید و از توابع مورد نیاز خود استفاده کنید.

<?php
$objStudent = new Student();
$objStudent->Name = "Iman";
$objStudent->Family = "Nemati";
$objStudent->Age = "22";
$objStudent->DisplayInformations();
?>

هنگام new کردن یک کلاس، تابع __construct() آن کلاس اجرا می شود. برای دسترسی به اعضای public یک کلاس در PHP باید از عملگر <- بلافاصله پس از نام متغیر کلاس استفاده کنید.

اعضای Static

همانند سی شارپ، در PHP هم با نوشتن کلمه کلیدی static می توانید یک تابع یا یک متغیر را به عنوان عوض استاتیک معرفی کنید. تعریف یک متد یا یک خصوصیت به صورت استاتیک آن ها را بدون نیاز به ساخت یک نمونه از کلاس در خارج از کلاس، قابل دستیابی می کند. فقط برای استفاده از اعضای استاتیک یک کلاس به جای عملگر -> باید از عملگر :: استفاده کنید.

<?php
class Sample {
public static function StaticMethod() {
//Some Function
}
}

//
Sample::StaticMethod();
?>

در کدنویسی های معمولی PHP شاید نیازی به استفاده از کلاس ها پیدا نکنید اما برای حرفه ای تر شدن و بعدها برای استفاده از فریم ورک های PHP نیاز به داشتن دید شیء گرایی و نحوه تعریف و استفاده از کلاس ها خواهید داشت. خوشبختانه برنامه نویسان ASP.NET از نظر شیء گرایی دید نسبتاً مناسب و خوبی دارند، زیرا به صورت پیش فرض تمام برنامه های آن ها بر اساس کلاس ها و مفاهیم شیء گرایی توسعه داده می شوند. احتمالاً آموزش PHP برای برنامه نویسان ASP.NET را ادامه نخواهیم داد. از اول هم قرار نبود جلوتر از این برویم. نسخه PDF کامل تر این سری نوشته ها به زودی بر روی وبلاگ قرار خواهد گرفت. امیدوارم این نوشته ها برای شما مفید بوده باشند.

farasun.wordpress.com

مشترک فید فراسان شوید!

نکات امنیتی برای برنامه نویسان ASP.NET

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

در این مطلب کوتاه با نکاتی آشنا خواهید شد که اگر آن ها را بکار ببرید می توانید تا حدی امنیت وب اپلیکیشن های خود را تامین کنید.

ASP.NET Security Tips

1) داده های ورودی کاربران را اعتبارسنجی کنید

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

2) اطلاعات حساس را کد کنید

قانون دوم : هر اطلاعاتی را که فکر می کنید ممکن است از آن سوء استفاده شود را کد کنید. حتماً Username و Password کاربران را کد کرده و سپس ذخیره کنید. Hash کردن رمز عبور یکی از بهترین و مطمئن ترین راه ها برای تامین امنیت رمزعبور کاربران است. برای این کار در دات نت راه حل های خوبی وجود دارد. اطلاعات حساس دیگر مثل Connection String دیتابیس خود را حتماً Encrypt کنید. در ASP.NET توصیه شده است به جای اینکه رشته اتصال دیتابیس خود را در کدهای خود بنویسید، آن را به صورت جداگانه در فایل Web.config تعریف کنید. از آن جایی که فرمت این فایل XML است و امنیت پایینی دارد، شما باید تمام اطلاعات حساس این فایل از جمله Connection String را کد کرده و سپس ذخیره کنید.

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

3) اطلاعات تکنیکی را از دید کاربران مخفی کنید

در برنامه های ASP.NET هنگامی که خطایی رخ می دهد که توسط برنامه هندل نشده، تمام اطلاعات تکنیکی مربوط به خطای مذکور با ذکر جزئیات و حتی خطی از برنامه که خطا در آن اتفاق افتاده است توسط کاربران قابل مشاهده است. البته این تنظیمات پیش فرض ASP.NET برای زمان توسعه در Localhost و خطایابی مناسب است که هنگام پابلیش وب اپلیکیشن بر روی اینترنت یا اینترانت باید تغییر کند. متاسفانه برخی از برنامه نویسان ناشی هنگام توزیع وب اپلیکیشن خود همان فایل web.config روی لوکال هاست خود را بدون هیچ تغییری بر روی محیط اجرایی قرار می دهند. این گونه پیغام های خطای ASP.NET معمولاً اطلاعات مناسبی در مورد آسیب پذیری های یک وب سایت در اختیار یک هکر قرار می دهد. برای حل این مشکل شما باید تمام خطاهای ممکن را هندل کنید و مقدار ویژگی customErrors در فایل web.config را برابر RemoteOnly قرار دهید.

<customErrors mode=«RemoteOnly«></customErrors>

4) حالت دیباگ را غیرفعال کنید

هنگام توسعه یک وب اپلیکیشن در ASP.NET حالت Debug به صورت پیش فرض true است. شما باید پس از توسعه و هنگام آپلود وب اپلیکشن در یک هاست اینترنتی خاصیت debug در قسمت compilation فایل web.config را برابر false قرار دهید. این کار هم کارایی برنامه تحت وب شما را بالاتر می برد و هم از نشان دادن برخی از خطاها که باعث لو رفتن کدهای شما می شود جلوگیری می کند.

5) مواظب حملات SQL Injection باشید

این نوع حملات در اکثر وب سایت های اطلاعاتی مبتنی بر دیتابیس مرسوم است. به این صورت که کاربر/هکر یک کد SQL را به برنامه شما تزریق می کند و باعث ایجاد خرابکاری می شود. با وجود خطرناک بودن و جدی بودن این نوع حمله باز هم هستند برنامه نویسانی که به این مورد توجهی ندارند. به طور مثال در یک فرم لاگین نا امن که کوئری چک کردن Username و Password شبیه به کد زیر باشد، حمله SQL Injection به راحتی امکان پذیر است.

string query = «SELECT * FROM Users WHERE username='» +
txtUsername.Text + «‹ AND password='» + txtPassword.Text + «‹»;

در این موقعیت یک فرد نسبتاً باهوش با نوشتن رشته x› or username like %x در فیلد password به راحتی می تواند فرم لاگین شما را رد کرده و خود را به عنوان یک کاربر قانونی جا بزند. برای جلوگیری از این مشکل حتماً قانون اول را رعایت کنید و به جای استفاده از مقادیر تکست باکس ها به این صورت، از کلاس SqlParameter برای مقداردهی استفاده کنید. یکی از راه های دیگر برای جلوگیری از این حمله استفاده از ORMهایی مثل LINQ  to SQL است.

6) جلوگیری از حملات Cross-site Scripting

یکی از مرسوم ترین و در دسترس ترین نوع حملات به وب سایت هاست که فرد خرابکار سعی می کند اسکریپت مخربی را به وب اپلیکیشن شما تزریق کند. به طور مثال در فرم های ورود اطلاعات کاربر خرابکار می تواند به جای وارد کردن اطلاعات صحیح، کدهای جاوا اسکریپت مخرب را وارد کند. خوشبختانه ASP.NET به صورت پیش فرض دارای یک محافظ درخواست توکار است که در اکثر مواقع جلوی این حملات را می گیرد. اما باز هم نمی توان به صورت صد در صد به آن اطمینان کرد، چون راه هایی برای دور زدن آن نیز وجود دارد. بهتر است هنگام نمایش دادن داده های ورودی کاربر، ابتدا رشته مورد نظر را با Server.HtmlEncode به یک رشته امن HTML تبدیل کنید و سپس آن را نمایش دهید. در این صورت اگر حتی کاربر اسکریپت مخربی را با موفقیت به برنامه شما تزریق کرده باشد، آن اسکریپت اجرا نخواهد شد و فقط به صورت یک رشته به نمایش در خواهد آمد.

7) سیستم لاگین خود را امن بسازید

روش مرسوم برای پیاده سازی سیستم لاگین در وب، روش استفاده از Session است. Session متغیرهایی هستند که بر روی سرور به ازای هر کاربر لاگین شده ساخته می شوند و وب اپلیکیشن با چک کردن متوالی آن در هر صفحه هویت کاربر وارد شده را شناسایی می کند. یک Session معمولاً برای یک مدت زمان محدودی (مثلاً 20 دقیقه) اعتبار دارد و پس از آن کاربر دوباره باید به سیستم لاگین کند. در ASP.NET بهترین و امن ترین راه برای پیاده سازی لاگین استفاده از ویژگی خوب تشخیص هویت خود دات نت است. منظورم همان FormsAuthentication است که شما با آن می توانید یک سیستم لاگین بسیار امن پیاده سازی کنید. به هیچ وجه از کوکی ها برای پیاده سازی یک سیستم لاگین استفاده نکنید! از کوکی ها فقط برای پیاده سازی قابلیت «Remember Me» استفاده کنید آن هم با کلی احتیاط! یک نکته دیگر در مورد لاگین این است که تعداد تلاش های ناموفق یک کاربر برای لاگین را محدود کنید. مثلاً بعد از 5 بار وارد کردن اشتباه رمز عبور به او تا یک مدت اجازه ورود ندهید!

8 ) در مواقع لازم از تصاویر امنیتی استفاده کنید

این نکته را در اکثر وب سایت ها و هنگام ثبت نام دیده اید. مثلاً گوگل در هنگام ثبت نام شما را مجبور می کند که یکسری حروف عجیب و غریب را که در عکس می بینید درون تکست باکس وارد کنید تا بفهمد شما آدم هستید! شما هم سعی کنید در اکثر فرم هایی که نیاز به لاگین کاربر ندارند (مثل فرم ثبت نام یا فرم تماس) از این تصاویر استفاده کنید.

9) امنیت دیتابیس خود را تامین کنید

معمولاً دیتابیس های SQL Server دارای امنیت بسیار خوبی هستند اما اگر از دیتابیس Access برای ذخیره اطلاعات استفاده می کنید حتماً 1- روی فایل آن پسورد بذارید 2- مطمئن شوید که فولدری که فایل دیتابیس در آن قرار دارد توسط کاربران قابل دسترسی نباشد 3- حتماً اطلاعات داخل آن را کدگذاری کنید.

farasun.wordpress.com

مطالب مرتبط :

مصائب فلش! یا چرا اپل از فلش استفاده نمی کند؟

فلشFlash نام بزرگی در دنیای اینترنت و PCهاست که این روزها آینده و حیاتش به چالش جدی کشیده شده است. با سر و صدایی که اپل با پشتیبانی نکردن از ادوبی فلش در محصولات خود از جمله iPad و iPhone راه انداخت و با ارائه HTML 5 که امکانات چند رسانه ای فوق العاده خوبی به توسعه دهندگان وب می دهد، تردید بسیار جدی ای در آینده Adobe Flash بوجود آمده است. فلش در زمان پیدایش خود یک پدیده دوست داشتنی و مدرن بود. پدیده ای که به شما اجازه می داد با کمترین دانش و کمترین زحمت انیمیشن های اینتراکتیو بسیازید و از آن ها در وب استفاده کنید. مشکل فلش شاید این بود که مثل تکنولوژی های دیگر زود به زود تغییر نکرد و همان رویه اولیه خود را دنبال کرد تا به امروز که دیگر جوابگوی نیازهای توسعه دهندگان وب و حتی کاربران اینترنت نیست.

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

موتورهای جستجو فلش را دوست ندارند!

یکی از مهمرین دلایل برای عدم استفاده از فلش، ایندکس نشدن محتویات فایل های فلش در موتورهای جستجوست. اطلاعات مخفی شده در فایل های گرافیکی مثل فایل های فلش برای موتورهای جستجو قابل دسترسی نیستند، هرچند موتورهای جستجوی پیشرفته ای مثل گوگل سعی می کنند محتویات فایل های فلش را نیز ایندکس کنند، اما این عمل با محدودیت های بسیار زیادی مواجه است. وب سایت هایی که کاملاً با فلش ساخته شده اند وضع بسیار نامناسبی از نظر SEO دارند. تگ های متا در فایل های HTML از مهمترین عناصر مربوط به SEO هستند که در وب سایت های Full Flash قابل استفاده نیستند. فایل های فلش معمولاً اطلاعات متنی بسیار کمی ارائه می کنند و اکثراً برای تاثیر گذاری بیشتر فایل های عکس و فیلم را به نمایش می گذارند. گوگل چند وقت پیش از بهبود جستجوی text در فایل های فلش خبر داد و ایندکس کردن اطلاعات عکس، فیلم و انیمیشن بکار رفته در یک فایل فلش را منتفی دانست.

فلش استانداردهای Usability وب را رعایت نمی کند

سایت های فلش زیبا و چشم نواز هستند. شاید برای یک کاربر عادی استفاده از یک سایت فلش حتی راحت تر از استفاده از یک وب سایت معمولی ساخته شده با HTML و CSS باشد. اما محدویدت هایی که فلش برای یک کاربر ایجاد می کند استانداردهای قابل استفاده بودن وب را زیر پا می گذارد. به طور مثال در یک وب سایت فول فلش سعی کنید از دکمه Back مرورگر خود استفاده کنید، متاسفانه کار نمی کند. سعی کنید قسمتی از متن را انتخاب و کپی کنید، یا سعی کنید با استفاده از امکانات مرورگر خود اندازه متن را بزرگ و کوچک کنید! متاسفانه هیچکدام از این امکانات کار نمی کنند. اصلاً یک نکته مهم دیگر : در وب سایت های فول فلش شما نمی توانید استایل صفحه را با استفاده از ابزارهایی مثل Stylish بر اساس سلیقه خود تغییر دهید!

کاربرانی که فلش ندارند!

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

دلایل اپل برای استفاده نکردن از فلش

استیو جابز در نوشته ای دلایل خود را برای عدم استفاده از فلش در محصولات اپل بیان کرده است. اولین دلیل و از نظر من مهمترین دلیل برای استفاده نکردن از فلش، بسته بودن فلش نسبت به سایر تکنولوژی های وب و مخصوصاً HTML و CSS است. استانداردهای فلش را فقط ادوبی تعیین می کند و تمام آینده آن در دست این شرکت است. این در حالی است که استانداردهای مهم وب مثل HTML، CSS و JavaScript همگی باز هستند. چرا باید این استاندرادهای باز را کنار بگذاریم و از محصول بسته شرکت ادوبی استفاده کنیم!؟

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

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

به هر حال با ارائه HTML5 و CSS3 باید منتظر کم رنگ تر شدن هرچه بیشتر نقش Adobe Flash در توسعه وب باشیم. شرکت مایکروسافت نیز همانند گوگل و اپل در مرورگر خود اینترنت اکسپلورر 9 از HTML5 پشتیبانی خواهد کرد و این یعنی آینده وب را تکنولوژی های بازی همچون HTML, CSS و JavaScript خواهند ساخت.

دلایل دیگر برای عدم استفاده از فلش

در وب سایت های فول فلش معمولاً URLهای یکتایی برای هر صفحه وجود ندارد. این مسئله باعث می شود کاربران نتوانند یک صفحه خاص از سایت را بوکمارک کنند و موتورهای جستجو نیز قادر به تفکیک صفحات مختلف از هم نخواهند بود.

کنسرسیوم جهانی وب، تگ جایگذاری فایل فلش درون یک فایل HTML را معتبر نمی داند. در صورتی که از یک فایل فلش در وب سایت خود استفاده کنید، کد شما استاندارد نخواهد بود.

همانطور که در متن اشاره شد، فایل های فلش معمولاً حجم زیادی دارند و این باعث استفاده بیشتر از پهنای باند اینترت کاربران و در نتیجه عدم رضایت آن ها می شود.