Как стать автором
Обновить

Комментарии 21

Неплохо сделано в ExtJS — docs.sencha.com/extjs/4.2.0/#!/guide/application_architecture
как показала практика, такой подход упрощает жизнь, прямо из коробки разработчик раскладывает всё по полочкам и потом придерживается установленного порядка.
Такой способ с его плюсами и минусами в статье описан.

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

статью не читай комментарий оставляй?

вы сделали такой вывод основываясь на чём? :)
ну просто вы показали ровно то что есть в статье :)

Вообще у меня был/есть опыт использования такого подхода (который по ссылке), и все же я соглашусь с выводом статьи что такая организация не совсем удобна когда нужно часть функциональности вырезать и вставить в другой проект. Если же этого не требуется, то такой подход весьма удобен и понятен, а главное прост в использовании.
ну просто вы показали ровно то что есть в статье :)


именно так, показал, что где-то есть люди, которые это уже обдумали и воплотили в жизнь
Там разбито по интерфейсным компонентам (по большому счету). Думаю, для Ангуляра хороший формат, т.к. он как раз заточен на директивы и интерфейс. По крайней мере завести папочку «UI», было бы не плохо :-)
Я вообще немного удивлён, что Ангуляр в шаблоне проекта свалил всё в кучу. Когда сами разработчики фреймворка не пытаются помочь с организацией проекта, это как-то странно…
Ну, они же пишут в документации, что это не эталон и чтобы разработчики организовывали исходя из своих потребностей. К сожалению (или к счастью) Ангуляр не настолько высокого уровня абстракции, чтобы решать за разработчиков, как им авторизацию делать, как модальное окно рисовать или как организовать товары… Поэтому они и не могут разбить иначе в шаблонном проекте
Действительно модульный подход весьма логичный и наглядный, нежели абстрактный MVC, пробую применять уже в некоторых проектах своих… Есть Components для Node.js, где вообще инкапсулируются css, html и js файлы в отдельные реюзабельные компоненты.
Спасибо за статью, благодаря ней я узнал два новых для меня решения («стопки на полу» и «ящик для носков» в терминах статьи).
как вы это все в итоге подключаете к проекту? используете amd?
Я потом собираю все в один файл, заодно и минимизирую. Можно делать это например с помощью grunt.js, но так как я использую .net, то мне проще использовать новую штуку от Microsoft, которая называется bundles.
grunt + concat (пример подсмотрел в грантфайле самого ангулара, безумно понравилось, использую на всех проектах). Туда же можно и через clusure compiller прогнать, и через imagemin и много чего еще.
Хороший подход, использую его, только с одной маленькой но удобной модификацией: имена файлов. Вместо

UserContract.js
UserController.js
UserModel.js
UserService.js
UserView.aspx
...

называем файлы по шаблону {Entity}.{concept}.{language}:

User.contract.js
User.controller.js
User.model.js
User.service.js
User.view.aspx


Что это даёт? Например, пожалуй самое для меня удобное: в VisualStudio я поставил плагин TabStudio, который позволяет группировать открытые табы по имени. В результате вместо 4-х открытых табов с длинными заголовками и необходимостью скроллить и искать в толпе других открытых табов

__| UserContract.js (x) || UserController.js (x) || UserModel.js (x) || UserService.js (x) || UserView.aspx (x) |____

получается лишь один скромный «групповой» таб с общим именем и 4-мя расширениями, типа такого

__| User .contract.js .controller.js .model.js .service.js .view.aspx (x) |____

что сильно экономит место и время.
Ага, давным давно смотрел вашу презентацию. Логичный подход к проектированию компонентов. Правда, дальнейшее углубление взорвало мозг и решил отложить)
А зачем «models/», их же как бы нет в angular там scope?
model более общее понятие. scope уже привязывается к модели или к ее части. Например, если выводить список с помощью ngRepeat, то помимо области видимости на весь список, создадутся дочерние на каждый элемент списка.… Но, вообще, понятия не имею, как они организуют код в этой папочке. Не json-файлы же там хранят)
model более общее понятие. scope уже привязывается к модели или к ее части. Например, если выводить список с помощью ngRepeat, то помимо области видимости на весь список, создадутся дочерние на каждый элемент списка.…


Ну это придется ручками делать, ведь scope создается один на контроллер, и он биндится к шаблону. Если нужны дочерние, то их придется создать вручную.
Неправильно сказал. Не область видимости привязывается к модели, а модель к области видимости. Точнее, scope это всего лишь ссылка на модель: habrahabr.ru/post/181882/. Область видимости, да, одна на контроллер, но может быть несколько на элементе, причем они так же будут вложенными, а не параллельными. На практике, создавать дочерние области приходится совсем не часто. Стандартные директивы и так их создают, когда нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории