ممنون. الگوهای طراحی برنامه نویسی شیءگرا یک حالت عمومی دارند. یعنی مختص به یک فناوری یا زبان خاص یا حتی یک محصول خاص نیستند. بگردید برای LINQ to SQL هم پیاده سازی الگوی Repository وجود دارد.
کلا استفاده‌ی از هر کدام از ORMs موجود بدون پیاده سازی الگوی Repository اشتباه است. به چند دلیل:
- مخفی کردن ساز و کار درونی یک ORM : برای مثال من جدا قصد ندارم این رو حفظ کنم که فلان ORM خاص چطور Insert انجام می‌دهد. من فقط می‌خواهم یک متد Insert داشته باشم. یکبار این رو در الگوی Repository پیاده سازی می‌کنم و بعد فراموش می‌کنم که این ORM الان EF است یا NH یا هرچی
- امکان تعویض کلی یک ORM : زمانیکه من در کدهای BLL خودم فقط از متد Insert پیاده سازی شده مطابق رهنمون‌های الگوی Repository استفاده کردم، دیگر BLL درکی از ORM نخواهد داشت. برای کوچ کردن به یک ORM دیگر فقط کافی است تا Repository را عوض کرد. مابقی برنامه دست نخورده باقی می‌ماند.
- نوشتن Unit test با استفاده از الگوی Repository ساده‌تر است: این الگو چون بر مبنای یک Interface پیاده سازی می‌شود، امکان Mocking این Interface در Unit tests ساده‌تر است.

سلام،
زمانیکه با ORM هایی از نوع Code First کار می‌کنید مثل NHibernate یا مثل نگارش بعدی Entity framework ، ذهن خودتون رو از وجود جداول حاضر در بانک اطلاعاتی خالی کنید. جدولی به نام CoursesToStudents توسط ساز و کار درونی NHibernate‌ مدیریت خواهد شد و لزومی ندارد برنامه در مورد آن اطلاعاتی داشته باشد.
موردی را که شما نیاز دارید کلاسی است به نام نتایج دوره؛ مثلا چیزی به نام CourseResult . این کلاس ارجاعاتی را به شیء دانشجو و شیء دوره دارد، به همراه نمره نهایی یا مثلا خاصیت قبول شده و برای مثال تاریخ امتحان و خواص دیگری که صلاح می‌دانید.
زمانیکه NHibernate اسکریپت اعمال این نگاشت‌ها را تشکیل دهد (توسط امکانات کلاس SchemaExport که در مطلب بالا ذکر شده)، در جدول نهایی بانک اطلاعاتی شما به ازای ارجاعات به اشیاء یاد شده، یک کلید خارجی خواهید داشت. این کلاس جدید تاثیری روی سایر روابط ندارد.

حق با شما است. روش صحیح لایه بندی این قسمت بر اساس تعریف unit of work و سپس repository است. یک unit of work می‌تواند از اعمال حاصل چندین repository تشکیل شده و نهایتا در پایان کار همه را یکجا اعمال کند. در مثال فوق این دو مفهوم با هم تلفیق شده.
بنابراین اگر علمی‌تر می‌خواهید کار کنید در مورد unit of work تحقیق کنید (در سایت nhforge.org).

ابزار حرفه‌ای مشاهده خروجی NHibernate برنامه زیر است (که در جهت دیباگ کار بسیار مفید است):
NHProf
کار کردن با آن هم بسیار ساده است. فایل How to use.txt آن‌را مطالعه کنید..

این مورد اصلا ربطی به using , try/catch و غیره ندارد. نیاز به solution کار شما است (با تمام کلاس‌ها و نگاشت و غیره) تا بتوان آن‌را دیباگ کرد. بهترین روش هم این است که خروجی SQL تولید شده را بررسی کنید تا متوجه شوید مشکل کار در کجاست.

سلام،
کاری را که شما دارید انجام می‌دید اشتباه است.
Using statement در سی شارپ به صورت خودکار به try/finally به همراه dispose شیء احاطه شده توسط آن ترجمه می‌شود. (+)
به عبارتی شما یک try/finally را در یک سطح بالاتر دارید و داخل آن یک try/catch قرار داده‌اید. اینکار صحیح نیست. Using را حذف کنید و try/catch/finally را جایگزین تمام موارد اضافه شده کنید.
ضمنا توصیه من این است که فقط try/catch را حذف کنید. Using سرجایش باشد تا هدف اصلی آن یعنی dispose اشیاء مرتبط حتما رخ دهد.
به تمام برنامه نویس‌ها آموزش داده می‌شود که exception handling چیست اما در پایان فصل به آن‌ها آموخته نمی‌شود که لطفا تا حد امکان از آن استفاده نکنید! بله، لطفا در استفاده از آن خساست به خرج دهید. چرا؟ چون کرش بر خلاف تصور عمومی چیز خوبی است! زمانیکه شما این try/catch را قرار دادید، flow برنامه متوجه نخواهد شد که در مرحله‌ی قبل مشکلی رخ داده و از ادامه برنامه و خسارت وارد کردن به سیستم جلوگیری کند. ضمنا این را هم به خاطر داشته باشید که exception ها در دات نت حبابی هستند. یعنی به فراخوان خود منتشر خواهند شد و در یک سطح بالاتر هم قابل catch هستند (با تمام جزئیات).

با سلام
و با تشکر از لطف دوستان.

بله. بنده در سایت‌های social به دلایل شخصی حضور ندارم. از لطف شما سپاسگزارم.

لطفا این سری را مطالعه بفرمائید (از ابتدا).
لابلای توضیحات تفاوت‌های بنیادین برشمرده شده است.

بحث entity framework با NHibernate متفاوت است.
در NHibernate این متد BuildSessionFactory فوق کار بارگذاری متادیتا و نگاشت‌ها و غیره رو انجام میده؛ یعنی خودکار نیست و اگر قرار باشه به ازای هر کوئری یکبار فراخوانی شود اصلا نمی‌شود با برنامه کار کرد چون به شدت کند خواهد بود. به همین جهت کش کردن آن‌را با استفاده از الگوی singleton به صورت فوق تنها یکبار باید انجام داد. یکبار در طول عمر برنامه باید نگاشت‌ها صورت گیرد و پس از آن بارها و بارها از آن استفاده شود چون قرار نیست در طول عمر یک برنامه در حال اجرا تغییری کند.
در حالیکه در Entity framework اینکار (بارگذاری متادیتا و نگاشت‌های تعریف شده) به صورت خودکار زمانیکه برنامه برای بار اول اجرا می‌شود رخ داده و به صورت خودکار هم کش می‌شود. ماخذ: (+) ؛ بنابراین برای مدیریت آن اصلا لازم نیست شما کاری انجام دهید.
فقط در Entity framework یک لایه بسیار کم هزینه به نام ObjectContext وجود دارد که توصیه شده در برنامه‌های ASP.NET به ازای هر درخواست ایجاد و تخریب شود که می‌توانید از مقاله فوق ایده بگیرید و اصلا نباید کش شود یا هر بحث دیگری. ماخذ: (+) ؛ حتی اگر اینکار را هم انجام ندادید مهم نیست چون سربار بسیار کمی دارد.

یک سری وبلاگ در مورد NHibernate هست که مربوط به توسعه دهنده‌های اصلی آن است و مرجع محسوب می‌شوند. برای مثال:
http://ayende.com/Blog
در این پست زیر قید شده که هر آنچه که در criteria API پشتیبانی می‌شود در نگارش یک LINQ آن هم وجود دارد (بنابراین group joins or subqueries پشتیبانی نمی‌شود چون در criteria API وجود ندارد+ join هم به نظر هنوز تکمیل نشده).
http://ayende.com/Blog/archive/2009/07/26/nhibernate-linq-1.0-released.aspx

وبلاگ توسعه دهنده‌ی اصلی LINQ برای NHibernate
http://blogs.imeta.co.uk/sstrong/Default.aspx
join هم اکنون در نگارش بتای جدید آن کار می‌کند:
http://blogs.imeta.co.uk/sstrong/archive/2009/12/16/823.aspx

وبلاگ یکی از مدیر پروژه‌های NHibernate
http://fabiomaulo.blogspot.com