Webapp的有意义的目录结构

时间:2015-06-02 14:47:45

标签: javascript angularjs web-applications single-page-application directory-structure

所以在我的情况下我有一个angularJS应用程序,但我认为这个问题真的适用于任何单页应用程序。

我使用了thisand this等各种文章中描述的组件结构。

所以,让我假设我的结构与John Papa的结构相似

app/
    app.module.js
    app.config.js
    app.routes.js
    directives.js
    layout/
        shell.html      
        shell.controller.js
        topnav.html      
        topnav.controller.js       
    people/
        attendees.html
        attendees.controller.js  
        speakers.html
        speakers.controller.js
        speaker-detail.html
        speaker-detail.controller.js
    sessions/
        sessions.html      
        sessions.controller.js
        session-detail.html
        session-detail.controller.js  
    services/       
        data.service.js  
        localstorage.service.js
        logger.service.js   
        spinner.service.js

这里有一些问题,关于什么是最好的方式(按照你的经验)来遵循这个范例,可能出现什么问题以及如何避免将来的问题与我们正在讨论的目录结构有关随着时间的推移会变大并变大的大应用程序:

  • 如果spinner.service.js仅在layout控制器中使用,我应该将其放在/layout文件夹中吗?或者任何服务应该始终位于通用文件夹中?

  • 假设我想在另一个页面中使用/people/speakers 作为部分内容,请说/admin/speakers。我该如何管理?在speakers/people的同一级别上制作/admin个独立组件?

  • 这是一个更通用的问题,每当我同时拥有一个项目的detail view和一个显示这些项目列表的list view时:将所有内容放入其中更好/item文件夹(如本例所示)?

1 个答案:

答案 0 :(得分:1)

我会根据自己的经验询问,所以有些人可能会同意或不同意,但这当然是基于每个人的意见。

首先看一下我的自己的角度结构(非常类似于例子):

  /
  - app/
      - feature/
          - {featurename}/
               - controller/  // -> Put here all your MyFeatureController.js files
               - directive/   // -> List of components relative to this feature
               - service/     /* -> Utilities mostly SomethingService.js 
                                 returning promises from back end calls
                                 and SomethingElseHelper.js used to factorize 
                                 all the business logic */
               - template/    // -> Partial HTML files that are not user final view
               - view/        // -> All the views
                              //    Theses are used as endpoint in your routing

这就是全部。在大型应用程序上,它可以适应一些子功能。我总是有一个common/(作为功能)文件夹用于共享内容。主要是指令,服务,页眉,页脚,菜单及其控制器的模板。

如果你想要一个特定的例子,你可以看看personal project's code我正在做什么。

回答您的问题:

  1. 在编程中,我首先总是尽可能具体地编码。如果我意识到某些事情是重复的,我会重构并推广它。我在结构中的工作方式相同。如果服务仅用于功能,则它应位于功能文件夹中。如果此服务在某些其他功能中开始有用,我会将其移至公共级别。
  2. 在我看来,如果你有这样的东西:admin/speakerspeoples/speakers我会考虑我的真实特征。我的意思是客户端功能。你控制人民和管理员吗?那么我会用你的上位命题,还是你控制扬声器?在这种情况下,我会这样做:speakers/adminspeakers/people 请注意it will really depend on your features
  3. 因为我正在使用功能结构。我一定会去的。如果需要,可以结束此操作:item/detail/item/list/
  4. 希望它对你有所帮助。如果您想要更多关于构建项目的我的方式的解释,请随时提问。

    PS:关于此

    的另一个有趣的post

    编辑:今天我使用了这种变体,因为将应用程序编码为组件(角度为1.5)