مقایسه تجربی 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 را به خوبی انجام می دهند و کمی در جزئیات با هم متفاوت اند که در این مطلب به آن ها اشاره شد.

استفاده از 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);
}

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

یادگیری Castle ActiveRecord با مثال – قسمت هفتم

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

نکته : اگر از گوگل ریدر یا هر فیدخوان دیگری استفاده می کنید و کدها را به درستی مشاهده نمی کنید، لطفاً مطلب اصلی را در وبلاگ بخوانید.

یکی از مزیت های مهم استفاده از NHibernate که بسیاری از شرکت ها و توسعه دهندگان فقط به همین دلیل از آن در پروژه ها استفاده می کنند، پشتیبانی از پایگاه داده های محبوبی مثل Oracle, SQL Server, MySQL, Firebird و SQLite است. در این قسمت یاد خواهیم گرفت که چطور Castle ActiveRecord را برای کار با پایگاه داده های مختلف تنظیم کنیم.

اگر خاطرتان باشد در برنامه ویندوزی مثالی که نوشتیم تنظیمات CAR را در فایل App.config ذخیره کردیم (در برنامه های وب در فایل Web.config). این فایل را باز کنید و برای دیتابیس های مختلف به صورت زیر تغییر دهید :

SQL Server

<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=MyBookStore;Integrated Security=True;Pooling=False"/>
 <add key="proxyfactory.factory_class"
 value="NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle"/>
 </config>
</activerecord>

Oracle

<activerecord>
 <config>
 <add key="connection.driver_class"
 value="NHibernate.Driver.OracleClientDriver" />
 <add key="dialect"
 value="NHibernate.Dialect.Oracle10gDialect" />
 <add key="connection.provider"
 value="NHibernate.Connection.DriverConnectionProvider" />
 <add key="connection.connection_string"
 value="Data Source=./Oracle;User ID=MyBookStore;Password=MyBookStore;Unicode=true" />
 </config>
</activerecord>

MySQL

<activerecord>
 <config>
 <add
 key="connection.driver_class"
 value="NHibernate.Driver.MySqlDataDriver" />
 <add
 key="dialect"
 value="NHibernate.Dialect.MySQLDialect" />
 <add
 key="connection.provider"
 value="NHibernate.Connection.DriverConnectionProvider" />
 <add
 key="connection.connection_string"
 value="Database=MyBookStore;Data Source=localhost;User Id=root;Password=" />
 </config>
</activerecord>

Firebird

<activerecord>
 <config>
 <add
 key="connection.driver_class"
 value="NHibernate.Driver.FirebirdDriver" />
 <add
 key="dialect"
 value="NHibernate.Dialect.FirebirdDialect" />
 <add
 key="connection.provider"
 value="NHibernate.Connection.DriverConnectionProvider" />
 <add
 key="connection.connection_string"
 value="Server=localhost;Database=MyBookStore.fdb;User=;password=;ServerType=1;Pooling=false" />
 <add
 key="query.substitutions"
 value="true 1, false 0" />
 </config>
</activerecord>

PostgreSQL

<activerecord>
 <config>
 <add
 key="connection.driver_class"
 value="NHibernate.Driver.NpgsqlDriver" />
 <add
 key="dialect"
 value="NHibernate.Dialect.PostgreSQLDialect" />
 <add
 key="connection.provider"
 value="NHibernate.Connection.DriverConnectionProvider" />
 <add
 key="connection.connection_string"
 value="Server=localhost;initial catalog=MyBookStore;User ID=;Password=;" />
 </config>
</activerecord>

SQLite

<activerecord>
 <config>
 <add key="connection.driver_class"
 value="NHibernate.Driver.SQLite20Driver"/>
 <add key="dialect"
 value="NHibernate.Dialect.SQLiteDialect"/>
 <add key="connection.provider"
 value="MyBookStore.Model.SQLite.SQLiteConnectionProvider, MyBookStore.Model"/>
 <add key="connection.connection_string"
 value="Data Source=Data.db"/>
 <add key="proxyfactory.factory_class"
 value="NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle"/>
 </config>
 </activerecord>

