مطالب
ارتقاء به NH 3.2 - قسمت دوم

پیشتر مطلبی را در مورد 18 مقاله‌ای که اکثر حالت‌های Mapping موجود در NHibernate را خلاصه کرده بود، مطالعه کردید.
یک مورد هم در این مطلب به نظر در مقایسه با Fluent NHibernate درنظر گرفته نشده است و آن هم بحث AutoMapping است. Fluent NHibernate این قابلیت را دارد که بر اساس تعاریف کلاس‌های شما و روابط بین آن‌ها به صورت خودکار نگاشت‌ها را تشکیل دهید. یعنی خودش مباحث ارتباط‌های یک به چند و چند به چند و غیره را در پشت صحنه به صورت خودکار تولید کند؛ بدون حتی یک سطر کدنویسی اضافی. فقط حداکثر یک سری IAutoMappingOverride و همچنین تعدادی Convention نامگذاری را هم می‌توان جهت تنظیمات این سیستم تمام خودکار اعمال کرد. مثلا توسط IAutoMappingOverride، یکی از خاصیت‌های کلاس را به صورت Unique معرفی کرد و مابقی هم به صورت خودکار توسط قابلیت Autommaping نگاشت می‌شوند. یا توسط Convention نامگذاری سفارشی خود، به Fluent NHibernate اعلام می‌کنیم که من علاقمندم نام مثلا کلیدهای خارجی تشکیل شده بجای اعدادی منحصربفرد، از روش ویژه‌ای که تعیین می‌کنم، ساخته شوند. اینجا است که به نظر من کار با NHibernate حتی از Entity framework هم ساده‌تر است (یا ساده‌تر شده است).
قابلیت AutoMapping یاد شده، در سیستم جدید توکار Mapping by code هم وجود دارد. فقط چون جایی به صورت درست و درمان مستند نشده، همه دور خودشان می‌چرخند! به همین جهت مثالی را در این زمینه آماده کردم که موارد زیر را پوشش می‌دهد:
- نحوه اعمال تنظیمات بانک اطلاعاتی با کدنویسی در NH3,2
- نحوه یکپارچه سازی این روش جدید با کتابخانه NHibernate Validator
- استفاده از NHibernate Validator جهت تنظیم طول فیلدهای بانک اطلاعاتی تولیدی به صورت خودکار
- نحوه تعریف قراردادهای نامگذاری ویژه (مثلا نام جداول تولید شده به صورت خودکار،‌ برخلاف نام موجودیت‌ها، جمع باشد نه مفرد)
- اضافه کردن قابلیت تشخیص many-to-many به auto-mapping موجود در NH3,2 (برای تشخیص این مورد به کمک امکانات مهیای پیش فرض NH3,2، باید اندکی کدنویسی کرد)
- نحوه بازنویسی قراردادهای پیش فرض auto-mapping. مثلا اگر قرار باشد همه چیز خودکار شود اما یکی از فیلدها به صورت unique معرفی شود چکار باید کرد.
- نحوه ذخیره اطلاعات mapping کامپایل شده در فایل فایل و سپس بارگذاری خودکار آن در حین اجرای برنامه جهت بالا بردن سرعت بارگذاری اولیه برنامه.



مطالب
اعمال تغییرات سفارشی به ویژگی AutoMapping در Fluent NHibernate

