معماری‌های سه لایه

[bftarane]

سلام
در یک آگهی مورد زیر رو دیدم

آشنا به معماری‌های سه لایه و MVC

من با معماری سه لایه در asp.net وب فرم آشنایی دارم، که شامل سه لایه BLL، DALو UI میشهیه مقدار در مورد معماری سه لایه در asp.net mvc هم جستجو کردم، متوجه شدم که در این جا mvc همون لایه UI میشه.

ممنون می شم آموزشی معرفی کنید که معماری سه لایه رو در asp.net ام وی سی کد فرست آموزش داده باشه.


یه سوال دیگه هم با توجه به اینکه گفته معماری های سه لایه، آیا خود معماری سه لایه دارای انواع مختلفی هست؟ یعنی به فرض یک روش که همون DAL و BLL و UI هست درسته؟ به صورت های دیگه ای هم پیاده سازی میشه؟

[Moien Tajik]

در mvc هم به همون شکل Web Form هست و لایه های BLL و DAL و Web هست.

ممنون می شم آموزشی معرفی کنید که معماری سه لایه رو در asp.net ام وی سی کد فرست آموزش داده باشه.

چیزی نیست که نیاز به آموزش دادن داشته باشه ، صرفا جداسازی کلاس ها داخل Class Library های دیگه هست و چیزه چندان پیچیده ای نیست.
https://softwareengineering.stackexchange.com/a/299881

آیا خود معماری سه لایه دارای انواع مختلفی هست؟

خیر

[hakim22]

وقتی صحبت از معماری چند لایه میشه منظور اینه که باید بتوانید با IoC Container ها و Dependency Injection کار کنید.
وقتی در یک پروژه از این ابزار استفاده می کنید خود به خود جدا سازی لایه ها اتفاق میوفته. در واقع باید نحوه ی کار ابزاری مثل Ninject یا StructureMap یا AutoFac را بلد باشید. روش کار هر سه اینها تقریبا یکی است و از یک مفهوم پیروی می کنند.

در این ویدیو می توانید با نمونه یک پروژه ی چند لایه آشنا بشید. همینطور لینک دانلود پروژه هم در توضیحات ویدیو هست.

https://www.aparat.com/v/5Fmk9

[bftarane]

یه سوال در همین رابطه با توجه به جوابی که دوستان دادن، آیا اینکه با استفاده از ریپازیتوری پترن و Unit of work پروژه رو پیش ببریم آیا معماری سه لایه پیاده شده، حتی بدون اینکه بخواهیم به ازای هر لایه یک Class library ایجاد کنیم؟(در واقع فقط یک پروژه داریم که شامل تعدادی کلاس repository و کلاس unit of work باشه)

[ali_md110]

هدف اصلی از لایه بندی توسعه نرم افزار هست
برنامه چند لایه معمولا با اهداف خاصی طراحی میشود و هر لایه وظیفه خاصی دارد
اگر کل پروژه شما در یک پروژه جمع آوری بشود مثلا Repository و Uow که گفتید بهمراه کلاسهای poco و همچنین ioc و سایر قسمتهای برنامه .....
نگهداری این پروژه کمی مشکل ساز هست و منابعی که در این سیستم طراحی کردید در پروژه های دیگر به سختی قابل استفاده هست
یک برنامه نویس باید برای خودش یک استراتژی و پیاده سازی خاصی را داشته باشد
و فرض بر این بگیرد که ممکن است برنامه ای که مینویسد در آینده دوباره شبیه این برنامه نیاز است بنویسد
یا از کلاس لایبراری های این برنامه در سایر پروژه ها استفاده مجدد بکند

[hakim22]

یه سوال در همین رابطه با توجه به جوابی که دوستان دادن، آیا اینکه با استفاده از ریپازیتوری پترن و Unit of work پروژه رو پیش ببریم آیا معماری سه لایه پیاده شده، حتی بدون اینکه بخواهیم به ازای هر لایه یک Class library ایجاد کنیم؟(در واقع فقط یک پروژه داریم که شامل تعدادی کلاس repository و کلاس unit of work باشه)

وقتی شما ریپوزیتوری و Unit Of Work به پروژه اضافه میکنید خود به خود پروژه ی شما سه بخش میشه
لایه UI و Data و Business ، البته باید از تزریق وابستگی هم است استفاده کنید.

استفاده از Class Library مجزا فقط راهی برای جدا سازی کدها و سازماندهی اونهاست. ربطی به چند لایه شدن پروژه نداره. در سی شارپ همه چیز درون namespace تعریف میشه. تا زمانی که شما از Namespace مجزا برای یک سری از کلاسها استفاده می کنید اون کلاسها در یک لایبراری جدا قرار دارن (هرچند که از نظر فیزیکی اینطور به نظر نرسه و کدها عملا کنار هم باشن)

در پروژه ها وب کمتر پیش میاده که یک Class library در پروژه ها دیگه قابل استفاده باشه. کد مورد نظر خیلی باید کلی و عمومی باشه که در جای دیگه کاربرد داشته باشه.
بهتره حداقل از دو پروژه ی مجزا استفاده کنید. یکی برای وب و دیگری برای سایر چیزها. دلیل عمده اینه که پروژه ی وب از Package های عمدتا متفاوتی استفاده میکنه .

شما می توانید هر قسمت از پروژه رو درون کلاس های جدا قرار بدید یا اونها رو درون فولدر قرار بدید.
به خاطر داشته باشید که هر زمان می توانید یک Folder رو تبدیل به کلاس جدا کنید و به پروژه ی خودش منتقل کنید. (با کپی و پیست) یا بر عکس یک کلاس مجزا رو درون یک Folder قرار بدید. این انتخابی نیست که در زمان طراحی اهمیت داشته باشه. من معمولا با فولدرها کار میکنم. تا جایی که چیزی باعث بشه نیاز به پروژه های مجزا پیش بیاد.

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

مثلا در ASP MVC اگر برای قسمت های مجزا لایبراری جدا درست کنید یک مشکل همیشه دارید که باید Identity و Entity framework رو در همه ی پروژه ها نصب کنید. در واقع اگر شما به پروژه ای رفرنس بدید که از یکی از این دو استفاده میکنه باید حتما پکیج کاملش رو هم نصب کنید. این مسئله کار آسانیه ولی نفس جدا سازی پروژه رو از بین میبره. نفس اینکه ما پروژه هایی داشته باشیم که فقط به منابع مورد نیازشون دسترسی داشته باشن. البته در دات نت Core این مسئله برطرف شده و رفرنس ها بدون نصب مجدد پاس داده میشن

من با Solution هایی که کار کردم که شامل 30 پروژه ی مجزا میشدن و پروژه هایی که با وجود بزرگی درون دو پروژه پیاده شده بودن و با فولدر طبقه بندی شده بودن. اما با توجه به اینکه تیم برنامه نویسی هیچوقت از 5 یا 6 تجاوز نکرد عملا نیازی به پروژه های مجزا نبود. مدیریت کردن سولوشن با دو پروژه خیلی ساده تر بود.