مقایسه تجربی Entity Framework و NHibernate

اگر پست های اخیر این وبلاگ را خوانده باشید نباید با Entity Framework و NHibernate نا آشنا باشید. هر دو راه حلی برای دستیابی به داده ها در دات نت فریم ورک ارائه می کنند. Entity Framework محصول مایکروسافت است و NHibernate محصول جامعه اوپن سورس. من از هر دو در پروژه های واقعی استفاده کرده ام و در مورد هر دو نتیجه رضایت بخش بوده است. در این مطلب نتیجه یک مقایسه تجربی را میان Entity Framework و NHibernate خواهید خواند که امیدوارم شما را در انتخاب هر کدام از آن ها کمک کند.

نگاشت کلاس ها

در NHibernate برای انجام عمل Mapping کلاس ها، (با صرف نظر از کتابخانه های کمکی) به ازای هر کلاس باید یک فایل نگاشت XML و برای تنظیم آن نیز یک فایل XML نوشته شود. زمانی که یک دیتابیس داریم و می خواهیم کلاس های مدل خود را بسازیم NHibernate ابزاری برای این کار ندارد (با صرف نظر از ابزارهای کمکی) و باید نگاشت را به صورت دستی انجام داد. اما با استفاده از کتابخانه های کمکی مثل Fluent NHibernate می توان بدون نوشتن حتی یک خط کد XML نگاشت کلاس ها و تنظیم NHinernate را به خوبی انجام داد. ابزارهای Designer متعددی هم در حال حاضر برای نگاشت یک دیتابیس موجود برای NHibernate ساخته شده اند.

در Entity Framework انجام عمل Mapping با استفاده از Designer قدرتمند ویژوال استادیو به راحتی قابل انجام است و (با صرف نظر از نسخه جدید EF) این Designer فقط زمانی که یک دیتابیس وجود داشته باشد به کار می آید. شما می توانید ابتدا دیتابیس خود را بسازید و با Import کردن جدول های مورد نظر خود به صورت ویژوال عملیات Mapping را انجام دهید. سپس EF از روی آن، کلاس های دامین شما را با ارتباط های مناسب خواهد ساخت. در نسخه بعدی EF شما می توانید از روش هایی شبیه به Fluent NHibernate و Castle ActiveRecord برای ساختن کلاس های دامین خود و سپس نگاشت آن ها به یک دیتابیس استفاده کنید.

انجام پرس و جو

Entity Framework دو روش را برای ایجاد و اجرای کوئری ها به شما می دهد. یک روش، دستوراتی کاملاً شبیبه به SQL دارد به نام Entity SQL Language و روش دیگر روش محبوب LINQ to Entitis است که اکثراً از این روش استفاده می کنند. روش اول کاملاً شبیه به استفاده از زبان SQL است، فقط در اینجا به جای استفاده از نام جداول اطلاعاتی از نام کلاس ها و به جای نام فیلدها از نام پراپرتی ها استفاده می کنید. در روش دوم شما تمام قدرت LINQ را برای بدست آوردن نتایج از کلاس های دامین پروژه خود خواهید داشت.

در NHibernate برای کوئری گرفتن انتخاب های بیشتری دارید. این موضوع می تواند هم خوب باشد و هم بد! خوب است چون شما می توانید بر اساس نیاز خود و کاری که می خواهید انجام دهید یک روش را انتخاب کنید و بد است چون در بعضی مواقع باعث سردرگمی شما می شود. محبوب ترین روش در هر دوی این ORMها استفاده از LINQ است که تا نسخه قبلی NHibernate مشکلاتی در پشتیبانی کامل LINQ وجود داشت که در نسخه جدید تا حدود زیادی برطرف شده است. NHibernate از زبان HQL که یک SQL شیء گرا برای نوشتن کوئری است پشتیبانی می کند که برای کسانی که پیش زمینه SQL دارند کار را راحت می کند. Criteria API روش دیگری است که اگر نحوه استفاده از آن را یاد بگیرید تقریباً هر کوئری که نیاز داشته باشید را می توانید با آن بنویسید. در نسخه 3.0 NHibernate روش جدیدی به نام QueryOver اضافه شده که همان Criteria API را با استفاده از اکستنشن متدها و عبارت های lambda به صورت type safe ارائه می دهد. کوئری های نوشته شده به این روش شباهت زیادی به کوئری های نوشته شده با LINQ دارند. MultiQuery نام روش دیگری است که NHibernate را قادر می سازد که فقط با یک بار رفت و برگشت به دیتابیس چند کوئری را اجرا کند و نتایج آن را برگرداند.

سادگی در استفاده

فکر میکنم همه بدانیم که استفاده از Entity Framework در عمل از استفاده از NHibernate به مراتب ساده تر است. ابزارهایی که ویژوال استادیو برای ایجاد کلاس های دامین پروژه برای Entity Framework در اختیار شما قرار می دهد کار شما را بسیار آسان می کند. برای استفاده از EF شما نیازی به دانستن چیز خاصی ندارید و همین که کلاس های شما با استفاده از ویزارد ساخته شدند می توانید شروع به استفاده از آن ها کنید. اما در NH شما نیاز به یادگیری و مطالعه بیشتری دارید و احتمال برخورد به مشکل در آن نسبت به EF بسیار بیشتر است. اگر اهل مطالعه و یادگیری نیستید و در برنامه نویسی بی حوصله اید به هیچ وجه از NHibernate استفاده نکنید!

پشتیبانی از دیتابیس های مختلف

EF و NH هر دو از دیتابیس های محتلفی پشتیبانی می کنند. اما پشتیبانی کردن آن ها با یکدیگر تفاوت دارد. EF محصول مایکروسافت است و به صورت توکار فقط از SQL Server پشتیبانی می کند. برای دیتابیس های دیگر مثل اوراکل یا Sybase باید از پروایدرهای تجاری استفاده کنید. به تازگی MySql و SQLite پروایدرهای خود را برای EF ارائه کرده اند و اوراکل نیز قرار است در نیمه دوم سال 2011 این کار را انجام دهد. البته شما خودتان هم می توانید برای دیتابیس مورد نیاز خود یک پروایدر برای EF بنویسید.

در مورد NH چون یک محصول اوپن سورس است به صورت پیش فرض از دیتابیس های مختلفی مثل اوراکل، MySql، SQLite، SQL Server، Firebird پشتیبانی می کند.

Second Level Cache

استفاده از Caching در یک ORM معمولاً در دو سطح امکان پذیر است. سطح اول که در سطح تراکنش است و تضمین می کند که دو رکورد یکسان در یک Session دو بار خوانده نخواهند شد. سطح دوم Cache در سطح DAL انجام می شود و باعث بالا رفتن سرعت اجرای کوئری ها بدون اتصال دوباره به دیتابیس می شود و فقط محدود به یک Session نخواهد شد. EF  تا نسخه 4.0 این قابلیت را به صورت توکار ارائه نمی کند اما NHibernate تعدادی Provider مناسب برای این کار دارد.

کتابخانه های کمکی

در حال حاضر تعداد کتابخانه های کمکی NHibernate به علت کدباز بودن آن بسیار زیاد است. پروژه هایی مثل NHibernate Search و NH Validator که توسط جامعه کاربری توسعه می یابند برای EF وجود ندارند. برای EF باید به محصولات تجاری شرکت ها مراجعه کنید.

کارایی و سرعت

Entity Framework و NHibernate به اندازه کافی کارایی خوبی دارند اگر به درستی به کار گرفته شوند. نکته ای که وجود دارد این است که با EF شما به سختی می توانید اشتباه کنید اما در NHibernate اشتباه کردن به راحتی آب خوردن است! در Entity Framework بدون اینکه شما کاری انجام دهید، کارایی خوبی خواهید داشت اما در مورد NHibernate اینطور نیست. اگر مستندات NHibernate را کامل بخوانید و تمام ملاحظات کارایی را در پیاده سازی لحاظ کنید به کارایی و سرعت بالاتری از EF هم خواهید رسید.

زمان یادگیری

همانطور که گفته شد، یادگیری NHibernate معمولاً زمان بیشتری نسبت به Entity Framework نیاز دارد. با NHibernate شما نیاز به یادگیری مفاهیم بیشتری دارید و معمولاً برای حل یک مشکل زمان بیشتری را باید صرف کنید. هر دو، کتاب ها و منابع خوبی برای یادگیری دارند.

نتیجه

برای تصمیم گیری درباره استفاده از هر کدام از این ORMها فاکتورهای دیگری نیز موثر هستند که در این مطلب به آن ها اشاره نشد. NHibernate در حال حاضر انتخاب های بیشتری را نسبت به EF ارائه می دهد و شما کنترل بیشتری بر روی ویژگی های آن دارید. انتخاب های بیشتر باعث پیچیده تر شدن NH شده است. EF به جای آن از سادگی خاص محصولات مایکروسافت بهره می برد و برای راه اندازی یک پروژه که وقت کمی دارد بسیار مناسب است. هر چند انتخاب ها و ویژگی های بیشتر همیشه نکته مثبتی نیستند، چون اگر ندانید چطور انتخاب کنید و یا نحوه کار ویژگی مورد نظر را درک نکرده باشید، به راحتی می توانید اشتباه کنید. EF و NH هر دو وظیفه های مهم یک ORM را به خوبی انجام می دهند و کمی در جزئیات با هم متفاوت اند که در این مطلب به آن ها اشاره شد.

ویژگی جدید Code-first برای Entity Framework

با محبوب شدن NHibernate و کتابخانه های وابسته به آن مثل Castle ActiveRecord و Fluent NHibernate، مایکروسافت به تازگی ویژگی جدیدی را به صورت Preview برای ORM خود یعنی Entity Framework عرضه کرده است که قابلیت هایی جدیدی را به توسعه دهندگان می دهد تا به جای سر و کله زدن با ابزارهای Designer و فایل های نگاشت XML، بر کدهای شیء گرا تمرکز داشته باشند. با این ویژگی شما به راحتی می توانید مدل خود را با استفاده از کلاس های معمولی بسازید و از EF بخواهید تا دیتابیس را از روی مدل نوشته شده توسط شما بسازد.

