“آیا باید پروژه ASP.NET MVC خود را به چندین پروژه تقسیم کنیم؟” جواب کوتاه: نه!

نمیدانم که چگونه این روند شروع شد اما دیده ام که برخی از توسعه دهندگان، یک پروژه ASP.NET MVC را به چندین پروژه تقسیم می کنند: یک پروژه وب حاوی لایه ارائه (presentation logic)، به علاوه دو class library، برای لایه های دیتا و منطق.

 

مفهوم Tiers چیست؟

غالباً به اشتباه تصور می شود که ساختار مطرح شده در بالا، یک برنامه را بصورت Multi-Tier یا ۳-Tier می سازد. برنامه Multi-Tier چیست؟ برنامه ای است که قسمت های آن به صورت فیزیکی در رایانه (ماشین) های مختلف در یک شبکه توزیع می شود. برنامه های وب معمولاً ذاتاً Multi-Tier هستند.

در برنامه های وب اغلب Tier های زیر را داریم:

  1. Client / Presenter Tier: این قطعه در مرورگر کاربر اجرا می شود.
  2. Middle / Application / Logic Tier: این بخشی است که با ASP.NET MVC (یا سایر چارچوب های مشابه سمت سرور) در یک وب سرور اجرا شده است.
  3. Data Tier: پایگاه داده ، file system یا هر نوع ذخیره دیگری است.

وقتی در مورد ASP.NET MVC صحبت می کنیم ، ما فقط در مورد application یا middle tier صحبت می کنیم. جدا کردن یک پروژه ASP.NET MVC به سه پروژه، منجر به اضافه شدن Tierهای جدید در معماری شما نمی شود.

به عبارتی، برای مثال لایه داده را در رایانه دیگری مستقر نمی کنید! بیشتر اوقات (نه همیشه) این ۳ پروژه (وب ، BLL و DAL) در یک فرآیند در یک ماشین، کامپایل و اجرا می شوند؛ وب سرور شما!

وقتی شخصی به سایت شما مراجعه می کند، این DLL ها درون یک فرآیند (یک AppDomain) که توسط IIS اداره می شود، بارگذاری می شود.

 

Layers یا Tiers ؟ مسئله این است!

واژه های Layer و Tier گاها به جای هم استفاده می شوند ولی اساسا متفاوت هستند. Layer برای جدا سازی منطقی کد های برنامه استفاده می شود ولی Tier برای جدا سازی فیزیکی. یعنی توزیع قطعات برنامه در ماشین های مختلف.

Layer چیزی مفهومی در ذهن برنامه نویس است! یک class library یا پوشه، یک لایه نیستند. می توانید کلاس ها را در یک پوشه یا یک class library که متعلق به لایه های مختلف است قرار دهید و به یکدیگر وابسته باشند. که این نشان دهنده ی بد بودن معماری است. قرار دادن این کلاس ها در یک پوشه یا class library مانند BLL و DAL فوراً به نرم افزاری با معماری تمیز و تفکیک خوب منجر نمی شود.

با وجود این ، استدلال من این است که این پوشه ها (BLL و DAL) می توانند و باید در پروژه اصلی وب سکونت داشته باشند و انتقال آنها به یک class library جداگانه ، هیچ ارزشی ندارد.

 

آیا باید پروژه ASP.NET MVC خود را به چندین پروژه تقسیم کنیم؟

۲ دلیل برای تقسیم یک پروژه به پروژه های کوچکتر وجود دارد: قابلیت استفاده مجدد و استقرار مستقل آن پروژه ها.

 

قابلیت استفاده مجدد

یکی از دلایل جدا کردن یک پروژه در چند class library، قابلیت استفاده مجدد است. هنوز قسمت BLL یا DAL یک برنامه وب را که در یک برنامه دیگر مورد استفاده مجدد قرار گرفته است ، مشاهده نکردم. این همان چیزی است که کتابهای دهه ۹۰ میلادی برای ما تعریف می کردند! امروزه اکثر برنامه ها به صورت خاص نوشته می شوند و لایه های آن کمتر در سایر برنامه ها استفاده می شود. اغلب اوقات class libraries ها برای استفاده داخلی خود نرم افزار ساخته می شوند نه برای استفاده مجدد.

 

قابلیت استقرار

یکی دیگر از دلایل جدا کردن یک پروژه در class libraries در مورد استقرار پذیری است. اگر میخواهید قطعات پروژه به صورت مستقل ورژن بندی و مستقر شود، خوب است پروژه را به این شکل لایه بندی کنید. که اغلب در framework ها کاربرد دارد نه برنامه های سازمانی.

Entity Framework مثال خوبی است. این فریم ورک از assembly های مختلفی تشکیل شده است که هر یک حوزه کاربرد خاصی دارد. core assembly شامل قسمت های اصلی این فریم ورک است. اسمبلی دیگری برای ارتباط با SQL server یا سایر پایگاه ها داریم.

با استفاده از این معماری ماژولار ، ما می توانیم فقط قسمتهایی را که لازم داریم را بارگیری کنیم. تصور کنید که Entity Framework فقط شامل یک اسمبلی بود! یک اسمبلی غول پیکر با کد های بسیار زیاد که نیازی به اکثر آن ها نداریم.

