StructureMap امکان اسکن اسمبلی‌های اضافه شده به سیستم را دارد. باید وقت بگذارید مستندات آن‌را مطالعه کنید: (^)

HibernatingRhinos مربوط است به برنامه EF Prodiler که در قسمت 10 توضیح دادم.

مدیریت اتصالات توسط DbContext مدیریت می‌شود؛ با وهله سازی و سپس dispose آن.

قبلا در این مورد مطلب نوشتم: (^) | (^)

- استفاده از uow صحیح است. نیاز است یک uow بین لایه‌های مختلف به اشتراک گذاشته شود.
- استفاده از Repository که به صورت یک لایه سبک روی EF عمل کند اتلاف وقت است. به دلایلی که عرض کردم.
- استفاده از لایه سرویس توصیه شده است.
این موارد رو به صورت یک مثال عملی در قسمت بعدی توضیح خواهم داد.

این مورد برای مثال: (^)

شما فقط به uow برای پیاده سازی session per request نیاز خواهید داشت (به اشتراک گذاری فقط یک سشن در طول عمر یک http request در لایه‌های مختلف برنامه).
الگوی Repository خصوصا در مورد NH قابل انتقال نیست. چون تا حد بسیار زیادی به جزئیات LINQ، QueryOver و حتی HQL وابسته می‌شود که در سایر ORMهای دیگر معادل ندارد. به همین جهت تحمیل این لایه به سیستم غیرضروری است.
یعنی در ابتدا مقالات را که مطالعه کنید، همه عنوان می‌کنند که با استفاده از Repository به سیستمی خواهید رسید که می‌توانید ORM آن‌را به سادگی تعویض کنید. اما در مورد NH ابدا اینطور نیست. هنوز حتی خیلی از حالات mapping رو که این سیستم پشتیبانی می‌کنه در سایر ORMها نمی‌تونید پیدا کنید. بنابراین این Repository قابل تعویض نیست. بهتره بگم این ORM اصلا قابل تعویض نیست؛ چون اصطلاحا feature rich است. مگر اینکه از توانایی‌های پیشرفته آن استفاده نشود که آن وقت ضرورت استفاده از آن‌را زیر سؤال می‌برد.

من فکر می‌کنم طرحی که از Repository در ذهن شما است، تعریف یک اینترفیس که دارای متدهای مثلا Add و Get و امثال آن است. سپس پیاده سازی کامل آن با EF. چون مبتنی بر Interface است می‌شود یک پیاده سازی مبتنی با NH را هم برای آن تدارک دید. بعد این‌ها رو میشه با DI مدیریت کرد. بله. این شدنی است. فقط واژه‌های استفاده شده در اینجا بین من و شما یکی نیست. من Repository رو به عنوان یک لایه سبک محصور کننده خود EF مد نظر دارم. یعنی پیاده سازی که در هزاران سایت اینترنتی داره تبلیغ میشه و به نظر من لزومی ندارد. انتقال پذیر نیست و لذت استفاده از یک ORM واقعی رو از بین می‌بره.
در کل من از واژه سرویس استفاده کردم شما از واژه مخزن. ولی به نظر برداشت هر دو یکی است.

چندتا بحث هست. مدیریت پروژه. استفاده از Repository.
اینکه پوشه درست کنید،  class library‌ درست کنید. اسم‌های متفاوت استفاده کنید. همه این‌ها خوب است.
باز هم در طراحی خودتون اومدید ORM رو مخفی کردید. کل بحث جاری این است که اینکار اتلاف وقت است. «فقط با یک Config ساده در DI این موضوع به طور کامل حل می‌شود» : .... نمی‌شود. خیر! قصد ندارم مواردی رو که عنوان کردم تکرار کنم. مدتی با یک ORM با قابلیت‌های بالا کار کنید، این مطلب رو دیگر عنوان نخواهید کرد.
به نظر در مورد اسامی کمی تداخل اینجا هست. مفهومی رو که از Repository‌ دنبال می‌کنید، همان چیزی است که در لایه سرویس من به آن اشاره کردم.
اگر علاقمند بودید، به پیاده سازی generic repository که لینک دادم مراجعه کنید.
واژه‌ها‌ی مورد استفاده رو اگر یکسان کنیم شاید خیلی از سؤ تفاهم‌ها برطرف شود.

بله. این مورد به الگوی «Session Per Request» معروف است که کار آن به اشتراک گذاری یک DbContext در طول مدت عمر یک Http Request است. در این مورد یک مطلب خواهم نوشت.