اگر به کدهای بالا توجه کنید متوجه خواهید شد که Connection Provider مربوط به تنظیمات SQLite با بقیه فرق دارد. این تفاوت به این علت است که NHibernate در نسخه 2 از System.Data.SQLite به صورت توکار پشتیبانی نمی کند. برای اینکه این پشتیبانی را خودمان اضافه کنیم یک کلاس جدید به پروژه Model برنامه مثال اضافه می کنیم که کدهای آن را در زیر مشاهده می کنید :

public class SQLiteConnectionProvider : NHibernate.Connection.DriverConnectionProvider
 {
 private static System.Data.IDbConnection m_Connection;

 public override System.Data.IDbConnection GetConnection()
 {
 if (m_Connection == null)
 m_Connection = base.GetConnection();
 return m_Connection;
 }

 public override void CloseConnection(System.Data.IDbConnection conn)
 {
 //Do nothing
 }
 }

همانطور که مشاهده می کنید انتخاب دیتابیس برای ذخیره داده ها هنگامی که از NHibernate استفاده می کنید کار آسانی است. پروژه مثال این مطالب با SQL Server، Oracle و SQLite با موفقیت آزمایش شده است. مستقل شدن از دیتابیس برای ذخیره داده های یک برنامه، ویژگی بسیار کارآمدی است که با استفاده از Castle ActiveRecord آسان و قابل دسترس است.

این مطلب آخرین قسمت سری آموزشی Castle ActiveRecord به همراه مثال بود اما باز هم در مورد آن در این وبلاگ مطلب خواهیم داشت. اگر خواننده این سری مطالب بودید، لطفاً نظر کلی خودتان را در قسمت نظرات همین پست با من در میان بگذارید.

پ.ن : برای دانلود پروژه مثال این سری مطالب باید چند روز صبر کنید تا کامل شود.

ویژگی جدید 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 باشیم.

یادگیری Castle ActiveRecord با مثال – قسمت ششم

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

نکته : اگر از گوگل ریدر یا هر فیدخوان دیگری استفاده می کنید و کدها را به درستی مشاهده نمی کنید، لطفاً مطلب اصلی را در وبلاگ بخوانید.

مشکل Select N+1 در ORMها

استفاده از یک ORM می تواند توسعه یک پروژه را بسیار سریع و آسان کند اما آگاهی نداشتن از برخی مسائل در مورد ORMها ممکن است باعث پایین آمدن شدید کارایی اپلیکیشن شما شود. یکی از مهم ترین و جدی ترین مشکلاتی که می تواند به شدت کارایی اپلیکیشن شما را پایین بیاورد، مشکل Select N+1 است. برای درک این مشکل بهتر است نمونه ای در مورد پروژه مثال کتاب فروشی ذکر شود. فرض کنید از Lazy Loading در سطح کلاس های این پروژه استفاده نمی کردیم، به نظر شما با اجرای یک خط کد زیر چه اتفاقی می افتد؟

Book[] books = Book.FindAll();