نسخه ای که به تازگی عرضه شده آخرین نسخه کتابخانه Code first قبل از ارائه نسخه اصلی خواهد بود. برای دانلود این ویژگی جدید به این صفحه از سایت مایکروسافت بروید. بعد از نصب کتابخانه، برای استفاده از این ویژگی پروژه جدیدی از نوع Class Library ایجاد کنید و به فایل EntityFramework.dll در مسیر نصب شده ارجاع دهید. یک کلاس به نام Blog با محتویات زیر بسازید :

using System.Collections.Generic;<br />
using System.ComponentModel.DataAnnotations;<br />
using System.Data.Entity;</p>
<p>namespace BlogModel<br />
{<br />
public class Blog<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Title is required.")]<br />
public string Title { get; set; }</p>
<p>public bool ShowInSearchEngines { get; set; }</p>
<p>public string Description { get; set; }</p>
<p>public IList<Post> Posts { get; set; }<br />
}<br />
}

می خواهیم مدلی بسازیم برای نگهداری اطلاعات یکسری وبلاگ به علاوه پست ها و کامنت های هر کدام. در اینجا شما می توانید کلاس هایی ایجاد کنید که هر کدام نشان دهنده یک موجودیت در دیتابیس شما خواهند بود. این کلاس ها می توانند کلاس های ساده POCO باشند که نیازی ندارند از کلاس دیگری به ارث بروند تا نقش یک Entity را برای شما بازی کنند. این ویژگی به شما کمک می کند تا یک مدل ساده، قابل درک، تمیز و قابل تست برای پروژه خود بسازید. کلاس های مثال ما همگی POCO هستند.

using System.Collections.Generic;<br />
using System.Data.Entity;<br />
using System.ComponentModel.DataAnnotations;</p>
<p>namespace BlogModel<br />
{<br />
public class Post<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Title is required.")]<br />
public string Title { get; set; }</p>
<p>[StringLength(4000)]<br />
[Required(ErrorMessage="Content is required.")]<br />
public string Content { get; set; }</p>
<p>public Blog Blog { get; set; }</p>
<p>public IList<Comment> Comments { get; set; }<br />
}<br />
}

کلاس Post برای نگهداری اطلاعات یک پست وبلاگ نوشته شده است. Post با موجودیت Blog یک رابطه چند به یک و با موجودیت Comment یک رابطه یک به چند دارد که با استفاده از پراپرتی در آن مشخص شده اند. با استفاده از قابلیت های فضای نام DataAnnotations می توان مشخصات یک موجودیت را اعتبار سنجی نمود. این اعتبار سنجی با استفاده از تعریف Attribute بر روی مشخصات انجام می شود. به طور مثال پراپرتی Content در این موجودیت می تواند تا 4000 کاراکتر را در خود ذخیره کند و حتماً باید مقداری برای آن وارد شود وگرنه یک استثنا رخ خواهد داد که باید توسط برنامه نویس هندل شود.

using System.Data.Entity;<br />
using System.ComponentModel.DataAnnotations;</p>
<p>namespace BlogModel<br />
{<br />
public class Comment<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Name is required.")]<br />
public string Name { get; set; }</p>
<p>[Required(ErrorMessage="Email is required.")]<br />
public string Email { get; set; }</p>
<p>public string URL { get; set; }</p>
<p>[Required]<br />
public string Content { get; set; }</p>
<p>public Post Post { get; set; }<br />
}<br />
}<br />

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

using System.Data.Entity;</p>
<p>namespace BlogModel<br />
{<br />
public class MyBlogPlatform: DbContext<br />
{<br />
public DbSet<Blog> Blogs { get; set; }<br />
public DbSet<Post> Posts { get; set; }<br />
public DbSet<Comment> Comments { get; set; }<br />
}<br />
}<br />

در واقع این کلاس باعث می شود تا کلاس های ساده ی ما با دیتابیس بوسیله Map کردن کلاس ها به جدوال و پراپرتی ها به فیلدها و رابطه ها  ارتباط برقرار کنند. کدهای بالا تمام کدهای لازمی بود که ما برای ایجاد مدل و لایه دسترسی به داده های خود احتیاج داشتیم. آخرین مرحله قبل از استفاده از این مدل، مشخص کردن Connection String برای ایجاد دیتابیس از روی آن است که می توانید در web.config آن را به صورت زیر مشخص کنید :

<connectionStrings><br />
 <add name="MyBlogPlatform"  connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=MyBlogPlatform;Integrated Security=True"  providerName="System.Data.SqlClient"  />

EF Code first به صورت پیش فرض به دنبال رشته اتصالی در فایل web.config می گردد که با کلاس Context شما همنام باشد. چون کلاس Context ما در این مثال MyBlogPlatform است، EF هم به دنبال رشته اتصالی به همین نام خواهد گشت و از آن برای ایجاد دیتابیس یا اتصال به دیتابیس موجود استفاده خواهد کرد. برای اینکه مطمئن شویم کارمان مشکلی ندارد کدی برای ایجاد یک موجودیت بلاگ در دیتبایس در مکان مناسب (مثل کلیک یک دکمه در صفحه) می نویسیم :

MyBlogPlatform blogPlatform = new MyBlogPlatform();<br />
 Blog blog = new Blog()<br />
 {<br />
 Title = "Farasun",<br />
 ShowInSearchEngines = true,<br />
 Description = "A blog about programming"<br />
 };<br />
 blogPlatform.Blogs.Add(blog);<br />
 blogPlatform.SaveChanges();<br />
 

