структурирование приложения AngularJS

Question

У нас есть довольно большое приложение angularJS, где все контроллеры находятся в одном файле.

Мы думаем о разделении каждого контроллера на соответствующий файл. есть ли причина, почему бы не сделать это?

Причина, по которой мы хотим разделить ее, заключается в упрощении управления/изменения источника в файле и, очевидно, гораздо более интуитивно понятной.

Просьба сообщить.

Answer 1

От an article by Brian Ford:

Вероятно, самый большой вопрос с большими приложениями, где поставить все , что код. На вашем инструментальном инструменте у вас есть файлы, каталогов, модулей, сервисов и контроллеров. Для краткого обзора хорошей структуры проекта AngularJS, проверьте Угловое семя на Github. Однако я хотел бы углубиться и предложить дополнительные рекомендации по структуре проекта. Начнем с каталогов и проложим путь по списку.

Например ваша структура файла может выглядеть так:

project/ 
     app.js 
     controllers/ #your controllers files here 
     views/ #your templates here 
     services/ #your services files 
     directives/ #your custom directives 

Каждый файл должен иметь одну «вещь» в нем, где «вещь» является контроллер, директива, фильтр или услуги. Это делает для небольших, сфокусированных файлов. Это также помогает создать лакмусовый тест для того, как делают API . Если вы часто просматриваете файлы слишком часто, , это свидетельствует о том, что ваши API слишком сложны. Вы, , должны переосмыслить, реорганизовать и упростить.

Проверьте статью для получения более подробной информации.

Answer 2

Существует множество различных способов структурирования вашего приложения, и вряд ли вы правы или неправы. Нет, нет причин, почему бы не сделать это, и похоже, что это имеет смысл.

Я лично решил использовать следующую структуру, основанную на моем опыте, чтобы дать вам пример:

Я использую структуру каталогов углового Seed проекта:

• приложение/JS -> содержит все динамические JS скрипты
• приложения/Библиотека/angular114 -> содержит текущую версию angularjs (я могу использовать несколько версии для целей тестирования таким образом)
• приложения/Lib/моякомп -> содержит все мои компании/личные многоразовых библиотеки го при хранении в отдельном репозитории
• app/partials -> содержит все мои частичные части html, которые я делю в подкаталоги на основе структуры js-файлов в app/js. Если у меня есть user.js, то у меня есть каталог пользователя.

Собственный Libs

В моих собственных библиотек, которые находятся в Lib/MyCompany Я PREfix все файлы, а также имена методов с моей приставкой компании. Если моя компания будет называться East Asia Ltd., я бы создал двухбуквенный префикс под названием «ea». Это предотвратит столкновения имен с моими динамическими js-скриптами, поскольку имена контроллеров и сервисов могут быть общедоступны через мое приложение.

Библиотека/еа/еа-validators.js

(function() { 
    'use strict' 
    angular.module('eaValidators', []) 
    .directive('eaValidateUnique', [function() { 
     // directive code goes here 
    }]) 
    .directive('eaValidateId', [function() { 
     // code goes here 
    }]) 
    .controller('MyCtrlJustAsExample', ['$scope', function($scope) { 
     // code goes here 
    }]);  
})(); 

я группа все, чтобы логические модули, такие как:

• Validation Модуль
• Global Обработка ошибок Модуль
• Модуль аутентификации/авторизации
• ...

Модуль аутентификации, например, содержит директивы, контроллеры, службы и т. Д. Я различаю логические сущности, а затем различаю контроллеры, директивы и т. Д. Я считаю, что эта структура более эффективна, потому что, когда я хочу изменить, например, что-то связанное с проверкой, я знаю, что она находится в моем модуле проверки.

Вы можете найти примеры здесь: http://chstrongjavablog.blogspot.ch/

Dynamic Content

У меня есть подход к похож моих динамических JS-файлов. Если у меня есть, например, страницы пользователя и страницы поставщика Я хочу, чтобы отобразить затем создать следующие файлы в моем каталоге JS:

• user.js
• vendor.js

Опять эти файлы может содержать директивы, контроллеры, службы в том же файле, сгруппированные по модулю. Поэтому, если мне нужно изменить что-то, связанное с пользователем, я сразу понял, что найду код в user.js.

А образец user.js может выглядеть следующим образом:

JS/user.js

angular.module('user', ['ngResource']) 
    .controller('UserListCtrl', ['$scope', 'User', function($scope, User) { 
    // code goes here 
    }]) 
    .controller('UserNewCtrl', ['$scope', 'User', function($scope, User) { 
    // code goes here 
    }]) 
.factory('User', ['$resource', function($resource) { 
    return $resource('/api/user/:userId', {userId: '@id'}); 
}]);  

Клей все вместе

Js/app.js

Затем я использую js/app.js для склеивания всего вместе и выполните маршрутизацию:

