در این مقاله می خواهیم یک لیستی از کارمندان را نمایش دهیم ،هدف استفاده از معماری لایه ای و استفاده از روش database First و کار با کلاس repository است ، و ارائه ی یک نمونه ی سبک و قابل نگه داری است.

هدف این مقاله :

1-ارائه ی یک معماری در mvc

2-کار با روش DataBase First

3-Dependency injection   با استفاده از Unity

4- استفاده از الگوی repository

Onion Architecture چیست؟

این اصطلاح معماری توسط جفری پالرمو تماس در سال 2008 ابداع شد، و تا کنون محبوبیت خود را داشته است، زمانی که جزییات آن گفته می شود ممکن است شما احساس کنید که در حال حاضر از آن استفاده می کنید وشاید هم ممکن است که شما از آن استفاده کرده باشید و نا آگاه باشید .

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

به عنوان مثال شکل زیر را مشاهده نمایید:

اگر ما 3 لایه داشته باشیم و لایه ی 1 لایه اصلی و هسته ی ما باشد، و سپس لایه 2 ولایه ی3 باشد، بنابر این بر اساس معماری برای ایجاد برنامه ما یک لایه داریم که لایه ی درونی دارد.

که مستقل از لایه 2 و3 است.

سپس لایه دوم بالای لایه اول و وابسته به لایه 1، و در نهایت لایه سوم خارجی ترین لایه که به لایه اول و دوم وابستگی دارد.

بنابر این مهم ترین نکته در لایه ها ما از لایه ی هسته حرکت می کنیم تا به لایه های بالاتر برسیم.

این کار وابستگی به سمت لایه های داخلی را افزایش می دهد اما نباید اینگونه باشد باید وابستگی به صورت متقابل باشد.

بنابر این نباید لایه دوم و سوم به هم وابسته باشد، و باید طوری طراحی شود که لایه ی اول هسته  و عمومی باشد.

یک پروژه ی جدید به صورت زیر بسازید:

حالا باید پایگاه داده ی خود را به روش Entity Framework  که database first است پایگاه داده ی خود را اضافه نمایید، البته باید یک کلاس Library اضافه نمایید و بعد آن را به refrence پروژه ی خود اضافه نمایید.

مرحله ی بعد نمایش داده ها از جدول است ، ما یک کلاس جدیدی به نام UserRepository می سازیم، در این پروژه شما می توانید یک CRUD بسازید ولی ما در اینجا فقط یک لیستی از کارمندان را نمایش می دهیم، به صورت زیر:

ما یک Controller جدید می سازیم، و متد GetAllUsers را در repository  صدا می زنیم، توجه داشته باشید که classlibrary خود را به refrence های خود اضافه نمایید.

وقتی view را ایجاد نمایید خروجی به صورت زیر خواهد بود:

چند نکته:

1-Violation of Single Responsibility Principle:

کلاس Controller وابسته به کلاس Repository است، کلاس Controller مسئول انجام چند وظیفه است، به عبارت دیگر نمونه سازی Repositore و بازگشت داده ، این خود یک نقض است که هر کلاس مسئول انجام یک وظیفه است.

Tight coupling between the Web and the Infrastructure project-2:(اتصال میان وب سایت و زیر بناهای پروژه )

پروژه ی ما مستقیم وابسته به entites  است ، این فقط شامل کلاس Controller نخواهد شد، view و Model  هم شامل آن می شود

و ممکن است در آینده به هر دلیلی بخواهیم Entity Framework را حذف نماییم این فقط به کلاس controller تاثیر نمی گذارد بلکه به view و Model هم اثر می گذارد.

Concrete Repository class-3:

کلاس repository  یک کلاس concrete در پروژه است ، اگر بخواهیم در میان اجزاها از آن استفاده کنیم باید آن را جمع ببندیم.

ما می توانیم از کلاس های ساده POCO استفاده کنیم ، که داده ها را از لایه ی دسترسی با استفاده از یک Repository به Controller و در نهایت نمایش داده شود.

ما می توانیم این کلاس ها را به صورت DAL به پروژه ی خود اضافه نماییم.