شاید منظورمان از نوشتن کد بالا این بوده که تمام کتاب ها را از دیتابیس بخوانیم، اما با این کار در واقع کل جدول های دیتابیس مان را خواهیم خواند! اجرای این خط باعث می شود تا برای هر کتاب، اطلاعات موضوعات، نویسنده، انتشارات، سفارشات و مشتریان هم از دیتابیس خوانده شوند. به این مشکل در ORMها، Select N+1 گفته می شود که خوشبختانه در Caslte ActiveRecord با تعریف رابطه ها به صورت Lazy قابل حل است.
در پروژه مثالی که مورد بررسی قرار گرفت تمام کلاس ها و تمام رابطه ها به صورت Lazy تعریف شده اند. برای تعریف یک کلاس به صورت Lazy کافیست تا صفت [ActiveRecord(Lazy=true)] را به آن اضافه کنید. با این کار شما باید تمام پراپرتی های کلاس را به صورت virtual تعریف کنید تا NHibernate بتواند در زمان اجرا، متد ها و پراپرتی های کلاس شما را override کند و فقط داده هایی را برای شما بارگذاری کند که واقعاً به آن ها نیاز دارید. فقط به این نکته توجه داشته باشید که Lazy Loading فقط زمانی ممکن است که یک Session در حافظه وجود داشته باشد، در غیر این صورت با یک استثنای NHibernate Lazy Initialization failure مواجه خواهید شد. برای اینکه با این استثنا مواجه نشوید می توانید در صورت نیاز از SessionScope در CAR استفاده کنید.

using (new SessionScope())
 {
 Category category = Category.Find(SelectedCategoryId);
 Books = Book.GetByCategory(category);
 }

Lazy Loading در سطح رابطه ها

فعال کردن Lazy Loading برای رابطه های یک موجودیت روی کارایی برنامه تاثیر بسیار زیادی دارد. Lazy مربوط به تمام رابطه ها به صورت پیش فرض برابر false است. برای رابطه های HasMany و HasAndBelongsToMany باید Lazy را برابر true و برای رابطه های BelongsTo صفت Lazy را برابر FetchWhen.OnInvoke قرار دهید. در این مورد نیز شما باید تمام پراپرتی ها و رابطه ها را به صورت virtual تعریف کنید. زمانی که یک رابطه مجموعه ای را به صورت Lazy تعریف می کنید، NHibernate تنها زمانی آیتم های آن را لود خواهد کرد که برنامه شما به یکی از اعضای آن دسترسی پیدا کند. در مورد رابطه های Lazy نیز حتماً باید یک SessionScope وجود داشته باشد تا NHibernate بتواند داده ها را فقط هر موقع نیاز بود برای شما لود کند.

لاگ کردن کدهای SQL تولید شده توسط NHibernate

برای اینکه بفهمیم Castle ActiveRecord چطور با دیتابیس حرف می زند و چه کارهایی در پشت پرده انجام می دهد تا ما از وجود دیتابیس بی خبر باشیم، می توانیم با استفاده از کامپوننت Log4net کوئری های SQL که توسط NHibernate ایجاد می شوند را به صورت فایل های log ذخیره و در صورت نیاز مشاهده کنیم. برای این کار شما باید به اسمبلی log4net.dll (که معمولاً همراه CAR هم وجود دارد) در پروژه خود ارجاع دهید. در مورد پروژه مثال ما که تحت ویندوز است، باید فایل App.config را به صورت زیر تغییر دهیم (در صورتی که از دات نت فریم ورک 4.0 استفاده می کنید) :

<?xml version="1.0"?>
<configuration>
 <configSections>
 <section name="activerecord"
 type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler,
 Castle.ActiveRecord"/>
 <section name="log4net"
 type="log4net.Config.Log4NetConfigurationSectionHandler,
 log4net" />
 </configSections>
 <startup useLegacyV2RuntimeActivationPolicy="true">
 <supportedRuntime version="v4.0" />
 </startup>
 <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=MyBookStore;Integrated Security=True;Pooling=False"/>
 <add key="proxyfactory.factory_class" value="NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle"/>
 </config>-->
 </activerecord>
 <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>

 <log4net>
 <appender name="trace" type="log4net.Appender.TraceAppender, log4net">
 <layout type="log4net.Layout.PatternLayout,log4net">
 <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] &amp;lt;%P{user}&amp;gt; - %m%n" />
 </layout>
 </appender>
 <appender name="console" type="log4net.Appender.ConsoleAppender, log4net">
 <layout type="log4net.Layout.PatternLayout,log4net">
 <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] &amp;lt;%P{user}&amp;gt; - %m%n" />
 </layout>
 </appender>
 <appender name="rollingFile" type="log4net.Appender.RollingFileAppender,log4net" >
 <param name="File" value="log.txt" />
 <param name="AppendToFile" value="true" />
 <param name="RollingStyle" value="Date" />
 <param name="DatePattern" value="yyyy.MM.dd" />
 <param name="StaticLogFileName" value="true" />
 <layout type="log4net.Layout.PatternLayout,log4net">
 <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] &amp;lt;%X{auth}&amp;gt; - %m%n" />
 </layout>
 </appender>
 <root>
 <priority value="ALL" />
 <appender-ref ref="rollingFile" />
 </root>
 </log4net>