angular.module('myApp', ['eaValidators', 'vendor', 'user']) 
    .config(['$routeProvider', function($routeProvider) { 
    $routeProvider.when('/user', {templateUrl: 'partials/user/user-list.html', controller: 'UserListCtrl'}); 
    $routeProvider.when('/user/new', {templateUrl: 'partials/user/user-new.html', controller: 'UserNewCtrl'}); 
    $routeProvider.otherwise({redirectTo: '/user'}); 
}]) 
    .config(['$httpProvider', function ($httpProvider) { 
    $httpProvider.defaults.headers.common['Content-Type'] = 'application/json'; 
    $httpProvider.defaults.headers.common['Accept'] = 'application/json'; 
}]); 

Затем я просто подключаю файлы в основном индексе.HTML-файл:

index.html

<!doctype html> 
<html lang="en" ng-app="myApp"> 
<head> 
    <meta charset="utf-8"> 
    <title>YourApp</title> 
    <link rel="stylesheet" href="css/app.css"/> 
    <link rel="stylesheet" href="css/style.css"/> 
    <link rel="stylesheet" href="css/ea-validators.css"/> 
</head> 
<body> 

    <!-- Display partial pages --> 
    <div ng-view></div> 

    <!-- Include all the js files. In production use min.js should be used --> 
    <script src="lib/jquery203/jquery-2.0.3.js"></script> 
    <script src="lib/angular114/angular.js"></script> 
    <script src="lib/angular114/angular-resource.js"></script> 
    <script src="lib/ea/ea-validators.js"></script> 
    <script src="js/app.js"></script> 
    <script src="js/user.js"></script> 
    <script src="js/vendor.js"></script> 
</body> 
</html> 

Преимущество этой конструкции является то, что я могу скопировать, например, user.js и парциальных пользователей более в другой проект, и повторно использовать большую часть код.

Также у меня есть мои глобальные обработчики проверки, обработчики ошибок, обработчики аутентификации, которые я могу просто проверить из своего репозитория в каталог lib.

Я нашел эту структуру наиболее эффективной до наших дней.

Другой подход

Вы можете также использовать YEOMAN, что делает много для структуры для вас. Однако он добавляет множество зависимостей, и когда я пытался использовать его, я капал по некоторым проблемам с конфликтами зависимостей во время установки. Мое личное эмпирическое правило состоит в том, что если я не могу заставить что-то работать в течение 1 дня, я оставляю свои руки подальше от него, так как я потеряю время, затрачиваемое на код. Другое эмпирическое правило, которое я задал себе, заключается в том, что если есть структура с зависимостями, зашитыми вместе, которые разрабатываются людьми с разными целями, я стараюсь избегать ее, если это возможно. Обратите внимание, что это личные правила, которые я задал себе и, возможно, не буду правильной стратегией для других лиц. Из-за этих причин я решил не использовать его. Но, похоже, уже довольно большое сообщество.

Производство

Для производственных целей можно затем использовать UglyfyJS или Google Closure Compiler, чтобы создать один сжатый файл JS со всей кодой или каждый файл сжатого seperatly.

Надеюсь, это описание будет полезно для вас.

Answer 3

На мой взгляд, лучший способ структурирования больших AngularJS приложение на это, чтобы сделать это по признаку, предложенный Питером Бэконом Дарвина и Павла Козловского в своей книге «Mastering развития веб-приложений с AngularJS».

Вместо структуры, рекомендованного AngularJS проекта семян (и многие другие, как старшина-х генератор угловой), что является «технически управляемой» означает, что каждый тип элемента, как контроллеры, частичными/просмотров и т.д. приземляется в своей папке , вы должны использовать «домен-ориентированный», который отражает бизнес-домены в вашем коде.

Она имеет много преимуществ, как:

• делает владение кода явного и ясного,
• вводит вездесущий язык, который является общим для всех модулей,
• уполномочивает (в некоторой степени) прямая связь с бизнес-аналитиками,
• устраняет потенциальные конфликты из-за более низкой потребности в слиянии и т. д.

Вот пример (просто пояснить идею) структуры, как предложено в книге, упомянутой выше:

каталогов верхнего уровня в проекте:

- src: contains application source code 
- test: contains accompanying automated tests 
- vendor: contains third party dependencies 
- build: contains build scripts 
- dist: contains build results, ready to be deployed in a target environment 

Внутри ЦСИ папка (фиксированная):

- app: AngularJS-specific code, domain-driven 
- common: AngularJS-specific code, boiler-plate 
- assets: holds images and icons, 
- less: LESS variables 
- index.html - entry point to the application 

Внутри приложения папка (с доменом), например. Веб-магазин:

- shop 
    - products 
    - customers 
    - orders 
    - orderlists 
    - orderdetails 
    - ... etc. 
- admin 
    - users 
    - ... etc. 

Каждая папка содержит все соответствующие символы, включая обертоны, скрипты и т.д.