سلام

ابتدا توصیه میکنم پروژه سورس باز مثل Nop Commers و orChard رو ببینید

مقاله زیر هم میتونه کممتون کنه

معماری چند لایه ی نرم افزار چیست؟

سلام دوست عزیز

مبحث معماری لایه ها یا در واقع n-Layer  با بحثی که لابلای نوشته تان بدان اشاره کرده بودید یعنی n-Tier  کاملا متفاوت است

لایه ها به تقسیم بندی کدها بر اساس الگوی طراحی اشاره دارد اما تایرها بیشتر مباحث مربوط به توزیع لایه ها بر روی سرورهای متفاوت است

"سلام دوست عزیز

مبحث معماری لایه ها یا در واقع n-Layer  با بحثی که لابلای نوشته تان بدان اشاره کرده بودید یعنی n-Tier  کاملا متفاوت است ... "

بله دوست عزیز متوجه نکته اشاره شده شما هستم اشتباه لوپی بود

در ضمن مهندس مدائنی عزیز فرق بین 3 لایه domail.model و Business و service رو میگید و آیا دستورات و کوئری های پرس و جو linq همیشه بایددر لایه repository باشن؟

به نظر من وقتی از EF استفاده میکنیم در واقع لایه ی دسترسی به داده همون System.Data.Entity هستش که در واقع همون dbContext هستش و ما از متدهای این لایه جهت دسترسی به داده باید در Business استفاده کنیم.

به نظرم لایه ی انتزاعی بی خودی بیایم بکشیم روی EF که خودش هم uow هست و هم dbSet هایی که نقش مخازن رو بازی میکنند، فقط کد رو کثیف کردیم و کاری کردیم که قدرت بی نظیر EF مخصوصا در ورودی های لامبدا و خروجی های Anynomous رو اومدیم به شدت محدود کردیم و یه جورایی EF رو زندانی کردیم.

تمام قدرت EF انعطافی هستش که به خروجی و کوئری ها میده و نباید توی لایه ای به عنوان DAL انتزاعی اون رو حصر کنیم.

مایکروسافت اومده یه DAL ساخته و گفته بیاین از این استفاده کنید و ADO رو فراموش کنید. این معماری که میاد لایه بندی میکنه خیلی خوبه اما به شرطی که دقیقا درک کنیم چی رو لایه ی جدا در نظر میگیره

اینکه بیایم LinQ to Entities رو چادر سرش بکشیم و بگیم فقط می تونی اینطور عمل کنی متضاد هستش با ایده ی خلق ORM هایی مثل EF

شاید یکی بگه که با این کار میام و کاری میکنم که پروژه ی من منعطف بشه و اگه خواستم به راحتی تکنولوژی دسترسی به داده ام رو عوض میکنم! در صورتی که اصلا به این راحتی نیست و در هر صورت کلی وابستگی بین منطق و دسترسی پیدا میکنین مخصوصا توی عبارات لامبدا اگه برای انعطاف ورودی سرویس ها لحاظ بشن

یه راهم هست

Hard Coding!

خب اگه واقعا کسی دوست داره لایه دسترسی به داده ایجاد کنه با EF برای اینکه کاملا وابستگی رو از بین ببره باید Hard Coding انجام بده که خب بازم EF نیومده که شما خودتون رو توی دردسر بندازید!

این معماری های چند لایه مخصوصا Domain Driven Design رو اصلا منطقی نیست با EF انجام بدین و شاید اصلا عملی هم نباشه

اگه به دنبال این لایه بندی ها هستین Linq و  EF رو فراموش کنید و برین سراغ ADO یا Dapper

نهایت کاری که منطقی باشه اینه که بیاین بعضی از متدهایی که خیلی بهش توی کد نیاز دارین رو به عنوان یک سرویس به dbContext تزریق کنید و با dbContext در لایه ی منطقتون به اون سرویس ها دسترسی داشته باشید

عرض دیگری ندارم.