در این نقطه کار ما به پایان رسیده و شما قادر خواهید بود که با مدل خود کار کنید. EF تمام کارهای مربوط به دیتابیس را انجام خواهد داد و شما فقط باید بر روی قوانین تجاری و رابط کاربری اپلیکیشن خود وقت بگذارید. به طور مثال برای کوئری گرفتن توسط LINQ می توانیم چنین کدی برای مدل خود بنویسیم :

MyBlogPlatform myBlogPlatform = new MyBlogPlatform();<br />
 var query = from x in myBlogPlatform.Posts<br />
 where x.Title.Contains(“Entity Framework”)<br />
 select x;<br />
 

اگر سری آموزش های Castle ActiveRecord در این وبلاگ را دنبال کرده باشید، با این پست غریبه نبوده اید. اینطور که به نظر می رسد تیم Entity Framework راه درستی برای ادامه توسعه این پروژه انتخاب کرده و در آینده ای نزدیک باید شاهد قابلیت های بیشتری در جهت بهبود کارایی این ORM باشیم.

چرا NHibernate انتخاب خوبی به عنوان یک ORM است؟

در مطلب قبل دلایلی برای استفاده از ORM در دات نت فریم ورک برای دسترسی به داده ها و کار با دیتابیس معرفی شد. در این مطلب به معرفی NHibernate و دلایلی برای استفاده از آن به عنوان یک ORM مناسب برای دات نت فریم ورک پرداخته خواهد شد. NHibernate پیاده سازی ORM معروف دنیای جاوا یعنی Hibernate برای پلت فرم دات نت است که به صورت گسترده ای مورد استفاده توسعه دهندگان دات نت در سراسر دنیا قرار گرفته است. NHibernate آزاد و کد باز است و وظیفه اش مانند ORMهای دیگر نگاشت کلاس های شیء گرا به جدوال یک دیتابیس است.

nhibernate logoدر ادامه مطلب با مزیت های NHibernate به عنوان یکی از بهترین ORMهای موجود برای پلت فرم دات نت آشنا می شوید. البته تمام مزیت هایی که در مطلب قبل در مورد یک ORM ذکر شد، در مورد NHibernate نیز صحت دارند که دیگر از ذکر آن ها در این مطلب صرف نظر شده است.

کد باز است : شاید به نظر بعضی ها اوپن سورس بودن مزیت محسوب نشود، اما کد باز بودن NHibernate باعث شده تا این پروژه خیلی زود پیشرفت کند و به پر استفاده ترین و به روز ترین ORM پلت فرم دات نت تبدیل شود. در حال حاضر افراد زیادی به صورت تمام وقت و نیمه وقت بر روی توسعه NHibernate کار می کنند و از این ORM در بسیاری از پروژه های کد باز و تجاری استفاده می شود. حداقل برای من، کد باز بودن NHibernate مزیت بسیار مهمی محسوب می شود.

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

واقعاً از چند دیتابیس پشتیبانی می کند : شما فقط به SQL Server محدود نخواهید بود و تقریباً می توانید از هر دیتابیسی برای ذخیره داده های برنامه خود استفاده کنید.  NHibernate در حال حاضر از DBMSهای معروف و پر کاربرد مثل Oracle, SQL Server و MySql و چند دیتابیس دیگر پشتیبانی واقعی می کند. این در حالی است که Entity Framework مایکروسافت در حال حاضر به صورت رسمی فقط از SQL Server پشتیبانی می کند.

از زبان HQL پشتیبانی می کند : زبان HQL یک زبان پرس و جوی پیشرفته است که در پروژه Hibernate جاوا به صورت وسیع مورد استفاده قرار می گیرد. با استفاده از این زبان می توانید کوئری های پیچیده را بر روی دیتابیس مورد نظر خود اجرا کنید.

امتحان خود را پس داده است : در حال حاضر NHibernate به صورت گسترده ای در پروژه های مختلف کد باز و تجاری مبتنی بر پلت فرم دات نت مایکروسافت مورد استفاده قرار می گیرد. تجربه های بسیار خوبی از استفاده از NHibernate به عنوان ORM در پلت فرم دات نت وجود دارد. در واقع NHibernate مطمئن ترین و با اعتبار ترین ORM برای پلت فرم دات نت مایکروسافت است.

انجام تغییرات را آسان می کند : از آنجا که موجودیت های پروژه را خودتان مدل می کنید و بر روی آن ها کنترل دارید، انجام تغییرات بر روی مدل و ایجاد دیتابیس از روی آن با NHibernate بسیار آسان است. انجام تغییرات بر روی مدل برنامه با مهارت های یک برنامه نویس معمولی دات نت قابل انجام است و نیازی نیست برای تغییر در مدل برنامه و در نتیجه تغییر در دیتابیس یک حرفه ای باشید. این را هنگام توسعه اولین برنامه خود با NHibernate شدیداً درک خواهید کرد!

