وحید نصیری وحید نصیری
سازماندهی برنامه‌های Angular توسط ماژول‌ها
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: پنج دقیقه
یک برنامه‌ی Angular، از گروهی از کامپوننت‌ها تشکیل می‌شود؛ برای مثال یک کامپوننت App وجود دارد که آن نیز از تعدادی کامپوننت مختلف تشکیل می‌شود. ماژول‌ها کار سازماندهی و بسته بندی این کامپوننت‌ها را انجام می‌دهند و با بزرگتر شدن برنامه می‌توان قسمت‌های مختلف را در ماژول‌های متفاوتی قرار داد. مزایای این روش به شرح زیر هستند:
- بهبود کپسوله سازی قسمت‌های مختلف برنامه با بسته بندی آن‌ها در ماژول‌های متفاوت
- فراهم آوردن امکان lazy loading و بهبود کارآیی برنامه


انواع ماژول‌های توصیه شده‌ی در برنامه‌های Angular

منهای App Module پیش‌فرض یک برنامه‌های Angular، ایجاد سه نوع ماژول دیگر نیز در جهت سازماندهی اینگونه برنامه‌ها توصیه می‌شوند:
- Core Module
هدف از آن فراهم آوردن سرویس‌های Singleton اشتراکی بین کامپوننت‌ها و ماژول‌های مختلف برنامه است. علت این‌جا است که سیستم تزریق وابستگی‌های Angular، به ازای هر ماژولی که Lazy loaded باشد، سرویس تزریقی در آن‌ها را مجددا وهله سازی می‌کند. به همین جهت نیاز است تک ماژول اختصاصی را برای مدیریت سرویس‌هایی که نیازی است تنها یکبار در طول عمر برنامه وهله سازی شوند، تدارک ببینیم و Core Module مکان مناسبی برای این‌کار است.
همچنین Code Module باید شامل کامپوننت‌هایی در سطح برنامه باشد. دراینجا منظور از «در سطح برنامه»، کامپوننت‌هایی که قرار است در بین تمام ماژول‌ها به اشتراک گذاشته شوند، نیست. منظور تنها کامپوننت‌هایی هستند که در App Component اصلی برنامه قرار است استفاده شوند؛ مانند منوی راهبری بالای سایت.

- Shared Module
هدف از آن مدیریت و بسته بندی کامپوننت‌ها، دایرکتیوها و Pipes اشتراکی بین تمام اجزای برنامه است. برای مثال کامپوننت «لطفا منتظر بمانید ...» اگر قرار است در تمام قسمت‌های برنامه استفاده شود، نیاز است در Shared Module تعریف شود. از این جهت که در یک برنامه‌ی Angular نمی‌توان یک کامپوننت را بین دو ماژول مختلف به اشتراک گذاشت. به همین جهت نیاز است یک مکان مرکزی برای تعریف این کامپوننت‌های اشتراکی ایجاد شود و سپس این تک ماژول را در قسمت‌های مختلف برنامه، بدون مشکل مورد استفاده قرار داد.

- Feature Module
این ماژول‌ها به ازای هر ویژگی برنامه ایجاد شده و کامپوننت‌ها، سرویس‌ها، دایرکتیوها و Pipes اختصاصی آن ویژگی را بسته بندی می‌کنند.


ایجاد Core Module

فرض کنید می‌خواهید اطلاعات کاربر جاری لاگین شده را در طول عمر برنامه نگهداری کنید و از آن در تمام قسمت‌های برنامه استفاده نمائید. یک چنین سرویسی نیاز است دارای طول عمر Singleton باشد و تنها یکبار وهله سازی شود تا اطلاعات کاربر جاری از دست نرود. به همین جهت بهترین مکان تعریف این سرویس، در Core Module است.
برای این منظور در ساختار برنامه‌ی خود، پوشه‌ی جدید src\app\core را ایجاد می‌کنیم. سپس فایل core.module.ts را به صورت ذیل در آن تعریف خواهیم کرد:
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';

import { UserRepositoryService } from './user-repository.service';
import { NavBarComponent } from './nav-bar.component';
import { AccountMenuComponent } from './account-menu.component';

