یکی از مسائلی که در هنگام کار بر روی یک پروژه انگیولار مواجه می شویم نحوه سازماندهی برنامه و به صورت ساده تر پوشه بندی پروژه می باشد که معمولاً در طول پروژه نیز تغییر می یابد. شاید در پروژه های کوچک و متوسط این موضوع چندان مورد توجه قرار نگیرد ولی در یک پروژه بزرگ که بحث lazy loading  دارای اهمیت است توجه به سازماندهی برنامه و کاهش پیچیدگی منطق برنامه باید مدنظر قرار گیرد. برای پوشه بندی پروژه در سطح اینترنت می توان مثالهای زیادی پیدا کرد که اکثرا توسط نویسندگان آنها مورد استفاده قرار گرفته اند و به نوعی حساب خود را پس داده اند. در این مطلب یک روش تقریباً ترکیبی از روشهای پیشنهادی موجود ارائه خواهد شد که سعی شده بیشترین مطابقت را با بحث ماژول بندی و lazy loading داشته باشد.

پوشه ها

     برای مقایسه روشهای موجود بهتر است از روش خود CLI شروع کنیم. پس از ایجاد یک پروژه جدید توسط CLI ساختاری به صورت زیر ایجاد خواهد شد که (دو کاپوننت جدید نیز اضافه شده است)

- app.module.ts
- app.component.ts
- component1
     component1.component.ts
- component2
     component2.component.ts

     با اضافه شدن کامپوننت های جدید پس از مدتی پروژه دیگر قابل مدیریت نخواهد بود و باعث سردرگم شدن ما خواهد شد. البته می توان سروس ها، پایپ ها و کامپوننت ها را در پوشه های جداگانه مدیریت کرد. در اینصورت نیز یک مشکل باقی خواهد ماند: lazy loading. برای استفاده از این قابلیت که در پروژه های بزرگ نیاز خواهد بود باید منطق برنامه را به ماژول های جداگانه تقسیم بندی کرد. در این حالت نیز با اضافه شدن کامپوننت های جدید به ماژول ها تعداد و حجم کامپوننت ها افزایش خواهد یافت که دوباره همان مشکل قبلی (پیچیده شدن مدیریت پروژه و سردرگمی) خود را نشان خواهد داد. 

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

ساختار پیشنهادی

     برای سازماندهی برنامه با مدل page و partial منطق مدیریت کامپوننت ها را به اینصورت در نظر می گیریم:

          1. page: منظور از page کامپوننت هایی هستند که بصورت مستقیم در بخش routing ماژول ها مشخص می شوند.

          2. منظور از partial کامپوننت هایی هستند که در کنار یکدیگر، یک کامپوننت دیگر را به وجود می آورند.

مثلا فایل routing زیر را در نظر می گیریم:

const routes: [
	{path: 'home', component: HomeComponent}
]

     در این حالت، کامپوننت HomeComponent در منطق موردنظر ما یک page به حساب می آید. در مورد partial هم می توان header، footer و مشابه آنها را در نظر گرفت. در این مدل نیازی نیست منطق ماژول ها تغییر کند و فقط چند پوشه جدید اضافه خواهد شد تا راحت تر بتوان کامپوننت ها را سازماندهی کرد.

با توضیحات فوق ساختار زیر را می توانیم در نظر بگیریم.

- core
	- authentication
	- config
	- guards
	- interceptors
	- models
	- pipes
	- services
- layouts
	- public
		- shop
        	shop-layout.component.ts
        	shop-layout.component.html
        	shop-layout.component.css
	- secure
		- admin
		- customer
- modules
	- public
		- auth
			- models
			- pages
				- login
					login.component.ts
					login.component.html
					login.component.css
			- partials
				- auth-footer
					auth-footer.component.ts
					auth-footer.component.html
					auth-footer.component.css
				- auth-header
			- services				
			auth.module.ts
			auth-routing.module.ts
		- shop
	- secure
		- admin
		- customer
- shared
	shared.module.ts	
	
app.module.ts
app-routing.module.ts

     در ساختار فوق، پوشه های core، layouts و modules صرفاً پوشه هستند نه ماژول انگیولار. پوشه layouts هم برای جداکردن کامپوننتهایی که مربوط به قالب بندی هر بخش از برنامه است استفاده شده که در واقع استایل و placeholder برای کامپوننتهای دیگر در ماژول مربوطه می باشند. این کامپوننت ها در واقع <router-outlet> را شامل می شوند. پوشه های public و secure نیز برای جداسازی منطق بر اساس authentication بکار رفته اند. همانطور که در ساختار هم مشخص است کامپوننت login بعنوان مسیر می باشد و auth-footer و auth-header بعنوان کامپوننت های partial هستند که در کامپوننت اصلی یعنی login استفاده شده اند.

خلاصه

     همانطور که قبلاً هم گفته شد ساختار پیشنهادی چکیده ای از ساختار های موجود در سطح اینترنت است که سعی شده علاوه بر ساده تر شدن سازماندهی پروژه، حداکثر هماهنگی را با ویژگی های انگیولار مانند lazy loading داشته باشد. شاید یکی از ایراداتی که می توان به این ساختار گرفت طولانی شدن import ها در برخی از کامپوننت ها (البته چون برای هر ماژول پوشه های مدل، سرویس و ... را جداگانه در نظر گرفتیم این مشکل در مورد استفاده از سرویس ها و مدل های پوشه های core و shared ممکن است دیده شود) و نیاز به تایپ مسیر طولانی در ایجاد یک کامپوننت جدید (بخاطر تو در تو بودن ماژول ها و پوشه ها) باشد.