کتابخانه های کمکی مناسبی دارد : پس از یادگیری NHibernate متوجه خواهید شد که می توان بسیاری از کارها را با کتابخانه های کمکی که برای آن نوشته شده، سریع تر و آسان تر انجام داد. به طور مثال می توان از Fluent NHibernate برای انجام اعمال Mapping به جای نگاشت بر اساس فایل های XML استفاده کرد. کتابخانه  Castle ActiveRecord با اضافه کردن لایه ای بر روی NHibernate کاری می کند که شما بدون درگیر شدن با پیچیدگی های NHibernate از آن به راحتی استفاده کنید. کتابخانه ای برای اضافه کردن Validation و کتابخانه ای برای اجرای کوئری های Linq بر روی آبجکت های NHibernate نیز موجود است.

کارایی بالایی دارد : به عنوان یک ORM از کارایی مناسبی برای انجام عملیات های سنگین بر روی دیتابیس برخوردار است. البته این کارایی مناسب در صورتی است که شما NHibernate را به درستی تنظیم و از آن استفاده کنید. ویژگی هایی مثل Second Level Caching، Multi Query و Batch Select که باعث کاهش ایجاد اتصال ها به دیتابیس و در نتیجه افزایش Performance می شوند در NHibernate وجود دارند و شما کافیست تا از آن ها در مواقع مناسب استفاده کنید.

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

farasun.wordpress.com

اگر دلیل دیگری برای استفاده از NHibernate به عنوان یک ORM مناسب برای دات نت فریم ورک سراغ دارید، در فرم نظرات این مطلب با ما به اشتراک بگذارید.

10 دلیل برای استفاده از ORM در دات نت فریم ورک

ORM یک تکنیک برنامه نویسی برای تبدیل مدل رابطه ای یک دیتابیس به مدل شیء گرا و بالعکس می باشد که در حال حاضر مورد توجه بسیاری از توسعه دهندگان نرم افزاری قرار دارد. استفاده از ORMها مزایای بسیاری دارد و در بسیاری موارد کار توسعه را آسان تر و لذت بخش تر خواهد کرد. برای دات نت فریم ورک ORMهای کدباز و تجاری زیادی وجود دارد که از این جمله می توان به ADO.NET Entity Framework و NHibernate اشاره نمود. من به شخصه از Entity Framework در یک پروژه واقعی استفاده کردم و تمام مزایایی که قبلاً در مورد یک ORM خوانده بودم را در واقعیت دیدم. در این مطلب به 10 دلیل برای استفاده از یک ORM در یک پروژه مبتنی بر دات نت فریم ورک اشاره خواهم کرد که به شخصه آن ها را تجربه کرده ام.

1- افزایش سرعت توسعه : طراحی لایه دسترسی به داده ها در یک برنامه تجاری معولاً زمان قابل توجهی را به خود اختصاص می دهد و کارهای تکراری مثل درج، به روز رسانی، حذف و خواندن رکوردهای دیتابیس به وفور در آن یافت می شود. استفاده از یک ORM می تواند زمان طراحی لایه دسترسی به داده ها را کاهش دهد یا حتی در مواردی نیاز شما به این لایه را از بین ببرد و شما را از نوشتن کدهای تکراری برای انجام اعمال بر روی دیتابیس راحت کند. اگر وقت زیادی صرف نوشتن کوئری های SQL به صورت رشته ای برای خواندن رکوردها و استفاده از آبجکت های ADO.NET برای درج، به روز رسانی یا حذف داده های یک دیتابیس می کنید، بهتر است در رویه برنامه نویسی خود تجدید نظر کنید و بقیه مزایای استفاده از یک ORM را تا انتها بخوانید!

2- رعایت الگوی طراحی شیء گرا : تفاوت ماهیت دیتابیس های رابطه ای با الگوی شیء گرا همیشه برای برنامه نویسان معضل بزرگی بوده و هست. کار اصلی ORM این است که جدوال رابطه ای یک دیتابیس را به کلاس های شیء گرا و بالعکس تبدیل کند و مدل سازی های مورد نیاز را به صورت استاندارد انجام دهد. هرچند در این روش نمی توان از برخی مفاهیم مهم طراحی شیء گرا مثل ارث بری یا چند ریختی استفاده کرد اما برنامه نویس را مجبور خواهد کرد تا حداقل قوانین های طراحی شیء گرایی را در پروژه خود لحاظ کند. استفاده از الگوی طراحی OOP باعث کاهش پیچیدگی پروژه و آسان تر شدن نگهداری کد و اعمال تغییرات بر روی آن خواهد شد.

3- کاهش پیچیدگی پروژه : شاید در ابتدا استفاده از یک ORM برای طراحی یک پروژه بزرگ ترسناک به نظر برسد! اما در واقع ORM برای کاهش پیچیدگی توسعه یک پروژه بوجود آمده است. استفاده از کلاس های شیء گرا برای کار با ساختار پایگاه داده برای یک برنامه نویس دات نت بسیار راحت تر از سر و کله زدن با کوئری های SQL برای رسیدن به نتایج مورد نظر یا انجام عملیات بر روی دیتابیس خواهد بود. در واقع کدهای مورد استفاده در پروژه ای که با یک ORM توسعه داده شده است به مراتب خواناتر از پروژه های دیگر است و حتی یک فرد غیر برنامه نویس نیز منظور کد را خواهد فهمید.