@NgModule({
  imports: [ CommonModule, RouterModule ],
  exports: [ NavBarComponent, AccountMenuComponent ],
  declarations: [ NavBarComponent, AccountMenuComponent ],
  providers: [ UserRepositoryService ]
})
export class CoreModule { };
 - CoreModule در ابتدا تنها CommonModule و RouterModule را در صورت نیاز import می‌کند.
 - سپس سرویس‌های اشتراکی و Singleton برنامه در قسمت providers آن قرار می‌گیرند.
 - در اینجا همچنین دو کامپوننت منو که توسط app.component.ts مورد استفاده قرار می‌گیرند نیز import شده‌اند.
 - فایل‌های account-menu.component.ts، nav-bar.component.ts و user-repository.service.ts نیز به درون پوشه‌ی src\app\core منتقل خواهند شد (به همراه تمام فایل‌های html و css متناظر با آن‌ها).
 - اگر دقت کنید، قسمت exports این ماژول نیز مقدار دهی شده‌است. چون این کامپوننت‌ها قرار است خارج از این ماژول و در AppModule استفاده شوند، نیاز است آن‌ها را به صورت خروجی نیز معرفی کنیم.

اکنون جهت استفاده‌ی از این قابلیت‌ها، تنها کافی است تعریف CoreModule را به AppModule در فایل app.module.ts اضافه کنیم:
import { CoreModule } from "./core/core.module";

@NgModule({
  imports:      [
//...
    CoreModule,
//...
    RouterModule.forRoot(appRoutes)
  ],
//...
})
export class AppModule { }


ایجاد Shared Modules

در Shared Module اجزایی را قرار خواهیم داد که قرار است در بیش از یک ماژول مورد استفاده قرار گیرند. به همین جهت در ساختار برنامه‌ی خود، پوشه‌ی جدید src\app\shared را ایجاد می‌کنیم. سپس در آن، ماژول جدید shared.module.ts را ایجاد خواهیم کرد:
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';

import { LoadingSpinnerComponent } from './loading-spinner.component';

@NgModule({
  imports: [ CommonModule ],
  declarations: [ LoadingSpinnerComponent ],
  exports: [ LoadingSpinnerComponent, CommonModule ],
  providers: [ ]
})
export class SharedModule { };
ساختار این ماژول نیز شبیه به Core Module است. ابتدای CommonModule به آن import شده‌است. سپس کامپوننت‌هایی که قرار است در بین سایر ماژول‌های سایت به اشتراک گذاشته شوند (برای مثال یک کامپوننت Loading Spinner فرضی)، در هر دو قسمت declarations و exports این ماژول اشتراکی قرار می‌گیرند. همچنین فایل loading-spinner.component.ts و تمام اجزای وابسته‌ی به آن نیز به پوشه‌ی src\app\shared منتقل می‌شوند.
از این جهت که اجزای خروجی این ماژول قرار است در Feature Moduleها استفاده شوند، CommonModule مورد استفاده‌ی در آن‌ها نیز در قسمت exports ذکر شده‌است.

اکنون جهت استفاده‌ی از این قابلیت‌ها، تنها کافی است تعریف SharedModule را به AppModule در فایل app.module.ts اضافه کنیم:
import { CoreModule } from "./core/core.module";
import { SharedModule } from "./shared/shared.module";

@NgModule({
  imports:      [
//...
    CoreModule,
    SharedModule,
//...
    RouterModule.forRoot(appRoutes)
  ],
//...
})
export class AppModule { }


ایجاد Feature Modules

این مورد نکته‌ی ویژه‌ای را به همراه ندارد و همانند ایجاد سایر ماژول‌های برنامه‌است. برای مثال ویژگی مدیریت کاربران، به همراه تمام اجزای آن درون ماژول کاربران قرار می‌گیرد و به همین ترتیب برای سایر ویژگی‌های دیگر برنامه. ایجاد و مدیریت اینگونه ماژول‌ها توسط Angular CLI بسیار ساده‌است:
> ng g m users -m app.module --routing
> ng g c users/users-list
دستور اول ایجاد ماژول جدید users، پوشه‌ی مرتبط با آن و همچنین به روز رسانی فایل app.module را به صورت خودکار انجام می‌دهد.
دستور دوم نیز کامپوننتی را به این ماژول اضافه می‌کند؛ به همراه به روز رسانی تعاریف این ماژول.