با کمک Fluent NHibernate می‌توان نگاشت‌ها را به دو صورت خودکار و یا دستی تعریف کرد. در حالت خودکار، روابط بین کلاس‌ها بررسی شده و بدون نیاز به تعریف هیچگونه ویژگی (attribute) خاصی بر روی فیلدها، امکان تشخیص خودکار حالت‌های کلید خارجی، روابط یک به چند، چند به چند و امثال آن وجود دارد. یا اگر نیاز باشد تا اسکریپت تولیدی جهت به روز رسانی بانک اطلاعاتی، طول خاصی را به فیلدی اعمال کند می‌توان از ویژگی‌های NHibernate validator استفاده کرد؛ مانند تعریف طول و نال نبودن یک فیلد که علاوه بر بکارگیری اطلاعات آن در حین تعیین اعتبار ورودی دریافتی، بر روی نحوه‌ی به روز رسانی بانک اطلاعاتی هم تاثیر گذار است:
public class Product
{
public virtual int Id { set; get; }

[Length(120)]
[NotNullNotEmpty]
public virtual string Name { get; set; }

public virtual decimal UnitPrice { get; set; }
}
این نگاشت خودکار یا AutoMapping ،‌ تقریبا در 90 درصد موارد کافی است. فیلد Id را بر اساس یک سری پیش فرض‌هایی که این مورد هم قابل تنظیم است به صورت primary key تعریف می‌کند، طول فیلدها و نحوه‌ی پذیرفتن نال آن‌ها، از ویژگی‌های NHibernate validator گرفته می‌شود و روابط بین کلاس‌ها به صورت خودکار به روابط یک به چند و مانند آن ترجمه می‌شود و نیازی نیست تا کلاسی جداگانه را جهت مشخص سازی صریح این موارد تهیه کرد، یا ویژگی مشخص کننده‌ی دیگری را به فیلدها افزود. اما اگر برای مثال بخواهیم در این کلاس فیلد Name را به صورت Unique معرفی کنیم چه باید کرد؟ به عبارتی تمام آنچه‌ که ویژگی AutoMapping در Fluent NHibernate انجام می‌دهد، بسیار هم عالی؛ اما فقط می‌خواهیم مقادیر یک فیلد منحصربفرد باشد. برای این منظور اینترفیس IAutoMappingOverride تدارک دیده شده است:
public class ProductCustomMappings : IAutoMappingOverride<Product>
{
public void Override(AutoMapping<Product> mapping)
{
mapping.Id(u => u.Id).GeneratedBy.Identity(); //ضروری است
mapping.Map(p => p.Name).Unique();
}
}
در حالت استفاده از اینترفیس IAutoMappingOverride مشخص سازی نحوه‌ی تولید primary key ضروری است و سپس برای نمونه، فیلد Name به صورت منحصربفرد تعریف می‌گردد. در اینجا کل عملیات هنوز از روش AutoMapping پیروی می‌کند اما فیلد Name علاوه بر اعمال ویژگی‌های NHibernate validator، به صورت منحصربفرد نیز معرفی خواهد شد.