4- راحت شدن از دست SQL : برای کار کردن با جداول یک پایگاه داده زبان SQL زبان بی نقصی است، اما زمانی که قرار باشد از آن در یک زبان برنامه نویسی شیء گرا مثل سی شارپ استفاده شود، واقعاً عذاب آور خواهد بود. فرض کنید در تمام پروژه خود از دستورات SQL در متغیرهای string استفاده کرده اید، حال با تغییر نام یک فیلد بایستی به دنبال رشته نام فیلد مورد نظر، کل پروژه را بگردید و رشته جدید را جایگزین آن کنید و این کار به صورت خودکار انجام نخواهد شد. کامپایلر هیچ نوع کنترلی بر روی رشته های  SQL ندارد و یک اشتباه تایپی می تواند باعث ایجاد خطای در حال اجرا شود. استفاده از ORM می تواند شما را شر SQL راحت کند!

5- طراحی استاندارد لایه دسترسی به داده ها : در پیاده سازی ORMهای موجود تمام تجربه های موفق لحاظ شده اند و در نتیجه کدهای تولید شده توسط آن ها کاملاً بهینه و استاندارد هستند. ORM باعث می شود تا شما و بقیه اعضای تیم از یک استاندارد خاص برای طراحی لایه دسترسی به داده های خود پیروی کنید و در نتیجه بازدهی بهتری را شاهد باشید. این مزیت در آخر باعث بوجود آمدن یک ساختار مناسب در لایه دسترسی به داده های پروژه شما خواهد شد.

6- امکان استفاده از LINQ : در دات نت فریم ورک می توانید از زبان LINQ برای اجرای کوئری های مختلف در هنگام استفاده از یک ORM بهره ببرید. با این کار کامپایلر کنترل کاملی بر روی کوئری های نوشته شده دارد و تمام خطاها را شناسایی و گزارش خواهد کرد. به علاوه کوئری های نوشته شده در این حالت از خوانایی بسیار بالاتری برخوردار خواهند بود و می توانید از قابلیت های IntelliSense ویژاول استادیو برای بالا بردن سرعت کدنویسی و کاهش خطاهای انسانی بهره ببرید.

7- ORMها آزمایش خود را پس داده اند : در حال حاضر تعداد بسیار زیادی از پروژه های اوپن سورس پلت فرم دات نت بر پایه یک ORM توسعه یافته اند. با یک جستجوی کوچک می توانید لیست بلند بالایی از این پروژه ها را مشاهده کنید. تجربه های خوب بسیار زیادی هم از پروژه های تجاری که از ORM برای دسترسی به داده ها استفاده کرده اند در اینترنت وجود دارد. این نشان می دهد که ORMها آزمایش خود را پس داده اند و برای استفاده در پروژه های واقعی به اندازه کافی قابل اعتمادند.

8- نگهداری از کد و تغییر آن در دراز مدت آسان تر می شود : به علت پشتیبانی ORMها از الگوی طراحی شیء گرا و دیگر الگوهای طراحی در توسعه نرم افزار و تولید کدهای استاندارد، نگهداری از کدهای نوشته شده و تغییر آن ها در طولانی مدت بسیار آسان تر خواهد شد. کدهای نوشته شده بر مبنای یک ORM معمولاً بسیار واضح هستند و تغییر آن ها اگر به صورت استاندارد نوشته شده باشند، اصلاً سخت نخواهد بود.

9- استفاده از قابلیت Refactoring : فرض کنید نیاز دارید تا نام چند فیلد یا جدول را در دیتابیس خود تغییر دهید. اگر از ADO.NET و کدهای SQL برای طراحی لایه داده های خود استفاده کرده باشید، برای انجام این تغییرات در کدهای خود نمی توانید از قابلیت Refactoring ویژوال استادیو استفاده کنید تا به صورت اتوماتیک این کارها انجام شود. اما با استفاده از یک ORM، تغییر دادن یک موجودیت باعث به روز رسانی تمامی ارجاع های آن موجودیت در کل پروژه توسط قابلیت Refactoring ویژوال استادیو خواهد شد. این قابلیت می تواند خطاهای انسانی را فوق العاده کاهش و سرعت توسعه را افزایش دهد.

10 – عدم وابستگی به یک دیتابیس خاص : هر چند این نکته در مورد تمام ORMهای مخصوص دات نت فریم ورک درست نیست، اما در حال حاضر ORMهای خوبی مثل NHibernate و Entity Framework از چندین دیتابیس پر استفاده پشتیبانی می کنند. البته EF در حال حاضر به صورت رسمی فقط از SQL Server پشتیبانی می کند!

farasun.wordpress.com

توصیه می شود مطالبی که قبلاً دوستان در این مورد نوشته بودند را مطالعه کنید :

farasun.wordpress.com

عناوین دیگر برای این نوشته : چرا باید از یک ORM در دات نت فریم ورک استفاده کرد؟ | مزیت های استفاده از ORM در دات نت فریم ورک

فریم ورک های تست واحد برای دات نت