</configuration>

هنگامی که show_sql را در تنظیمات CAR تغییر می دهیم، در واقع به NHibernate می فهمانیم که قصد مشاهده کدهای SQL تولیدی اش را داریم. برای اینکه log4net را برای انجام وظیفه اش آماده کنیم باید یک خط کد به فایل Program.cs پروژه خود اضافه کنیم. این خط کد را قبل از اجرای فرم اصلی برنامه در فایل Program.cs اضافه کنید :

log4net.Config.XmlConfigurator.Configure();

با انجام این تغییرات از این به بعد با هر بار اجرای برنامه یک فایل log.txt در کنار فایل اجرایی پروژه ایجاد خواهد شد که در آن تمام مسائل پشت پرده CAR و NHibernate ثبت خواهد شد. این فایل برای عیب یابی و مشاهده کوئری های اجرا شده توسط NHibernate بر روی دیتابیس کاربرد خواهد داشت. در واقع این فایل تمام اطلاعاتی را که برای Debug کردن یک پروژه مبتنی بر NHibernate نیاز است را در خود ذخیره می کند.

ایجاد فایل های نگاشت NHibernate از روی کلاس های CAR

هر چند Castle ActiveRecord شما را از فایل های کانفیگ XML معمول NHibernate بی نیاز می کند، اما اگر می خواهید بدانید که CAR چطور عملیات Mapping را برای شما انجام می دهد، می توانید از آن بخواهید تا فایل های Mapping را برای شما تولید کند. برای این کار باید حالت isDebug مربوط به CAR را در فایل کانفیگ خود برابر true قرار دهید تا CAR مجبور شود فایل های نگاشت NHibernate را در کنار پروژه شما تولید کند. در این صورت باید به قسمت تنظمیات Castle ActiveRecord در فایل App.config پروژه مثال خود صفت isDebug=»true» را اضافه کنید. پس از اجرای برنامه خواهید دید که فایل های Mapping توسط NHibernate در کنار پروژه شما به ازای هر کلاس ایجاد خواهد شد. این فایل ها برای مشاهده جزئیات نگاشت، پیدا کردن و رفع یک مشکل و یا حتی گزارش یک باگ به تیم NHibernate کاربرد دارد.

farasun.wordpress.com

این مطلب ادامه دارد…

برای اینکه مطالب بعدی را از دست ندهید، مشترک فید فراسان شوید!

یادگیری Castle ActiveRecord با مثال – قسمت پنجم

قسمت اول | قسمت دوم | قسمت سوم | قسمت چهارم

نکته : اگر از گوگل ریدر یا هر فیدخوان دیگری استفاده می کنید و کدها را به درستی مشاهده نمی کنید، لطفاً مطلب اصلی را در وبلاگ بخوانید.

اعتبار سنجی موجودیت ها در Castle ActiveRecord

