معرفی فریمورک AUA

فریمورک ها و کتاب خانه های اماده در طراحی و پیاده سازی یک سیستم نرم افزار به ما کمک میکنند که سرعت توسعه بالایی داشته باشیم.امروزه بیشتر ابزارها open source بوده که باعث میشوند برنامه نویس دید بازتری نسبت به پروژه داشته باشد.در این سری از مقالات قصد داریم فریمورک سورس باز دانتنی AUA را معرفی کنیم که برای پروژه های خود میتوانید استفاده کنید.سورس کد گیت هاب را میتوانید از این لینک مشاهده کنید .

کلیه محتوای این مقاله متعلق به سایت auaframework میباشد

اگه از این مقاله براتون مفید بود ، میتونید از لینک زیر یک قهوه مهمونم کنید : )

https://www.coffeete.ir/sobhan

چکیده

پروژه های نرم افزاری، نیازمند تغییرات و بروزرسانی های مداوم هستند. در صورتی که ساختار توسعه درست نباشد مانع از تغییرات و گسترش می شود و در بیشتر مواقع باعث انجام کار های اضافه یا باز نویسی پروژه از اول می شود. برای رهایی از پیچیدگی و انجام کارهای تکراری که عمدتا برنامه نویسان و توسعه دهندگان با آن روبرو هستند که این امر نیز ناشی از عدم همخوانی کد ها در سطوح مختلف برنامه می باشد، ما نیاز مند یک ساختار یکپارچه و ساده جهت نوشتن پروژه های نرم افزاری هستیم که با کمک آن بتوان بخشی از پیچیدگی را مخفی و روی بیزینس کار تمرکز نمود. برای مثال فریم ورک Bootstrap یک فریم ورک بسیار مفید برای Front End می باشد که کمتر کسی ترجیح میدهد برای طراحی از فریم ورک هایی مثل Bootstrap استفاده نکند و از ابتدا تمام طراحی خود را با CSS بنویسد. برای قسمت End Back نیز این گونه است که یک فریم ورک ساده و همه منظوره می تواند در زمان و هزینه صرفه جویی کند و باعث تولید کد با کیفیت بالا و یک معماری یک نواخت شود. فریم ورک به توسعه دهندگان این امکان را می دهد تا بر اساس الگوی مناسب و یکپارچه پروژه خود را توسعه دهند. فریم ورک باید از انعطاف پذیری بالایی برخوردار باشد تا برنامه نویس بتواند با تکیه بر ساختار قدرتمند آن هر گونه تغییر مورد نیاز را اعمال کند.

چرا فریم ورک؟

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

فریم ورک(AUA) Asp.Net Unique Architecture

AUA یک فریم ورک ساده و سبک برای تولید پروژه های با هر مقیاس (کوچک و بزرگ) می باشد. فریم ورک Asp.Net Unique Architecture به دلیل شفافیت در ساختار، قابل استفاده در تمام معماری های (Micro service، CQRS,، ... (می باشد. همچنین فریم ورک AUA پر از الگو های طراحی مختلف بوده که یک منبع بسیار خوب برای معماران نرم افزار و توسعه دهنده ها می باشد.

• طراحی دامنه محور (DDD) Domain Driven Design
• EF 6 و EF Core 3.0,3.1
• امکان توسعه ی نرم افزار به شکلی ساده و سریع
• مبتنی بر اصول SOLID
• طراحی پیمانه ای یا ماژولار
• معماری لایه بندی شده

فریم ورک AUA در نسخه های:

• Asp.Net MVC (.net framework and ef6)
• Asp.Net MVC Core 3.0,3.1
• Asp.Net Web API Core 3.0,3.1

ساختار کلی فریم ورک Asp.Net Unique Architecture (AUA)

در این قسمت با لایه های مختلف فریم ورک AUA آشنا می شویم.

اضافه کردن موجودیت جدید

موجودیت، اصلی ترین مفهوم در فریم ورک AUA است که در مرکز معماری این فریم ورک قرار دارد. هر موجودیت با یک کلاس تعریف می شود که شامل مشخصات موجودیت و ارتباط آن با دیگر موجودیت ها می باشد. هر موجودیت، یک شناسه دارد که این شناسه می تواند از هر Data Type مجاز در .NET باشد و یا می تواند ترکیبی از دو یا بیشتر از Data Type مجاز باشد(کلید ترکیبی).

Entity Class

هر موجودیت از کلاس DomainEntity ارث بری می کند که یک فیلد کلید اصلی به نام Id و یک یا چند فیلد نظارتی (بسته به نوع تنظیمات) به آن اضافه می شود.

در صورتی که کلید اصلی بجز دیتا تایپ intباشد باید آن را مشخص نمود.( مثلا نوع داده ای Long در زیر کلید اصلی در نظر گرفته می شود)

به صورت پیش فرض به هر موجودیت فیلد های زیر اضافه می شود.

فیلد Id کلید اصلی و نوع داده ای آن هنگام تعریف موجودیت می تواند مشخص شود.

فیلد IsActive نمایش وضعیت فعال یا غیر فعال بودن و نوع داده ای آن bool می باشد.

فیلد RegDate تاریخ و زمان ایجاد موجودیت (به صورت خودکار در داخل SQL Server ایجاد می شود. ) و نیاز به پرکردن و ارسال ندارد.

فریم ورک AUA به صورت کد باز بوده و به راحتی می توان تغییرات مورد نظر را اعمال نمود.

فیلد های نظارتی :

در صورت تمایل و بسته به بیزینس شما می توان فیلد های نظارتی بیشتری به موجودیت ها اضافه نمود.

فیلد نظارتی ایجاد کننده موجودیت ICreationAudited

برای اضافه کردن فیلد نظارتی CreatorUserId فقط کافی است اینترفیس ICreationAudited را برای کلاس DomainEntity پیاده سازی نمود. مانند

فیلد های نظارتی حذف کردن موجودیت IDeletionAudited

جهت جلوگیری از حذف فیزیکی و اضافه کردن فیلد های نظارتی حذف موجودیت می توان از اینتر فیس IDeletionAudited استفاده نمود. حذف

فیلد های نظارتی جهت ویرایش IModifiedAudited

جهت اضافه کردن فیلد های نظارتی برای ویرایش موجودیت می توان از اینترفیس IModifiedAudited زیر استفاده نمود.

کانفیگ موجودیت ها:

برای هر موجودیت یک کلاس کانفیگ وجود دارد که می توان تنظیمات طول فیلد ها و.. را برای موجودیت مشخص نمود.

موجودیت با کلید ترکیبی را به صورت زیر کانفیگ می کنیم. فیلد AppUserId و RoleId هردو کلید موجودیت UserRole هستند

مدل ها و مپینگ :

مدل ها در AUA کلاس BaseEntityDto را به ارث می برند و فیلدی نظارتی و Id به صورت خود کار به آن اضافه می شود. فریم ورک AUA دو روش مپینگ IMapFrom و IHaveCustomMappings برای مپ کردن یک آبجکت به یک آبجکت دیگر دارد. در مپ کردن به مدل IMapFrom فقط فیلد های همنام مپ می شوند و برای فیلد های غیر همنام هیچگونه مپی انجام نمی شود. این نوع مپینگ ساده ترین و سریعترین نوع مپ می باشد. در مثال زیر یک موجودیت Student به یک StudentDto مپ می شود. مانند:

مپینگ به روش IHaveCustomMappings

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

در مقالات بعدی به قسمت های مختلف AUA Freamwork خواهیم پرداخت.

اگه سوال یا نکته نظری دارید در قسمت کانت مطرح کنید