Unit Testing یا آزمایش واحد (=تست واحد) روشی است برای آزمایش نرم افزار که در آن قسمت های واحدی از سورس کد پروژه مورد آزمایش قرار می گیرند تا مشخص شود که همان کاری که انتظار می رود را انجام می دهد. منظور از Unit یا واحد، کوچکترین قسمت قابل تست یک برنامه است که می تواند یک تابع یا یک متد باشد. هر واحد به صورت جداگانه مورد آزمایش قرار می گیرد تا از صحت عملکرد آن اطمینان حاصل گردد. در ابتدا شاید انجام تست واحد عملی وقت گیر و اضافی به نظر بیاید، اما اگر شما از صحت عملکرد قسمت های کوچک برنامه خود اطمینان داشته باشید، در آخر کار با باگ ها و مشکلات بسیار کمتری مواجه خواهید شد که این باعث کاهش زمان تولید و تست و در نتیجه بالا رفتن بازدهی و تحویل به موقع خروجی به پروژه به کارفرما می شود.

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

NUnit : یک فریم ورک خوش ساخت کدباز است که از دنیای جاوا و با پورت کردن پروژه JUnit به دات نت بوجود آمد و با استفاده از Resharper و TestDriven.NET می توان از تمام قابلیت های آن در ویژوال استادیو بهره برد. مستندات خوبی دارد و مثال های بسیار زیادی برای آن در وب وجود دارد.

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

csUnit : یک فریم ورک کدباز و رایگان است که تمام ویژگی های یک فریم ورک تست واحد خوب را یکجا دارد. با تمام زبان های برنامه نویسی دات نت سازگاری دارد و شامل ابزار GUI، پلاگین ویژوال استادیو و خط فرمان برای اجرای آزمایش هاست.

xUnit : فریم ورک کدباز جدیدی است که به توسعه دهندگان اجازه می دهد تا از TDD به سادگی هر چه تمام تر برای توسعه نرم افزار خود استفاده کنند. شامل ابزار GUI و خط فرمان برای اجرای تست هاست و می توانید با استفاده از TestDriven.NET یا Resharper در ویژوال استادیو از آن بهره ببرید.

Visual Studio Unit Testing Framework : راه حل مایکروسافت برای انجام آزمایش های واحد در دات نت است که در نسخه های Team System ویژوال استادیو 2005 به بعد وجود دارد. تست های واحد ساخته شده با این فریم ورک می توانند به صورت مستقیم درون ویژوال استادیو اجرا شوند یا با ابزار MSTest.exe از خط فرمان اجرا شوند.

farasun.wordpress.com

اگر به مبحث Unit Testing علاقه دارید پیشنهاد میکنم سری نوشته های آقای وحید نصیری در این مورد را حتماً بخوانید.

Visual Studio Unit Testing Framework : راه حل مایکروسافت برای انجام آزمایش های واحد در دات نت است که در نسخه های Team System ویژوال استادیو 2005 به بعد وجود دارد. تست های واحد ساخته شده با این فریم ورک می توانند به صورت مستقیم درون ویژوال استادیو اجرا شوند یا با ابزار MSTest.exe از خط فرمان اجرا شوند.

ذخیره تنظیمات یک برنامه دسکتاپ در دات نت

در اکثر برنامه های دسکتاپ، قسمتی به عنوان تنظیمات (Settings، Options یا Preferences) در نظر گرفته می شود تا کاربران امکان تنظیم اجزای مختلف برنامه را بر اساس سلیقه یا نیاز خود داشته باشند. در دات نت فریم ورک قابلیتی به نام Settings وجود دارد که شما با استفاده از آن می توانید تنظیمات برنامه خود را در یک فایل به نام App.config در کنار برنامه خود ذخیره کنید. Settings می تواند شامل مقادیر مختلفی باشد که برنامه شما برای به یادآوردن ترجیحات کاربران و تنظیم قسمت های مختلفش به آن ها نیاز دارد. به طور مثال می توانید تغییراتی که کاربر در ظاهر برنامه می دهد (مثل اندازه پنجره و تم برنامه) یا رشته اتصال به دیتابیس را درون فایل App.config ذخیره کنید و هر بار هنگام اجرای برنامه این فایل را بخوانید و تنظیمات کاربر را اعمال کنید.

برای استفاده از قابلیت Settings، در ویژاول استادیو از Solution Explorer بر روی پروژه خود کلیلک راست کنید و گزینه Properties را برگزنید (و یا از پوشه Properties پروژه خود فایل Settings.settings را باز کنید). اگر در تب Settings نیستید، به تب Settings بروید. حالا باید چیزی شبیه به تصویر زیر را ببینید که Settings Designer نام دارد.

Settings Designerهمانطور که مشاهده می کنید هر Setting دارای 4 خصوصیت است :

  • Name : نامی است که در کدنویسی برای دستیابی به مقدار ذخیره شده در این Setting مورد استفاده قرار می گیرد.
  • Type : نوع مقداری است که قرار است در این Setting ذخیره شود. در اینجا تمام نوع های داده ای دات نت فریم ورک پشتیبانی می شوند. به طور مثال شما می توانید رنگ پس زمینه یک پنجره را با توع System.Color ذخیره کنید.
  • Scope : نحوه دستیابی به یک Setting را در زمان اجرا کنترل می کند. اگر از نوع User انتخاب شود، مقدار هم خواندنی است و هم نوشتنی اما اگر از نوع Application در نظر بگیرید،مقدار Setting فقط خواندنی است و از طریق کدنویسی و در حال اجرا غیر قابل تغییر است.
  • Value : مقداری است که هنگام دستیابی به Setting برگردانده خواهد شد. این مقدار باید از همان نوعی باشد که در Type مشخص شده است.

پس از مشخص کردن Settingهای مورد نیاز برنامه خود، می توانید از طریق کد به آن ها دسترسی داشته باشید. در سی شارپ برای دسترسی به این تنظیمات از طریق کد باید از فضای نام Properties استفاده کنید. تمام تنظیماتی که مشخص کرده اید از طریق Properties.Settings.Default در کدنویسی قابل دسترسی اند و IntelliSense آن ها را می شناسد و به شما نشان می دهد. تمام آن ها از نوع مشخصی برخوردار هستند و به اصطلاح Strongly typed هستند.

فرض می کنیم یک Setting به نام Title از نوع String ساخته اید که عنوان پنجره اصلی برنامه شما را در خود ذخیره می کند. برای خواندن آن به صورت زیر کد می نویسیم :

this.Title = Properties.Settings.Default.Title;

و برای ذخیره مقدار ورودی کاربر در این Setting به صورت زیر عمل می کنیم :

Properties.Settings.Default.Title = txtTitle.Text;

Properties.Settings.Default.Save();

بدون صدا زدن متد Save تغییرات درون فایل ذخیره نخواهد شد. فقط به این نکته توجه داشته باشید که Settingهایی که دارای محدوده Application هستند را نمی توانید به صورت کد نویسی تغییر دهید. این نوع تنظیمات فقط از طریق Setting Designer یا تغییر دستی مقدار آن ها در یک ویرایشگر متن قابل تغییر هستند.

استفاده از چند فایل تنظیمات

در بعضی موارد ممکن است برنامه شما به جای یک فایل تنظیمات نیاز به چند فایل تنظیمات داشته باشد. در این مواقع شما می توانید در ویژوال استادیو روی پروژه خود کلیک راست کنید و گزینه Add New item را انتخاب کنید و به دنبال Settings File بگردید. یک نام به جز Settings مثلاً MyNewSettings را برای آن مشخص کنید و دکمه Add را بزنید تا به پروژه شما اضافه شود. حالا به جای Properties.Settings برای دسترسی به تنظیمات فایل جدید از Properties.MyNewSettings استفاده کنید. همین!

farasun.wordpress.com

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

نسخه Client Profile دات نت فریم ورک

اگر تا به حال در ویژوال استادیو 2010 برنامه های WPF یا WinForms نوشته باشید، حتماً متوجه شده اید که به صورت پیش فرض Target این پروژه ها دات نت فریم ورک نسخه Client Profile است. این نسخه از دات نت فریم ورک، زیر مجموعه ای از دات نت فریم ورک 4.0 است که برای برنامه های تحت دسکتاپ بهینه سازی شده است. این نسخه شامل تمام ویژگی هایی است که یک برنامه تحت دسکتاپ نیاز دارد. نسخه Client Profile باعث می شود تا حجم پکیج Install برنامه شما به حداقل برسد و فقط قسمتی از دات نت فریم ورک را بر روی سیستم کاربر نصب می کند که برای اجرای یک برنامه تحت کلاینت مورد نیاز است.

Target Client Profile

اجزای موجود در دات نت فریم ورک کلاینت پروفایل :

  • common language runtime (CLR)
  • ClickOnce
  • Windows Forms
  • Windows Presentation Foundation (WPF)
  • Windows Communication Foundation (WCF)
  • Entity Framework
  • Windows Workflow Foundation
  • Speech
  • XSLT support
  • LINQ to SQL
  • Runtime design libraries for Entity Framework and WCF Data Services
  • Managed Extensibility Framework (MEF)
  • Dynamic types
  • Parallel-programming features
  • Debugging client applications

اجزایی که در نسخه کلاینت پروفایل وجود ندارند :

  • ASP.NET
  • Advanced Windows Communication Foundation (WCF) functionality
  • .NET Framework Data Provider for Oracle
  • MSBuild

Project Templateهایی که به صورت پیش فرض نسخه کلاینت پروفایل را Target قرار می دهند :

  • WPF Application
  • WPF Browser Application
  • WPF Custom Control Library
  • WPF User Control Library
  • Windows Forms Application
  • Windows Forms Control Library
  • Console Application
  • Empty Project
  • Window Service
  • All Office 2007 and Office 2010 project templates
  • WCF Service Library
  • Activity Designer Library
  • Activity Library
  • Workflow Console Application
  • F# Application
  • F# Tutorial

چه موقع از نسخه کلاینت پروفایل استفاده کنیم؟
زمانی که پروژه شما قرار است تحت ویندوز اجرا شود و نیازی به استفاده از وب سرویس و ویژگی های حرفه ای WCF ندارید، استفاده از نسخه کلاینت پروفایل کار عاقلانه ای است. به این دلیل که استفاده از این نسخه باعث می شود تا کاربر برای اجرای برنامه شما نیازی به نصب کامل دات نت فریم ورک 4.0 بر روی سیستم خود نداشته باشد.