اما نکته ی مهم این است که این کلاس ها ظرفیت تحمل داده ها و اتصال به UI را دارند ، پس چرا آن ها را به لایه دیگری قرار می دهیم!

بنابر این ما یک لایه به نام Architecture.Core می سازیم به صورت معماری لایه ای  پیش می رویم:

1-لایه ی هسته مستقل از زیر ساخت ها و وب لایه خواهد بود، این لایه ی 1 از بحث قبلی ما استفاده می کند.

2- لایه ی زیر ساخت مستقل از لایه ی وب خواهد بود ، اما وابسته به لایه هسته خواهد شد ، برای کلاس های POCO  این بحث قبلی در لایه دوم است.

3-لایه ی وب وابسته به هر دو هسته و لایه ی زیر ساخت خواهد بود، برای استفاده از کلاس POCO  و کلاس Repository  بحث لایه ی سوم است که زودتر از بحث ما است.

بنابر این یک پروژه ی جدید از نوع ClassLibarry اضافه نمایید، اضافه کردن یک کلاس در POCO به نامUserUI  یکی دیگر از مزیت این کلاس ها استفاده از Validation  در Model است.

حالا ما متد Repository را با استفاده از کلاس POJO تغییر می دهیم، و به Controller برمی گردیم و به View متصل می شویم.

 بنابر این اگر شما بخواهید EF خود را حذف نمایید نیاز به تغییر View و Controller نخواهید داشت ، بدون هیچ تغییری در هسته و لایه های وب وجود دارد.

در حال حاضر سعی داریم که فرآیند ایجاد کلاس در repository را با Controller حذف نماییم.

شما می توانید از مفهوم وارونگی کنترل استفاده نمایید، ما مسئولیت کنترل مقدار دهی اولیه Repository از کنترل به مکان دیگر را داریم.

این همان تزریق وابستگی (dependency injection) ، پس در واقع این وابستگی مسئول ایجاد وابستگی های مورد نیاز و انتقال آن به کنترل خواهد بود، همان طور که در MSDN ,Unity است:

Unity:

یک Container برای استفاده در هر application  بر اساس چهارچوب Framework است. تمام ویژگی های معمول در مکانیزم تزریق وابستگی را دارد، از جمله resolve objects، manage object lifetimes، و..

بنابر این ما نیاز داریم که Dll را به refrence خود اضافه نماییم، بنابر این در شکل زیر Nuget  را به پروژه ی خود اضافه می کنیم.

حالا ما یک Repositoryاضافه می کنیم و متد GetAllMethod را اضافه می نماییم.و رابط را در کلاس UserRepository تعریف می کنیم ، دوباره همان سوال اضافه کردن رابط است و پاسخ آن است که آن یک جز قابل استفاده ی مجدد است ، و باید یک جز مستقل باشد، بنابر این ما آن را به صورت نمونه به Architecture.Core اضافه می کنیم

Dll ای که در Unity قرار دارد مسئولیت آن این است که نیاز وابستگی به کلاس را فراهم کند، بنابر این ما باید dll ها را به refrence هایمان اضافه نماییم.

ما نیاز به اضافه کردن دو کلاس UnityContainerRegistration وregister که به هم وابسته هستند داریم .

حالا در فایل global باید زمانی که برنامه آغاز شده است ، کد زیر را بنویسیم:

حالا ما UserRepository  را به IUserRepository تغییر می دهیم ، userRepository  نوعی از iRepository است، که به سازنده ی آن وابسته است.

بنابر این در حال حاضر نرم افزار ما اجرا و اثری بر روی نتایج ندارد، اما در کد نرم افزار وابستگی ما به شرح زیر است:

در اینجا Architecture.Core نمونه ی ما در لایه درونی است که مستقل از همه چیز است ، وArchitecture.Infrastructure

وابسته به لایه هسته و مستقل از لایه ی وب است ، و در نهایت لایه ی وب که وابسته به هر دو هسته و لایه ی زیر ساخت است.

خروجی به صورت زیر خواهد بود: