مقایسه تجربی 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 به همراه مثال بود اما باز هم در مورد آن در این وبلاگ مطلب خواهیم داشت. اگر خواننده این سری مطالب بودید، لطفاً نظر کلی خودتان را در قسمت نظرات همین پست با من در میان بگذارید.

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

یادگیری 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

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

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