یک ORM خوب بدون داشتن ویژگی Validation یا اعتبار سنجی کامل نیست. در Castle ActiveRecord با استفاده از کلاس ActiveRecordValidationBase می توان خصوصیات موجودیت ها را قبل از رسیدن به دیتابیس اعتبار سنجی کرد. برای این کار باید کلاس مورد نظر را از کلاس ActiveRecordValidationBase به جای کلاس ActiveRecordBase به ارث برد. با استفاده از امکانات موجود در فضای نام Castle.Components.Validator می توانید قوانین اعتبار سنجی مورد نظر خود را برای پراپرتی های کلاس خود تعریف کنید تا در صورت اشتباه بودن مقادیر وارد شده برای آن ها، آبجکت از ذخیره شدن اطلاعات در دیتابیس جلوگیری کند.   به مثال زیر توجه کنید :

[ActiveRecord(Table="Customers", Lazy=true)]
 public class Customer: ActiveRecordValidationBase<Customer>
 {
 [PrimaryKey(PrimaryKeyType.Native)]
 public virtual long ID { get; set; }

 [ValidateNonEmpty]
 [Property(NotNull=true, Length=250)]
 public virtual string Title { get; set; }

 [Property(Length=50)]
 public virtual string ContactNumber { get; set; }

 [ValidateEmail("Not like an email")]
 [Property(Length=250)]
 public virtual string Email { get; set; }

 [ValidateLength(10,400)]
 [Property(Length=400)]
 public virtual string Address { get; set; }
}

این همان کلاس Customer پروژه مثال MyBookStore است که این بار از کلاس ActiveRecordValidationBase به ارث برده شده است که دارای یک متد مهم به نام IsValid است. در فضای نام Castle.Components.Validator صفت های اعتبارسنجی معمول برای استفاده در سنارویوهای معمول وجود دارد که می توانید از آن ها برای انجام اعمال اعتبارسنجی در سطح موجودیت ها استفاده کنید. در اینجا از صفت ValidateNonEmpty برای اطمینان از خالی یا null نبودن مقدار پراپرتی Title، از صفت ValidateEmail برای اطمینان از صحت فرمت ایمیل وارد شده توسط کاربر و از ValidateLenght برای اعتبارسنجی طول رشته وارد شده کاربر برای پراپرتی Address استفاده شده است.

از Validatorهای مهم دیگر این کتابخانه می توان به ValidateIsUnique که چک می کند مقدار خصوصیت در دیتابیس وجود نداشته باشد، ValidateRegExp که چک می کند مقدار خصوصیت با یک Regular Expression هماهنگ باشد و ValidateIsGreater و ValidateIsLesser که مقدار خصوصیت را با مقدار خصوصیت دیگری از نظر بزرگتر یا کوچکتری مقایسه می کند، اشاره نمود.

اگر کاربر بخواهد مقدار نامعتبری را به هر یک از خصوصیت های این کلاس نبست دهد، یک استثنا رخ خواهد داد. برای جلوگیری از این موضوع شما باید اول مطمئن شوید که مقادیر وارد شده برای خصوصیات یک موجودیت با توجه به Validatorهای تعریف شده برای هر کدام، معتبر باشند. متد IsValid چک می کند که تمام اعتبار سنجی ها با موفقیت انجام شده اند و سپس True برمی گرداند.
ممکن است برخی نیازهای اعتبارسنجی شما برای تعریف به صورت Attribute یک خصوصیت مناسب نباشد. اگر اینطور بود می توانید متد IsValid را Override کنید و متد base را زمانی صدا بزنید که مطمئن شدید اعتبار سنجی شما با موفقیت انجام شده است. برای مثال می خواهیم مطمئن شویم که برای خصوصیت Title این کلاس حتماً بیشتر از 6 کاراکتر وارد شود :

public override bool IsValid()
 {
 if (Title.Length > 6)
 return base.IsValid();
 else
 return false;
 }

اگر هر کدام از مقادیر وارد شده برای پراپرتی های این کلاس با توجه به Validation تعریف شده برای آن ها، معتبر نباشد، یک استثنای ValidationException رخ خواهد داد. برای تغییر این رفتار می توانید متد NotIsValid این کلاس را بر اساس نیاز خود Override کنید.