فقط در اینجا SharedModule ایی را که پیشتر اضافه کردیم، به قسمت imports آن اضافه می‌کنیم:
import { NgModule } from '@angular/core';
import { RouterModule } from '@angular/router';

import { SharedModule } from '../shared/shared.module';
import { UsersListComponent } from './users-list.component';

@NgModule({
  imports: [ RouterModule, SharedModule ],
  declarations: [ UsersListComponent ],
  exports: [  ],
  providers: [ ]
})
export class UsersModule { };
‫۶ سال و ۱۱ ماه قبل، یکشنبه ۷ آبان ۱۳۹۶، ساعت ۱۵:۵۰
۸۲۲۵
۱۲
Angular
مطالب مشابه
  • #
    وحید نصیری وحید نصیری
    ‫۶ سال و ۱۱ ماه قبل، دوشنبه ۸ آبان ۱۳۹۶، ساعت ۱۳:۴۳
    توضیحات تکمیلی در مورد Core Module

    اگر به CoreModule تعریف شده دقت کنید، یک چنین تعریفی در آن ذکر شده‌است:
       providers: [ UserRepositoryService ]
    برای درک یک چنین تعریفی، نیاز است با نحوه‌ی عملکرد Angular Injector آشنا شد. برای این منظور فرض کنید برنامه‌ای را با سه ماژول طراحی کرده‌اید: یک App Module و دو ماژول معمولی و دیگری Lazy loaded. به ازای هر برنامه، Angular یک Root Injector را ایجاد می‌کند و کار آن تزریق سرویس‌ها، در مکان‌هایی است که به آن‌ها نیاز هست. این Root Injector نیز در App Module و در بالاترین سطح برنامه تشکیل می‌شود.
    اکنون فرض کنید سرویسی را در ماژول معمولی غیر Lazy loaded تعریف کرده‌اید. Angular این سرویس را در Root Injector ثبت می‌کند. به این ترتیب این سرویس در کل برنامه قابل دسترسی می‌شود. اما اگر سرویسی را در یک ماژول Lazy loaded تعریف کنید، Angular کار ایجاد یک Injector جداگانه را برای آن ماژول و در داخل آن انجام می‌دهد. این Injector مجزا است از Root Injector قرار گرفته‌ی در App Module. سپس این سرویس در این Injector جدید ثبت می‌شود. به این ترتیب، وهله‌ی تهیه شده‌ی از این سرویس، تنها درون این ماژول Lazy loaded قابل دسترسی است. حتی اگر این دو سرویس ثبت شده‌ی در Root Injector و Injector مخصوص ماژول Lazy loaded از یک کلاس تهیه شوند، باز هم دو وهله‌ی مختلف از آن ارائه می‌شوند. برای مثال اگر UserRepositoryService را در ماژول معمولی و ماژول Lazy loaded مورد استفاده قرار دهیم، دو وهله‌ی مجزای از آن‌ها تشکیل خواهد شد که دیگر با هم همگام نبوده و کار ردیابی اطلاعات کاربر جاری سیستم را با مشکل مواجه می‌کنند.
    ایجاد وهله‌ی دوم از یک سرویس، تنها منحصر است به ماژول‌های Lazy loaded. اما اگر این سرویس در ماژول‌های معمولی مختلفی مورد استفاده قرار گیرد، Angular تنها یک وهله از آن‌را ایجاد خواهد کرد. به همین جهت است که در این‌جا CoreModule را تعریف کردیم. این ماژول مکانی است که قرار است سرویس‌های اشتراکی در کل برنامه در آن قرار گیرند. چون این ماژول هیچگاه Lazy loaded نخواهد شد، هرگاه سرویسی را توسط آن ارائه دهیم، در Root Injector مربوط به App Module ثبت می‌شود. به این ترتیب تبدیل به یک Singleton Service قابل دسترسی در کل برنامه می‌شود.
    باید دقت داشت که از لحاظ فنی، تفاوتی بین Core Module و یک ماژول معمولی غیر Lazy loaded نیست و بیشتر هدف از آن نظم بخشیدن به تعریف سرویس‌هایی است که قرار است در طول عمر برنامه و در تمام انواع ماژول‌های آن، توسط یک وهله قابل دسترسی شوند.
    بنابراین تفاوتی نمی‌کند که یک سرویس را درون Core Module تعریف کنید و یا یک ماژول معمولی. این سرویس همواره در Root Injecror ثبت خواهد شد؛ مگر اینکه آن ماژول Lazy loaded باشد. در این حالت اگر سرویسی تنها قرار است در یک ماژول خاص استفاده شود، بهتر است آن‌را جهت مدیریت بهتر برنامه، درون همان پوشه تعریف کرد. هرچند از لحاظ فنی، این سرویس‌ها نهایتا در Root Injector مربوط به App Module ثبت و ارائه می‌شوند (از این لحاظ فرقی بین یک Core Module و Feature Modules نیست).
  • #
    وحید نصیری وحید نصیری
    ‫۶ سال و ۱۰ ماه قبل، سه‌شنبه ۳۰ آبان ۱۳۹۶، ساعت ۱۶:۴۹
    چند نکته‌ی تکمیلی در مورد بهبود تعاریف Shared Module و Core Module

    الف) چگونه از import ثانویه‌ی Core Module در سایر ماژول‌ها جلوگیری کنیم؟
    Core Module فقط باید در AppModule برنامه import شود و نه در هیچ‌جای دیگری. برای جلوگیری اتفاقی از این مساله می‌توان سازنده‌ای را به شکل زیر به آن اضافه کرد:
    @NgModule({
  imports: [CommonModule, RouterModule],
  exports: [], // components that are used in app.component.ts will be listed here.
  declarations: [], // components that are used in app.component.ts will be listed here.
  providers: [BrowserStorageService, AppConfigService] // global singleton services of the whole app will be listed here.
})
export class CoreModule {
  constructor( @Optional() @SkipSelf() core: CoreModule) {
    if (core) {
      throw new Error("CoreModule should be imported ONLY in AppModule.");
    }
  }
};
    روش کار به این صورت است که خود CoreModule را به سازنده‌ی همان کلاس تزریق می‌کنیم! اگر وهله‌ای از آن قابل دسترسی بود، یعنی Angular پیشتر این ماژول را import کرده‌است. در این حالت با صدور خطایی این مشکل را گوشزد می‌کنیم.
    از همین روش برای تشخیص singleton بودن یک سرویس نیز می‌توان استفاده کرد. خودش را به خودش تزریق می‌کنیم! اگر تزریقی صورت گرفت، یک خطا را صادر می‌کنیم.


    ب) چگونه از وهله سازی مجدد سرویس‌های تعریف شده‌ی در Shared Module در سایر ماژول‌ها جلوگیری کنیم؟
    هدف از قسمت providers در Shared Module تنها ارائه‌ی سرویس‌هایی جهت کامپوننت‌های اشتراکی آن است؛ وگرنه سرویس‌های سراسری برنامه در CoreModule تعریف می‌شوند و این ماژول ویژه نیز تنها یکبار و آن‌هم در AppModule برنامه import خواهد شد. اما در مورد Shared Module اینطور نیست و اگر این ماژول در یک lazy loaded module استفاده شود، سرویس‌های آن طول عمر متفاوتی را پیدا خواهند کرد (هر lazy loaded module یک injector و یک طول عمر خاص خودش را تعریف می‌کند).
    در این حالت برای اینکه سرویس‌های Shared Module فقط در AppModule وهله سازی شوند و نه در هیچ‌جای دیگری، روش کار به صورت ذیل است:
    - ابتدا آرایه‌ی providers را از تعاریف NgModule آن حذف می‌کنیم.
    - سپس متد ویژه‌ای را به نام forRoot، به کلاس آن اضافه خواهیم کرد:
    @NgModule({
  imports: [CommonModule],
  declarations: [], // common and shared components/directives/pipes between more than one module and components will be listed here.
  exports: [CommonModule], // common and shared components/directives/pipes between more than one module and components will be listed here.
  /* No providers here! Since they’ll be already provided in AppModule. */
})
export class SharedModule {
  static forRoot(): ModuleWithProviders {
    // Forcing the whole app to use the returned providers from the AppModule only.
    return {
      ngModule: SharedModule,
      providers: [ /* All of your services here. It will hold the services needed by `itself`. */]
    };
  }
};
    متد forRoot به صورت استاتیک تعریف می‌شود و همچنین خروجی از نوع ModuleWithProviders دارد. توسط ModuleWithProviders سبب خواهیم شد، AppModule، این ماژول را به همراه آرایه‌ی providers آن import کند؛ اما سایر ماژول‌ها خیر.
    سایر ماژول‌ها چون دسترسی به آرایه‌ی حذف شده‌ی providers این ماژول را ندارند، دیگر نمی‌توانند سرویس‌های آن‌را وهله سازی کنند. اما AppModule با فراخوانی ()SharedModule.forRoot در لیست import خود، تنها یکبار سبب وهله سازی سرویس‌های آن می‌گردد.
    بنابراین در اینجا AppModule باید ()SharedModule.forRoot را import کند. سایر ماژول‌ها فقط SharedModule را import می‌کنند (بدون ذکر متد forRoot). به این ترتیب سرویس‌های آن تنها یکبار توسط AppModule در طول عمر برنامه به اشتراک گذاشته می‌شوند و در این حالت تفاوتی نمی‌کند که SharedModule در یک lazy loaded module استفاده شده‌است یا خیر.

    روش تعریف متد forRoot توسط سیستم مسیریابی Angular نیز استفاده می‌شود و یک الگوی پذیرفته شده در بین توسعه دهندگان Angular است. برای مثال ()RouterModule.forRoot در AppModule تعریف می‌شود و ()RouterModule.forChild برای سایر ماژول‌ها.

    نمونه‌ای از AppModule ، ShardModule و CoreModule
    • #
      محمد دلیری محمد دلیری
      ‫۶ سال و ۹ ماه قبل، پنجشنبه ۳۰ آذر ۱۳۹۶، ساعت ۲۳:۰۳
      کار متد ()optimal@ و ()skipself@ چیست ؟
      • #
        وحید نصیری وحید نصیری
        ‫۶ سال و ۹ ماه قبل، پنجشنبه ۳۰ آذر ۱۳۹۶، ساعت ۲۳:۲۴
        - ویژگی Optional به معنای اختیاری بودن این پارامتر در تزریق وابستگی‌ها است. یعنی اگر تعاریف این وابستگی تزریقی پیشتر در سیستم تزریق وابستگی‌ها ثبت نشده بود، بجای صدور خطا، این شیء، این وابستگی را به صورت نال دریافت خواهد کرد.
        - ویژگی SkipSelf به معنای الزام به استفاده‌ی از وهله‌ی تزریق شده‌ی توسط والد هست؛ بجای وهله‌ی ارائه شده‌ی توسط تزریق کننده‌ی فعلی. برای مثال استفاده‌ی از ماژول‌های lazy loaded سبب ایجاد یک تزریق کننده‌ی خاص خود آن‌ها می‌شود که با         Root Injector یکی نیست. به همین جهت در اینجا اعلام می‌کنیم که از تزریق کننده‌ی جاری صرفنظر کن و با Root Injector کار کن.
  • #
    کیانی مقدم علیرضا کیانی مقدم علیرضا
    ‫۶ سال و ۱۰ ماه قبل، چهارشنبه ۸ آذر ۱۳۹۶، ساعت ۱۷:۲۰
    سلام ؛ اگر قرار باشد کلیه روتهای برنامه به عنوان childrout‌های والدی مثلا pages باشند از آنجا که برنامه حاوی چندین feature modules است تعریف همه  روتها در app-routing باشد ؟ یا در featureX-routing  ؟ (روت والد دارای کامپوننت page-component می‌باشد و منظور گروه بندی  تنها نیست . ) با تشکر .
    • #
      وحید نصیری وحید نصیری
      ‫۶ سال و ۱۰ ماه قبل، چهارشنبه ۸ آذر ۱۳۹۶، ساعت ۱۷:۵۵
      زمانیکه یک feature module را از طریق دستور «ng g m users -m app.module --routing » ایجاد می‌کنید، به صورت خودکار user.module.ts و user-routing.module.ts را ایجاد می‌کند که این user-routing.module در user.module به صورت خودکار ثبت می‌شود. بنابراین با معرفی user.module به ماژول اصلی برنامه (همان قسمت m app.module-)، کار ثبت تمام مسیریابی‌های آن هم خودکار خواهد بود.
  • #
    بابک داوودی بابک داوودی
    ‫۶ سال و ۷ ماه قبل، سه‌شنبه ۲۴ بهمن ۱۳۹۶، ساعت ۰۵:۳۷
    لطفا اگر ممکن هست یک ساختار (ویژوال) برای پروژه‌های بزرگ شامل چند زیر سیستم(ماژول) به همراه ماژول‌های Core,Shared , ... در Angular 5 ارائه نمائید. راستش من چند تا دیدم اما هنوز نتونستم به جمع بندی برسم. گفتم نظر شما رو هم بدونم. منظورم ساختاری مانند زیر است:

    سپاس از شما

  • #
    وحید نصیری وحید نصیری
    ‫۶ سال و ۴ ماه قبل، سه‌شنبه ۱ خرداد ۱۳۹۷، ساعت ۱۶:۱۵
    ارتقاء به Angular 6: ساده سازی قسمت providers در CoreModule

    ویژگی جدیدی به Angular 6 به نام tree-shakable providers اضافه شده‌است که نمونه‌ای از کاربرد آن به صورت پیش‌فرض در حین «ایجاد پروژه‌ی «کتابخانه» توسط Angular CLI 6.0» ارائه می‌شود. به این معنا که با استفاده‌ی از آن دیگر نیازی نیست تا سرویس‌های سراسری برنامه را در قسمت providers مربوط به CoreModule ثبت کرد. همینقدر که یک سرویس سراسری را به صورت ذیل تعریف کنید:
    import { Injectable } from '@angular/core';