مسیرراه‌ها
NHibernate
      نظرات مطالب
      آشنایی با NHibernate - قسمت ششم
      تشخیص روابط بین جداول یعنی همان mapping خودکار،‌ یعنی همان نحوه‌ی تعریف کلاس‌های شما و برقراری روابطی که در طی چند قسمت مثال زده شد. سیستم پیش فرض NHibernate بر اساس اول طراحی کلاس‌ها و بعد ایجاد ارتباط با دیتابیس است که اینجا به صورت خودکار صورت می‌گیرد.
      برای مثال در قسمت هشتم یک سیستم many-to-many مثال زده شده است به همراه کوئری‌هایی از نوع Linq . اینجا فقط تعریف کلاس‌هایی که بیانگر روابط many-to-many باشند مهم است؛ نحوه‌ی نگاشت خودکار آن‌ها به دیتابیس کار Fluent NHibernate است. (از این نوع مثال‌ها در هر قسمت پیاده سازی شده)
      جزئیات ریز نحوه‌ی نگاشت خودکار با مطالعه‌ی سورس کتابخانه NHibernate و مشتقات آن قابل درک است (برای علاقمندان).
      ضمنا فرقی نمی‌کند از Linq قسمت پنجم استفاده کنید یا هر روش موجود دیگری برای کوئری گرفتن (زمانیکه Linq هست و نگارش‌های جدید آن برای NHibernate پیشرفت زیادی داشته، چرا روش‌های دیگر؟).
      مطالب
      NH 3.2 و تاثیر آن بر آینده‌ی FHN

      در این عنوان، NH همان NHibernate است و FHN همان Fluent NHibernate

      نگارش آزمایشی NH 3.2 هم اکنون در دسترس است و یکی از مهمترین مباحثی را که پوشش داده، جایگزین کردن فایل‌های XML تهیه نگاشت‌ها با کدنویسی است. دقیقا چیزی شبیه به Fluent NHibernate البته اینبار از یک کتابخانه دیگر به نام ConfOrm کدها یکی شده‌اند.
      باید توجه داشت که نگارش 3.2 خاصیت AutoMapping مربوط به FHN را پشتیبانی نمی‌کند (یا هنوز در این نگارش به این حد نرسیده است)، بنابراین نمی‌تواند جایگزین صد در صدی برای FHN باشد اما باز هم تا حدود 75 درصد کار FHN را پوشش می‌دهد و می‌تواند علاقمندان را از این وابستگی خارجی (!) نجات دهد.
      و ... این مساله نویسنده‌ی اصلی FHN را کمی دلگیر کرده است که آیا FHN را ادامه دهد یا خیر. اصل مطلب رو می‌تونید اینجا بخونید.
      نظر بعضی‌ها هم در این بین این بوده!
      ConfOrm looks like lipstick on a pig as far as fluent interfaces go

      مطالب
      نحوه‌ی نگاشت فیلدهای فرمول در Fluent NHibernate

      اگر با SQL Server کار کرده باشید حتما با مفهوم و امکان Computed columns (فیلدهای محاسبه شده) آن آشنایی دارید. چقدر خوب می‌شد اگر این امکان برای سایر بانک‌های اطلاعاتی که از تعریف فیلدهای محاسبه شده پشتیبانی نمی‌کنند، نیز مهیا می‌شد. زیرا یکی از اهداف مهم استفاده‌ی صحیح از ORMs ، مستقل شدن برنامه از نوع بانک اطلاعاتی است. برای مثال امروز می‌خواهیم با MySQL‌ کار کنیم، ماه بعد شاید بخواهیم یک نسخه‌ی سبک‌تر مخصوص کار با SQLite را ارائه دهیم. آیا باید قسمت دسترسی به داده برنامه را از نو بازنویسی کرد؟ اینکار در NHibernate فقط با تغییر نحوه‌ی اتصال به بانک اطلاعاتی میسر است و نه بازنویسی کل برنامه (و صد البته شرط مهم و اصلی آن هم این است که از امکانات ذاتی خود NHibernate استفاده کرده باشید. برای مثال وسوسه‌ی استفاده از رویه‌های ذخیره شده را فراموش کرده و به عبارتی ORM مورد استفاده را به امکانات ویژه‌ی یک بانک اطلاعاتی گره نزده باشید).
      خوشبختانه در NHibernate امکان تعریف فیلدهای محاسباتی با کمک تعریف نگاشت خواص به صورت فرمول مهیا است. برای توضیحات بیشتر لطفا به مثال ذیل دقت بفرمائید:
      در ابتدا کلاس کاربر تعریف می‌شود:

      using System;
      using NHibernate.Validator.Constraints;

      namespace FormulaTests.Domain
      {
      public class User
      {
      public virtual int Id { get; set; }

      [NotNull]
      public virtual DateTime JoinDate { set; get; }

      [NotNullNotEmpty]
      [Length(450)]
      public virtual string FirstName { get; set; }

      [NotNullNotEmpty]
      [Length(450)]
      public virtual string LastName { get; set; }

      [Length(900)]
      public virtual string FullName { get; private set; } //از طریق تعریف فرمول مقدار دهی می‌گردد

      public virtual int DayOfWeek { get; private set; }//از طریق تعریف فرمول مقدار دهی می‌گردد
      }
      }
      در این کلاس دو خاصیت FullName و DayOfWeek به صورت فقط خواندنی به کمک private set ذکر شده، تعریف گردیده‌اند. قصد داریم روی این دو خاصیت فرمول تعریف کنیم:

      using FluentNHibernate.Automapping;
      using FluentNHibernate.Automapping.Alterations;

      namespace FormulaTests.Domain
      {
      public class UserCustomMappings : IAutoMappingOverride<User>
      {
      public void Override(AutoMapping<User> mapping)
      {
      mapping.Id(u => u.Id).GeneratedBy.Identity(); //ضروری است
      mapping.Map(x => x.DayOfWeek).Formula("DATEPART(dw, JoinDate) - 1");
      mapping.Map(x => x.FullName).Formula("FirstName + ' ' + LastName");
      }
      }
      }
      نحوه‌ی انتساب فرمول‌های مبتنی بر SQL را در نگاشت فوق ملاحظه می‌نمائید. برای مثال FullName از جمع دو فیلد نام و نام خانوادگی حاصل خواهد شد و DayOfWeek از طریق فرمول SQL دیگری که ملاحظه می‌نمائید (یا هر فرمول SQL دلخواه دیگری که صلاح می‌دانید).
      اکنون اگر Fluent NHibernate را وادار به تولید اسکریپت متناظر با این دو کلاس کنیم حاصل به صورت زیر خواهد بود:
          create table Users (
      UserId INT IDENTITY NOT NULL,
      JoinDate DATETIME not null,
      FirstName NVARCHAR(450) not null,
      LastName NVARCHAR(450) not null,
      primary key (UserId)
      )
      همانطور که ملاحظه می‌کنید در اینجا خبری از دو فیلد محاسباتی تعریف شده نیست. این فیلدها در تعاریف نگاشت‌ها به صورت خودکار ظاهر می‌شوند:
      <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
      default-access="property" auto-import="true" default-cascade="none" default-lazy="true">
      <class xmlns="urn:nhibernate-mapping-2.2" mutable="true"
      name="FormulaTests.Domain.User, FormulaTests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" table="Users">
      <id name="Id" type="System.Int32" unsaved-value="0">
      <column name="UserId" />
      <generator class="identity" />
      </id>
      <property name="DayOfWeek" formula="DATEPART(dw, JoinDate) - 1" type="System.Int32" />
      <property name="FullName" formula="FirstName + ' ' + LastName" type="System.String" />
      <property name="JoinDate" type="System.DateTime">
      <column name="JoinDate" />
      </property>
      <property name="FirstName" type="System.String">
      <column name="FirstName" />
      </property>
      <property name="LastName" type="System.String">
      <column name="LastName" />
      </property>
      </class>
      </hibernate-mapping>
      اکنون اگر کوئری زیر را در برنامه اجرا نمائیم:
      var list = session.Query<User>.ToList();
      foreach (var item in list)
      {
      Console.WriteLine("{0}:{1}", item.FullName, item.DayOfWeek);
      }
      به صورت خودکار به SQL ذیل ترجمه خواهد شد و اکنون نحوه‌ی بکارگیری فیلدهای فرمول، بهتر مشخص می‌گردد:
      select
      user0_.UserId as UserId0_,
      user0_.JoinDate as JoinDate0_,
      user0_.FirstName as FirstName0_,
      user0_.LastName as LastName0_,
      DATEPART(user0_.dw, user0_.JoinDate) - 1 as formula0_, --- همان فرمول تعریف شده است
      user0_.FirstName + ' ' + user0_.LastName as formula1_ ---از طریق فرمول تعریف شده حاصل گردیده است
      from
      Users user0_

      مطالب
      NHibernate 3.2

      نگارش نهایی NHibernate 3.2 مدتی است که ارائه شده و به همراه آن قابلیت‌هایی همانند Fluent NHibernate جهت حذف فایل‌های XML ایی تعریف نگاشت‌ها به کمک کد نویسی هم وجود دارد. در حال حاضر آنچنان مطالب خودآموز قابل توجهی را در این مورد نمی‌توان یافت ولی در کل دو ویدیوی مقدماتی زیر می‌توانند کمک خوبی جهت شروع به کار با این امکان جدید باشند:



      ماخذ

      مطالب
      ارتقاء به NHibernate 3.2

      شروع به کار با NH به دو قسمت تقسیم می‌شود. یک قسمت نگاشت کلا‌س‌ها است و قسمت دوم سشن گردانی آن. قسمت دوم آن به همان مباحث کلاس‌های singleton ایی که بحث آن‌ها در سایت هست بر می‌گردد. یا حتی استفاده از کتابخانه‌های IOC برای مدیریت آن (که این پیاده سازی را به صورت توکار هم دارند).
      قسمت نگاشت کلاس‌ها در NH انواع و اقسامی دارد:
      • ابتدا همان فایل‌های XML مدل Hibernate جاوا بود.
      • بعد شد مدل annotation ایی به نام Castle ActiveRecord. (این پروژه آنچنان فعال نیست و علتش به این بر می‌گردد که نویسنده اصلی جذب مایکروسافت شده)
      • سپس Fluent NHibernate پدید آمد. (این پروژه هم پس از NH 3.2 ، سرد شده و به نظر آنچنان فعال نیست)
      • الان هم مدل جدیدی به صورت توکار و بدون نیاز به کتابخانه‌های جانبی از NH 3.2 به بعد به آن اضافه شده به نام mapping-by-code .
      بنابراین روش مرجح از NH 3,2 به بعد، همین روش mapping-by-code توکار آن است. خصوصا اینکه نیاز به وابستگی خارجی ندارد. برای مثال به دلیل عدم فعال بودن پروژه‌هایی که نام برده شد، مثلا NH 3,3 امروز ارائه می‌شود، شاید دو ماه بعد، این کتابخانه‌های جانبی ساده سازی نگاشت‌ها، به روز شوند یا نشوند.

      و ... خبر خوب اینکه شخصی در 18 قسمت به توضیح این قابلیت جدید mapping by code پرداخته و روش‌های نگاشت مرتبط رو با مثال توضیح داده که در آدرس زیر می‌تونید اون‌ها رو پیدا کنید:



      مطالب
      فیلدهای پویا در NHibernate

      یکی از قابلیت‌های جالب NHibernate امکان تعریف فیلدها به صورت پویا هستند. به این معنا که زیرساخت طراحی یک برنامه "فرم ساز" هم اکنون در اختیار شما است! سیستمی که امکان افزودن فیلدهای سفارشی را دارا است که توسط برنامه نویس در زمان طراحی اولیه آن ایجاد نشده‌اند. در ادامه نحوه‌ی تعریف و استفاده از این قابلیت را توسط Fluent NHibernate بررسی خواهیم کرد.

      در اینجا کلاسی که قرار است توانایی افزودن فیلدهای سفارشی را داشته باشد به صورت زیر تعریف می‌شود:
      using System.Collections;

      namespace TestModel
      {
      public class DynamicEntity
      {
      public virtual int Id { get; set; }
      public virtual IDictionary Attributes { set; get; }
      }
      }

      Attributes در عمل همان فیلدهای سفارشی مورد نظر خواهند بود. جهت معرفی صحیح این قابلیت نیاز است تا نگاشت آن‌را از نوع dynamic component تعریف کنیم:
      using FluentNHibernate.Automapping;
      using FluentNHibernate.Automapping.Alterations;

      namespace TestModel
      {
      public class DynamicEntityMapping : IAutoMappingOverride<DynamicEntity>
      {
      public void Override(AutoMapping<DynamicEntity> mapping)
      {
      mapping.Table("tblDynamicEntity");
      mapping.Id(x => x.Id);
      mapping.IgnoreProperty(x => x.Attributes);
      mapping.DynamicComponent(x => x.Attributes,
      c =>
      {
      c.Map(x => (string)x["field1"]);
      c.Map(x => (string)x["field2"]).Length(300);
      c.Map(x => (int)x["field3"]);
      c.Map(x => (double)x["field4"]);
      });
      }
      }
      }
      و مهم‌ترین نکته‌ی این بحث هم همین نگاشت فوق است.
      ابتدا از IgnoreProperty جهت ندید گرفتن Attributes استفاده کردیم. زیرا درغیراینصورت در حالت Auto mapping ، یک رابطه چند به یک به علت وجود IDictionary به صورت خودکار ایجاد خواهد شد که نیازی به آن نیست (یافتن این نکته نصف روز کار برد ....! چون مرتبا خطای An association from the table DynamicEntity refers to an unmapped class: System.Collections.Idictionary ظاهر می‌شد و مشخص نبود که مشکل از کجاست).
      سپس Attributes به عنوان یک DynamicComponent معرفی شده است. در اینجا چهار فیلد سفارشی را اضافه کرده‌ایم. به این معنا که اگر نیاز باشد تا فیلد سفارشی دیگری به سیستم اضافه شود باید یکبار Session factory ساخته شود و SchemaUpdate فراخوانی گردد و خوشبختانه با وجود Fluent NHibernate ، تمام این تغییرات در کدهای برنامه قابل انجام است (بدون نیاز به سر و کار داشتن با فایل‌های XML نگاشت‌ها و ویرایش دستی آن‌ها). از تغییر نام جدول که برای مثال در اینجا tblDynamicEntity در نظر گرفته شده تا افزودن فیلدهای دیگر در قسمت DynamicComponent فوق.
      همچنین باتوجه به اینکه این نوع تغییرات (ساخت دوبار سشن فکتوری) مواردی نیستند که قرار باشد هر ساعت انجام شوند، بنابراین سربار آنچنانی را به سیستم تحمیل نمی‌کنند.
         drop table tblDynamicEntity

      create table tblDynamicEntity (
      Id INT IDENTITY NOT NULL,
      field1 NVARCHAR(255) null,
      field2 NVARCHAR(300) null,
      field3 INT null,
      field4 FLOAT null,
      primary key (Id)
      )

      اگر با SchemaExport، اسکریپت خروجی معادل با نگاشت فوق را تهیه کنیم به جدول فوق خواهیم رسید. نوع و طول این فیلدهای سفارشی بر اساس نوعی که برای اشیاء دیکشنری مشخص می‌کنید، تعیین خواهند شد.

      چند مثال جهت کار با این فیلدهای سفارشی یا پویا :

      نحوه‌ی افزودن رکوردهای جدید بر اساس خاصیت‌های سفارشی:
      //insert
      object savedId = 0;
      using (var session = sessionFactory.OpenSession())
      {
      using (var tx = session.BeginTransaction())
      {
      var obj = new DynamicEntity();
      obj.Attributes = new Hashtable();
      obj.Attributes["field1"] = "test1";
      obj.Attributes["field2"] = "test2";
      obj.Attributes["field3"] = 1;
      obj.Attributes["field4"] = 1.1;

      savedId = session.Save(obj);
      tx.Commit();
      }
      }

      با خروجی
      INSERT
      INTO
      tblDynamicEntity
      (field1, field2, field3, field4)
      VALUES
      (@p0, @p1, @p2, @p3);
      @p0 = 'test1' [Type: String (0)], @p1 = 'test2' [Type: String (0)], @p2 = 1
      [Type: Int32 (0)], @p3 = 1.1 [Type: Double (0)]

      نحوه‌ی کوئری گرفتن از این اطلاعات (فعلا پایدارترین روشی را که برای آن یافته‌ام استفاده از HQL می‌باشد ...):
      //query
      using (var session = sessionFactory.OpenSession())
      {
      using (var tx = session.BeginTransaction())
      {
      //using HQL
      var list = session
      .CreateQuery("from DynamicEntity d where d.Attributes.field1=:p0")
      .SetString("p0", "test1")
      .List<DynamicEntity>();

      if (list != null && list.Any())
      {
      Console.WriteLine(list[0].Attributes["field2"]);
      }
      tx.Commit();
      }
      }
      با خروجی:
          select
      dynamicent0_.Id as Id1_,
      dynamicent0_.field1 as field2_1_,
      dynamicent0_.field2 as field3_1_,
      dynamicent0_.field3 as field4_1_,
      dynamicent0_.field4 as field5_1_
      from
      tblDynamicEntity dynamicent0_
      where
      dynamicent0_.field1=@p0;
      @p0 = 'test1' [Type: String (0)]

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

      نحوه‌ی به روز رسانی و حذف اطلاعات بر اساس فیلدهای پویا:
      //update
      using (var session = sessionFactory.OpenSession())
      {
      using (var tx = session.BeginTransaction())
      {
      var entity = session.Get<DynamicEntity>(savedId);
      if (entity != null)
      {
      entity.Attributes["field2"] = "new-val";
      tx.Commit(); // Persist modification
      }
      }
      }

      //delete
      using (var session = sessionFactory.OpenSession())
      {
      using (var tx = session.BeginTransaction())
      {
      var entity = session.Get<DynamicEntity>(savedId);
      if (entity != null)
      {
      session.Delete(entity);
      tx.Commit();
      }
      }
      }

      نظرات مطالب
      آشنایی با NHibernate - قسمت اول
      در NHibernate سنتی کار ساخت نگاشت‌ها توسط یک سری فایل xml صورت می‌گیرد که ممکن است حین تهیه اولیه پر از اشتباهات تایپی و غیره باشند.این نوع فایل‌ها تحت کنترل کامپایلر نبوده و در حین کار مشکلات آن‌ها مشخص می‌شود.
      در Fluent NHibernate کار تعریف نگاشت‌ها با استفاده از کدهای strongly typed دات نتی صورت می‌گیرد که بلافاصله تحت کنترل کامپایلر هستند. همچنین مبحث Auto Mapping آن را می‌توانید در قسمت‌های بعد مطالعه کنید. امکان unit test نوشتن برای نگاشت‌های این روش بدون حتی درج یک رکورد در دیتابیس میسر است که باز هم در طی چند قسمت به آن پرداخته شده. با توجه به اینکه در روش دوم تعریف نگاشت‌ها، بلافاصله تحت نظر کامپایلر است امکان refactoring ساده‌تر آن نیز مهیا است.
      در روش Fluent اگر علاقمند بودید که این فایل‌های XML را هم مشاهده کنید به قسمت Mappings در Fluently.Configure خود، متد ExportTo را اضافه کنید.