web应用的有意义的目录结构

Meaningful Directory Structure for a Webapp

本文关键字：结构 有意义 应用 web      更新时间：2023-09-26

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

我正在使用一个组件结构，就像这篇文章和这篇文章中描述的那样。

假设我有一个类似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文件夹内(如在这个例子中)?

我将以我自己的经验来提问，所以有些人可能同意或不同意，但这当然是基于每个人的意见。

首先看一下我的自己的角度结构(与示例非常相似):

  /
  - 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/(工作作为一个功能)文件夹共享的东西。主要是指令、服务、页眉模板、页脚模板、菜单和它们的控制器。

如果你想要一个具体的例子，你可以看看我正在做的个人项目的代码。

    在编程中，我首先总是尽可能具体地编写代码。如果我意识到有些东西是重复的，我会重构它并概括它。我在这个组织里也一样。如果一个服务只在一个特性中使用，它应该在feature文件夹中。如果这个服务开始在其他一些功能中有用，我将把它移到公共级别。
  1. 在我看来，如果你有这样的东西:admin/speakers和peoples/speakers，我会考虑我真正的特点是什么。我指的是客户端功能。你对人员和管理有控制权吗?那我同意你的建议，还是说你有发言权?在这种情况下，我会用这样的东西:speakers/admin和speakers/people注意it will really depend on your features .
  2. 因为我正在使用功能结构是的。我肯定会去的。item/detail/和item/list/

希望对你有所帮助。如果你想了解更多关于我构建项目的方式的解释，请随时提问。

PS:关于这个的另一个有趣的帖子

编辑:今天我使用这个的一个变体，由于编码应用程序作为组件(与angular 1.5)

相关文章：