@Injectable({
    providedIn: 'root'
})
export class MyCoreService { }
    خاصیت providedIn آن کار ثبت این سرویس را به صورت خودکار انجام می‌دهد. تفاوت آن با حالت قبل این است که اگر این سرویس جایی در برنامه استفاده نشده باشد، tree-shakable خواهد بود. یعنی به صورت کد مرده در نظر گرفته شده و به prod bundle اضافه نمی‌شود که سبب کاهش حجم نهایی برنامه می‌گردد.
    در این حالت تزریق وابستگی‌هایی که در مطلب «تزریق وابستگی‌ها فراتر از کلاس‌ها در برنامه‌های Angular» نیز بحث شدند، پشتیبانی می‌شود:
    @Injectable({
    providedIn: 'root',
    useClass: LazyFlightCancellingService,
    deps: [NgModuleFactoryLoader, Injector] 
})
export class FlightCancellingService { }
    فقط مواردی مانند ثبت interceptors و حالت‌هایی که به همراه InjectionToken هستند، هنوز هم باید از طریق قسمت providers صورت گیرد.

    به عنوان مثال کدهای مخزن کد «اعتبارسنجی کاربران در برنامه‌های Angular» جهت استفاده‌ی از این قابلیت به روز شد.
  • #
    ابوالفضل روشن ضمیر ابوالفضل روشن ضمیر
    ‫۵ سال و ۸ ماه قبل، چهارشنبه ۳ بهمن ۱۳۹۷، ساعت ۰۲:۱۲
    فرض می‌کنیم در حال توسعه یک سیستم بزرگ می‌باشم که مثلا شامل چندین بخش مختلف مثل  Admin/Client/Colleague /Careworker و.. می‌باشد . تعدادی کامپوننت داریم که قرار است در تمامی بخش‌ها استفاده شود ( مثلا کامپوننت لیست سرویس‌ها / جزئیات سرویس‌ها و .. ) ، که تعداد این کامپوننت‌ها 200 یا بیشتر از 200 می‌باشد . در این حالت ، این کامپوننت‌ها را به Shared ماژول انتقال می‌دهیم جهت جلوگیری از ایجاد کامپوننت‌های تکراری و در نهایت بر اساس توضیحات بالا Shared ماژول را با forRoot در AppModule بخش import معرفی می‌کنیم و در سایر ماژول‌ها خود SharedModule را در بخش import معرفی می‌کنیم . 

    1-آیا حداقل و حداکثر تعداد، برای کامپوننت‌ها در SharedModule وجود دارد ؟
    2-آیا با افزایش تعداد کامپوننت‌ها درماژول  Shared  امکان کند شدن لود اولیه وجود دارد ؟ 
    3- انتقال کامپوننت‌های مثل کامپوننت لیست سرویس‌ها / جزئیات سرویس‌ها و .. به ماژول Shared با توجه به اینکه قرار است در چند بخش مختلف استفاده شوند کار صحیحی است ؟