همانطور که مشاهده کردید، استفاده از Validationها و تعریف اعتبارسنجی های سفارشی در سطح موجودیت ها در Castle ActiveRecord بسیار آسان در عین حال قدرتمند است. شما بر اساس نیاز پروژه خود می توانید پیچیده ترین اعتبار سنجی ها را با استفاده از امکانات این کتابخانه در سطح موجودیت های خود پیاده سازی کنید. این یکی از دلایل مهمی است که Castle ActiveRecord را در نظر من و بسیاری دیگر محبوب ساخته است.

farasun.wordpress.com

این مطلب ادامه دارد…

برای اینکه مطالب بعدی را از دست ندهید، مشترک فید فراسان شوید!

یادگیری Castle ActiveRecord با مثال – قسمت چهارم

قسمت اول | قسمت دوم | قسمت سوم

نکته : اگر از گوگل ریدر یا هر فیدخوان دیگری استفاده می کنید و کدها را به درستی مشاهده نمی کنید، لطفاً مطلب اصلی را در وبلاگ بخوانید.

از آنجا که در حال حاضر انجام آزمایش های واحد یا Unit Testing نقش مهمی را در توسعه یک نرم افزار ایفا می کند، در این قسمت می خواهیم نحوه نوشتن آزمایش واحد برای لایه دسترسی به داده هایی که با Castle ActiveRecord توسعه داده شده است را مورد بررسی قرار دهیم. برای این کار از فریم ورک اوپن سورس NUnit استفاده خواهیم کرد. قبل از هر کاری کتابخانه NUnit را از اینجا دریافت کنید. خواهید دید که انجام تست های واحد بر روی کلاس های Castle ActiveRecord به راحتی امکان پذیر است.

برای اینکه مطمئن شویم مدل برنامه مثال ما درست کار می کند، از تست واحد استفاده می کنیم. شاید بهتر بود قبل از نوشتن پست های قبلی، ابتدا تست واحد را می نوشتم اما به نظرم اینطوری توضیح دادن کدها مشکل تر بود. دست بکار شوید و یک پروژه جدید به نام MyBookStore.Test به Solution خود اضافه کنید و به فایل های Castle.ActiveRecord ، NHibernate.dll ، NUnit.Framework.dll و MyBookStore.Model.dll ارجاع دهید.

اگر خاطرتان باشد اولین کاری که پس از مشخص شدن مدل برنامه کردیم، راه اندازی اولیه CAR در هنگام اجرای برنامه بود. کلاس ActiveRecordStarter برای این مورد کاربرد دارد. در برنامه اصلی تنظیمات ActiveRecord را از فایل App.config خواندیم اما در اینجا می خواهیم از یک فایل جداگانه تنظمیات را بخوانیم چون قرار است تست واحد با استفاده از NUnit Test Runner اجرا شود. یک کلاس جدید به نام TestCase به این پروژه اضافه کنید و کدهای زیر را در آن بنویسید :

using System;
using System.Collections.Generic;
using NUnit.Framework;
using Castle.ActiveRecord;
using Castle.ActiveRecord.Framework;
using Castle.ActiveRecord.Framework.Config;
using MyBookStore.Model;

namespace MyBookStore.Test
{
[TestFixture]
 public class TestCase
 {

 [TestFixtureSetUp]
 public virtual void FixtureSetup()
 {
 IConfigurationSource configSource =
 new XmlConfigurationSource("ActiveRecordConfig.xml");
 ActiveRecordStarter.Initialize(typeof(Book).Assembly,configSource);
 }

 [SetUp]
 public virtual void OneTimeSetup()
 {
 ActiveRecordStarter.DropSchema();
 ActiveRecordStarter.CreateSchema();
 }