همچنین ، هر بار که تیم پشتیبانی یک ویژگی جدید را اضافه کند یا یک اشکال را برطرف کند ، باید کل اسمبلی کامپایل و deploy شود. این باعث می شود این اسمبلی بسیار شکننده شود. اگر برای ارتباط با SQL server از Entity Framework استفاده می کنیم، چرا با آپگرید به نسخه جدید برای رفع مشکل اتصال به SQLite ، برنامه خود را دچار مشکل کنیم؟؟؟ در صورتی که اصلا از SQLite استفاده نمی کنیم! به همین دلیل به شکلی ماژولار طراحی شده است.

در بیشتر برنامه های وب موجود، همه این مجموعه ها (وب ، BLL و DAL) را با هم version و deploy می کنیم. بنابراین ، جدا کردن یک پروژه در ۳ پروژه هیچ ارزشی نمی افزاید.

 

مواردی که باید پروژه ASP.NET MVC را به چند پروژه تقسیم کنیم

بنابراین ، چه موقع واقعاً نیاز دارید که یک پروژه را به صورت فیزیکی از چندین پروژه جدا کنید؟ در اینجا چند سناریو وجود دارد:

 

Multiple presentation layers: چند لایه ارائه داشته باشیم :

فرض کنید که شما یک برنامه پردازش سفارش ایجاد کرده اید. این برنامه یک برنامه دسک تاپ است که توسط کارکنان سازمان شما استفاده می شود. و تصمیم دارید یک رابط وب برای این برنامه ایجاد کنید تا کارکنان بتوانند از طریق اینترنت به آن دسترسی پیدا کنند. و البته می خواهید از DAL و BLL موجود استفاده مجدد کنید.

همانطور که قبلاً توضیح دادم ، یکی از دلایل تقسیم کردن پروژه به چند پروژه، قابلیت استفاده مجدد است. پس در این سناریو پروژه به چند پروژه زیر تقسیم می شود:

  • OrderProcessing.Core (شامل BLL و DAL است)
  • OrderProcessing.Web
  • OrderProcessing.Desktop

توجه داشته باشید که حتی در اینجا من دو پروژه ندارم (BLL و DAL). من یک پروژه با نام OrderProcessing.Core دارم که هم منطق کد و هم دسترسی به داده برای برنامه پردازش سفارش ما را در بر می گیرد. چرا این پروژه را به دو پروژه جداگانه (BLL و DAL) جدا نکردم؟ زیرا هدف اصلی این DAL ، فراهم آوردن یک persistence برای موارد موجود در BLL هست. بسیار بعید است که به تنهایی در پروژه دیگری مورد استفاده قرار گیرد.

همچنین ، با توجه به اصل وارونگی وابستگی (dependency inversion) در طراحی شی گرا ، وابستگی باید از DAL به BLL باشد ، و نه بر عکس. بنابراین ، این بدان معناست که ، در هر جایی که اسمبلی DAL را reference دهید ، باید به اسمبلی BLL نیز reference بدهید. به عبارت دیگر ، آنها کاملاً منسجم و جدانشدنی هستند.

 

Multiple applications under a single portal :  چند برنامه در یک پرتال

مورد دیگر این است که در آن شما چندین برنامه کوچک دارید که در یک پرتال مجزا میزبانی می شوند. بنابراین ، از دید کاربر نهایی این برنامه ها جدا نیستند؛ همه آنها دامنه های مختلف یک برنامه هستند. اما از نظر توسعه ، هر برنامه از سایرین مستقل است. هر برنامه می تواند persistence store خود را داشته باشد. یکی می تواند از اکسل استفاده کند ، دیگری می تواند از SQL Server استفاده کند ، و دیگری می تواند از Oracle استفاده کند.

در این سناریو ، به احتمال زیاد این برنامه ها توسط توسعه دهندگان یا تیم های مختلف توسعه یافته اند. آنها غالباً بطور مستقل توسعه یافته اند ، از این رو باید به چندین پروژه (class library) تقسیم شوند.

برای این سناریو می توانیم پروژه های زیر را در solution داشته باشیم:

  • OrderProcessing.Core (یک class library)
  • Shipping.Core
  • CustomerSupport.Core
  • MainPortal (یک پروژه ASP.NET MVC)

باز هم، شما جدایی BLL و DAL را در اینجا مشاهده نمی کنید. هر class library (به عنوان مثال OrderProcessing.Core) شامل منطق و دسترسی به داده ها (BLL و DAL) برای دامنه خود است.

 

سخن پایانی

در اینجا چند مورد وجود دارد که امیدوارم از این مقاله آموخته باشید:

  • Layers ها tiers نیستند
  • Tiers در مورد توزیع فیزیکی نرم افزار در رایانه های مختلف است.
  • لایه ها مفهومی هستند. داشتن پوشه یا اسمبلی به نام BLL یا DAL به این معنی نیست که شما به درستی برنامه خود را لایه بندی کرده اید ، همچنین به این معنی نیست که شما از قابلیت نگهداری بهتر برخوردار هستید.
  • قابلیت نگهداری بهتر یعنی: متد های و کلاس های کوچکتر که هریک وظیفه مشخصی دارند و وابستگی بسیار کمی بین آنها وجود دارد.
  • اسمبلی ها واحد های versioning و deployment هستند.
  • اگر می خواهید از قسمت های خاصی از آن در پروژه های دیگر استفاده مجدد کنید ، یا اگر می خواهید به طور مستقل هر پروژه را نسخه و مستقر کنید ، یک پروژه را به چندین پروژه تقسیم کنید.

 

و در نهایت: مثل همیشه ، آن را ساده نگه دارید!

 

منبع : http://bit.ly/2kgPcSg

 

همچنین بخوانید: مسائل مهمی که هر یک از توسعه دهندگان سی شارپ باید بدانند