“آیا باید پروژه ASP.NET MVC خود را به چندین پروژه تقسیم کنیم؟” جواب کوتاه: نه!
نمیدانم که چگونه این روند شروع شد اما دیده ام که برخی از توسعه دهندگان، یک پروژه ASP.NET MVC را به چندین پروژه تقسیم می کنند: یک پروژه وب حاوی لایه ارائه (presentation logic)، به علاوه دو class library، برای لایه های دیتا و منطق.
غالباً به اشتباه تصور می شود که ساختار مطرح شده در بالا، یک برنامه را بصورت Multi-Tier یا ۳-Tier می سازد. برنامه Multi-Tier چیست؟ برنامه ای است که قسمت های آن به صورت فیزیکی در رایانه (ماشین) های مختلف در یک شبکه توزیع می شود. برنامه های وب معمولاً ذاتاً Multi-Tier هستند.
در برنامه های وب اغلب Tier های زیر را داریم:
وقتی در مورد ASP.NET MVC صحبت می کنیم ، ما فقط در مورد application یا middle tier صحبت می کنیم. جدا کردن یک پروژه ASP.NET MVC به سه پروژه، منجر به اضافه شدن Tier های جدید در معماری شما نمی شود.
به عبارتی، برای مثال لایه داده را در رایانه دیگری مستقر نمی کنید! بیشتر اوقات (نه همیشه) این ۳ پروژه (وب ، BLL و DAL) در یک فرآیند در یک ماشین، کامپایل و اجرا می شوند؛ در وب سرور شما!
وقتی شخصی به سایت شما مراجعه می کند، این DLL ها درون یک فرآیند (یک AppDomain) که توسط IIS اداره می شود، بارگذاری می شود.
واژه های Layer و Tier گاها به جای هم استفاده می شوند ولی اساسا متفاوت هستند. Layer برای جدا سازی منطقی کد های برنامه استفاده می شود ولی Tier برای جدا سازی فیزیکی. یعنی توزیع قطعات برنامه در ماشین های مختلف.
Layer چیزی مفهومی در ذهن برنامه نویس است! یک class library یا پوشه، یک لایه نیستند. می توانید کلاس ها را در یک پوشه یا یک class library که متعلق به لایه های مختلف است قرار دهید و به یکدیگر وابسته باشند. که این نشان دهنده ی بد بودن معماری است. قرار دادن این کلاس ها در یک پوشه یا class library مانند BLL و DAL فوراً به نرم افزاری با معماری تمیز و تفکیک خوب منجر نمی شود.
با وجود این ، استدلال من این است که این پوشه ها (BLL و DAL) می توانند و باید در پروژه اصلی وب سکونت داشته باشند و انتقال آنها به یک class library جداگانه ، هیچ ارزشی ندارد.
۲ دلیل برای تقسیم یک پروژه به پروژه های کوچکتر وجود دارد: قابلیت استفاده مجدد و استقرار مستقل آن پروژه ها.
یکی از دلایل جدا کردن یک پروژه در چند class library، قابلیت استفاده مجدد است. هنوز قسمت BLL یا DAL یک برنامه وب را که در یک برنامه دیگر مورد استفاده مجدد قرار گرفته است ، مشاهده نکردم. این همان چیزی است که کتابهای دهه ۹۰ میلادی برای ما تعریف می کردند! امروزه اکثر برنامه ها به صورت خاص نوشته می شوند و لایه های آن کمتر در سایر برنامه ها استفاده می شود. اغلب اوقات class library ها برای استفاده داخلی خود نرم افزار ساخته می شوند نه برای استفاده مجدد.
یکی دیگر از دلایل جدا کردن یک پروژه در class libraries در مورد استقرار پذیری است. اگر میخواهید قطعات پروژه به صورت مستقل ورژن بندی و مستقر شود، خوب است پروژه را به این شکل لایه بندی کنید. که اغلب در framework ها کاربرد دارد نه برنامه های سازمانی.
Entity Framework مثال خوبی است. این فریم ورک از assembly های مختلفی تشکیل شده است که هر یک حوزه کاربرد خاصی دارد. core assembly شامل قسمت های اصلی این فریم ورک است. اسمبلی دیگری برای ارتباط با SQL server یا سایر پایگاه ها داریم.
با استفاده از این معماری ماژولار ، ما می توانیم فقط قسمتهایی را که لازم داریم را بارگیری کنیم. تصور کنید که Entity Framework فقط شامل یک اسمبلی بود! یک اسمبلی غول پیکر با کد های بسیار زیاد که نیازی به اکثر آن ها نداریم.
همچنین ، هر بار که تیم پشتیبانی یک ویژگی جدید را اضافه کند یا یک اشکال را برطرف کند ، باید کل اسمبلی کامپایل و deploy شود. این باعث می شود این اسمبلی بسیار شکننده شود. اگر برای ارتباط با SQL server از Entity Framework استفاده می کنیم، چرا با آپگرید به نسخه جدید برای رفع مشکل اتصال به SQLite ، برنامه خود را دچار مشکل کنیم؟؟؟ در صورتی که اصلا از SQLite استفاده نمی کنیم! به همین دلیل به شکلی ماژولار طراحی شده است.
در بیشتر برنامه های وب موجود، همه این مجموعه ها (وب ، BLL و DAL) را با هم version و deploy می کنیم. بنابراین ، جدا کردن یک پروژه در ۳ پروژه هیچ ارزشی نمی افزاید.
بنابراین ، چه موقع واقعاً نیاز دارید که یک پروژه را به صورت فیزیکی از چندین پروژه جدا کنید؟ در اینجا چند سناریو وجود دارد:
فرض کنید که شما یک برنامه پردازش سفارش ایجاد کرده اید. این برنامه یک برنامه دسک تاپ است که توسط کارکنان سازمان شما استفاده می شود. و تصمیم دارید یک رابط وب برای این برنامه ایجاد کنید تا کارکنان بتوانند از طریق اینترنت به آن دسترسی پیدا کنند. و البته می خواهید از DAL و BLL موجود استفاده مجدد کنید.
همانطور که قبلاً توضیح دادم ، یکی از دلایل تقسیم کردن پروژه به چند پروژه، قابلیت استفاده مجدد است. پس در این سناریو پروژه به چند پروژه زیر تقسیم می شود:
توجه داشته باشید که حتی در اینجا من دو پروژه ندارم (BLL و DAL). من یک پروژه با نام OrderProcessing.Core دارم که هم منطق کد و هم دسترسی به داده برای برنامه پردازش سفارش ما را در بر می گیرد. چرا این پروژه را به دو پروژه جداگانه (BLL و DAL) جدا نکردم؟ زیرا هدف اصلی این DAL ، فراهم آوردن یک persistence برای موارد موجود در BLL هست. بسیار بعید است که به تنهایی در پروژه دیگری مورد استفاده قرار گیرد.
همچنین ، با توجه به اصل وارونگی وابستگی (dependency inversion) در طراحی شی گرا ، وابستگی باید از DAL به BLL باشد ، و نه بر عکس. بنابراین ، این بدان معناست که ، در هر جایی که اسمبلی DAL را reference دهید ، باید به اسمبلی BLL نیز reference بدهید. به عبارت دیگر ، آنها کاملاً منسجم و جدانشدنی هستند.
مورد دیگر این است که در آن شما چندین برنامه کوچک دارید که در یک پرتال مجزا میزبانی می شوند. بنابراین ، از دید کاربر نهایی این برنامه ها جدا نیستند؛ همه آنها دامنه های مختلف یک برنامه هستند. اما از نظر توسعه ، هر برنامه از سایرین مستقل است. هر برنامه می تواند persistence store خود را داشته باشد. یکی می تواند از اکسل استفاده کند ، دیگری می تواند از SQL Server استفاده کند ، و دیگری می تواند از Oracle استفاده کند.
در این سناریو ، به احتمال زیاد این برنامه ها توسط توسعه دهندگان یا تیم های مختلف توسعه یافته اند. آنها غالباً بطور مستقل توسعه یافته اند ، از این رو باید به چندین پروژه (class library) تقسیم شوند.
برای این سناریو می توانیم پروژه های زیر را در solution داشته باشیم:
باز هم، شما جدایی BLL و DAL را در اینجا مشاهده نمی کنید. هر class library (به عنوان مثال OrderProcessing.Core) شامل منطق و دسترسی به داده ها (BLL و DAL) برای دامنه خود است.
در اینجا چند مورد وجود دارد که امیدوارم از این مقاله آموخته باشید:
و در نهایت: مثل همیشه ، آن را ساده نگه دارید!
منبع : سافت آموز