 [Test]
 public void InsertMyBook()
 {
 using (new SessionScope())
 {
 Book book = new Book()
 {
 Title = "Learn Castle ActiveRecord",
 BuyPrice = 1000,
 SalePrice = 2000
 };
 Category category = new Category() { Title = "ORM" };
 category.Create();
 Author author = new Author() { Title = "Iman Nemati" };
 author.Create();
 Publisher publisher = new Publisher() { Title = "Farasun" };
 publisher.Create();
 book.Categories = new List<Category>();
 book.Categories.Add(category);
 book.Author = author;
 book.Publisher = publisher;
 book.Create();
 Book[] books = Book.FindAll();
 Assert.AreEqual(1, books.Length);
 Assert.AreEqual("Iman Nemati", books[0].Author.Title);
 }
 }
 }
}
}

پروژه را کامپایل کنید تا اسمبلی MyBookStore.Test ساخته شود. حالا یک فایل XML به نام ActiveRecordConfig.xml با محتویات زیر به پروژه خود اضافه کنید :

<?xml version="1.0" encoding="utf-8" ?>
<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=MyBookStoreTest;Integrated Security=True;Pooling=False"/>
<add key="proxyfactory.factory_class" value="NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle"/>
</config>
</activerecord>

بر روی این فایل کلیک راست کنید و گزینه Properties را کلیک کنید و خاصیت  Copy to Output Directory را برابر Copy always قرار دهید. برای انجام تست واحد نیاز به یک دیتابیس جدا از دیتابیس اصلی داریم. برای این کار در Server Explorer دیتابیس جدیدی به نام MyBookStoreTest بسازید و اگر نیاز است تغییراتی در فایل Config بالا اعمال کنید تا مشکلی پیش نیاید. بعد از اتمام این کار، NUnit Test Runner را اجرا کنید. این فایل معمولاً در مسیر کتابخانه ای که دانلود کرده اید قرار دارد. پس از اجرای این برنامه، از منوی File گزینه Open Project را برگزینید و فایل اسمبلی MyBookStore.Test.dll در مسیر bin\Debug پروژه خود را انتخاب کنید. پس از این کار باید متدهای تست برنامه خود را مشاهده کنید. در اینجا ما فقط یک تست واحد نوشتیم که یک موجودیت Book را با خاصیت ها و روابط مشخص شده در دیتابیس ایجاد می کند و سپس چک می کند که آیا این موجودیت با موفقیت به دیتابیس اضافه شده است یا نه و بعد از آن نام نویسنده را با رشته مورد انتظار ما مقایسه می کند تا از صحت اطلاعات درج شده اطمینان پیدا کنیم. اگر تمام کارها را به درستی انجام داده باشید با کلیک روی دکمه Run، تست واحد شما با موفقیت Pass خواهد شد.

این تست چطور کار می کند؟

اگر با انجام تست واحد آشنایی دارید می توانید این بخش را نخوانید. کلاس TestCase با خاصیت TestFixture همراه شده که این مشخص می کند این کلاس دارای متدهایی برای تست است. متد FixtureSetup همانطور که از نامش مشخص است و با توجه به خاصیت TestFixtureSetup که برای آن تعریف شده، وظیفه مقداردهی های اولیه برای متدهای تست کلاس را بر عهده دارد و فقط یکبار در طول تست اجرا می شود. متد OneTimeSetup نیز که با خاصیت SetUp مشخص شده فقط یکبار برای تمام تست ها اجرا خواهد شد. متد InsertMyBook که با خاصیت Test مشخص شده، متدی است که Fail یا Pass شدن آن برای ما مهم است. در این متد با استفاده از Assert می توان شرط های مختلفی را آزمایش کرد تا از صحت کارکرد متد مطمئن شد. شما می توانید غیر از این متد، متدهای دیگری نیز با مشخصه Test به این کلاس اضافه کنید و تست های واحد خود را برای متدهای مختلف بنویسید.

farasun.wordpress.com

این مطلب ادامه دارد…

برای اینکه مطالب بعدی را از دست ندهید، مشترک فید فراسان شوید!