“Separation of concerns” در معماری لایههای نرمافزار یک اصل مهم است که به معنای تفکیک مسئولیتها یا جداسازی نگرشها از یکدیگر است. این اصل در طراحی و توسعه نرمافزار به منظور افزایش قابلیتنگهداری، قابلیتسازگاری و قابلیتتغییرپذیری کد استفاده میشود.
استفاده از اصل “Separation of Concerns” و لایهبندی نرمافزار به معنای این است که هر لایه یا بخش از نرمافزار یک مسئولیت مشخص دارد و تغییرات در یک مسئولیت تأثیر کمتری بر سایر مسئولیتها دارند. این امر ارتباطات را سادهتر میکند و کد را قابلتعمیر و توسعه میکند.
شامل کلاس ها و Type هایی هستش که برای بقیه لایه ها کاربرد دارد.
درواقع چیزهای مشترک بقیه لایه ها در این لایه قرار می گیرد ، مثلاً کلاس های Utility و کلاس هایی که وابستگی به پروژه فعلی ما ندارد در این لایه قرار میگیرند . فرض کنید که یک کلاس Utility برای کار با DateTime و یا برای کار با String و…. داریم که اینها وابستگی به پروژه ما ندارند .
این لایه کاملاً مستقل هست و می تواند در پروژه های دیگر هم استفاده شود.
Entity ها یا Model های Entity Framework ما داخلش قرار می گیرد ، مثل کلاس User , Role یا مثلاً Category , Post و غیره ، که تمام اینها در داخل این لایه قرار می گیرد.
یا کلاس های پایه (Base Class) ها که تمام Entity های ما از آن باید ارث بری کند .
و در کل هر چیزی که مربوط به Entity ها ما می شود. حتی Fluent API در این لایه قرار می گیرد.
لایه دسترسی به داده (Data Access Layer): مسئول ارتباط با منابع داده مانند پایگاهدادهها.
در این لایه DBContext مربوط به Entity Framework و Repository و unit of work و هر چیز دیگه ای که مربوط به لایه دسترسی به Data هست قرار می گیرد.
ممکنه Fluent API مربوط به Entity Frame هم در این لایه قرار بگیرد. چون بعضی ها معتقدن Role های دیتابیسی و Validation هایی که رو Property ها بگذاریم ربطی به خود Entity ها ندارند و باید از لایه Entity جدا باشند و در یک لایه ای باشد که مخصوص دسترسی به Data ، که در آنجا مشخص می کنیم که Data های ما چه Role ها و Validation هایی را باید داشته باشند.
در کل در این لایه هر چیزی که مربوط به دسترسی به دیتابیس ها هست در آن قرار میگیرد.
این لایه وظیفه ارسال Request به دیتابیس را دارد. و لایه های بالایی از این لایه برای دسترسی به دیتابیس استفاده می کنند. و هیچ وقت نباید مستقیم به دیتابیس دسترسی داشته باشند.
این لایه از طریق Entity های لایه پایین تر خودش برای ارتباط با دیتابیس استفاده می کند . و این Entity ها در DBContext این لایه هستند.
این لایه می تواند از لایه های پایین تر خودش مانند Common هم استفاده کند ، مثلاً یک کلاس Utility داریم برای Config کردن DBContext که یکسری تنظیمات را به صورت اتوماتیک روی DBContext اعمال می کنیم.
لایه تجاری (Business Layer): مسئول اجرای منطق تجاری و پردازشهای کسب و کار
Service های پروژه ما در اینجا قرار می گیرند.
Service ها چی هستند؟ کلاس هایی هستند که منطق تجاری پروژه ما داخل آنها پیاده سازی می شوند .
این لایه می داند که در چه زمانی از چه Repository هایی استفاده کند . مثلاً داخل کدام Repository عملیات Add ، Update ، Delete و یا Select کند .
مثلاً فرض کنید ما می خواهیم یک سفارش ثبت کنیم ، وقتی که Id محصول با تعدادی که سفارش داده شده به سرویس ما پاس داده میشود ، این لایه هست که تصمیم می گیرد که Repository مربوط به Product و Order و User استفاده کند و با ترکیب این سه تا عملیات مرلوطه را انجام دهد . و حتی اینکه آیا این محصول موجود هست ؟ و…. و در نهایت آن محصول را در داخل جدول سفارشات (Order) ثبت می کند .
تفاوت لایه Service و Repository :
وظیفه Repository دسترسی به دیتای یک Entity خاص خودش هستش ، مثلاً Repository مربوط به User وظیفه 4 عمل اصلی (Insert -Update – Delete – Select) برای UserEntity دارد.
منطق تجاری (Business) پروژه ها داخل لایه Service قرار می گیرد و بر اساس نیازش از هر کدام از Repository هایی که نیاز دارد استفاده کند .
این لایه محل قرارگیری چیزهای مشترک لایه های web(Presentation) ماست ، مثلاً ممکن است چند پروژه در لایه Presentation داشته باشیم ، یکی برای Admin، یکی برای API داشته باشیم و چیزهای مشترکی داشته باشند که این لایه آنها را فراهم می کند.
مثلاً IOC , Middleware , Filters , ASP Core Configs , Attribute های مشترک بین لایه های Presentation را بهتر است در اینجا بنویسیم .
مزیت این لایه در این هستش که لایه Presentation مون شلوغ نمیشه و اینکه اگر تنظیمات IOC مون رو در اینجا بنویسیم در بقیه لایه های Presentation مون ازش استفاده کنیم ، هر زمانی که لازم شد تغییر بدیم یکجا تغییر می دهیم و احتیاج به تغییر در پروژه های مختلف Presentation مون نداریم .
لایه رابط کاربری (User Interface Layer): مسئول ارتباط با کاربران و نمایش اطلاعات.
خروجی پروژه مون که ممکن است API ، وب سایت ، Admin ، Client و … باشد در این لایه قرار میگیرد.