Какой подход к разработке на AngularJs лучше?

Question

[igsavenko]

Добрый день,
Всегда хотел изучить AngularJs и все оказалось не так просто как я думал. Очень крутая мощная библиотека столько документации по ней и сразу сложно въехать во всё. Пока писал вопрос Toster подсказки мне выдавал, нашел хорошие советы и best practise. Но пока не нашел ответа на свой вопрос.

Я очень хорошо знаком с Laravel (уже не один проект с его помощью написал) а тут я решил написать небольшой проект и заодно изучить angular.js.
Наткнулся на первую же статью в интернет по запросу Laraver + AngularJs. вот ссылка.

Если Вам не сложно посмотрите, пожалуйста, на его подход к организации Контроллера и Сервиса мне очень понравилась такая архитектура. Вся логика описана в одном контроллере (получение списка, создание, удаление и т.д.), а доступ к данным в Сервисе.

А вот на официальном сайте angularjs.org нашел пример - Wire up a Backend (прям на главной странице), то что я примерно и хотел сделать (только другие данные) и тут мне не понятно, совсем другой подход к организации. Не понятно зачем создавать новый контроллер на каждое действие: ProjectListController, NewProjectController, EditProjectController... а потом привязывать это маршруту.

В голове не укладывается просто, первый подход мне нравится больше, но я пока не знаю как развить его для решения моей задачи, а второй противоречивые мысли вызывает. Может кто-нибудь пояснит? Огромное спасибо, заранее.

Comments

[copal]

Вы можете делать так как Вам хочется. Если хотите освоить клиентскую архитектуру, то сразу забывайте о толстом контроллере. А дальше все как везде, это уже дело вкуса - архитектурного подхода. Ну и ещё могу посоветовать рассматривать сервисный слой, как часть того с чем его используют. То есть если у Вас есть объект данных для логики приложения и есть сервис, который эти данные изменяет, то не расценивайте данные и сервис, как две отдельные части, это одна модель приложения.
То есть Вы должны понять, что из-за особенного вида клиентских разработчиков, angular искажает понятия модели приложения и данных для отображения. В angular ассеты называются моделью o_O. То есть ребенок захотел поиграть во взрослого, одил контрацептив, а он фак его, слетает. Это равносильно тому, как вэб разработчики, захотев напялить mvc сделали ассеты-данные для отображения - моделью.

[copal]

И ещё.. Я не хочу никого оскорбить, но такое жесткое сравнение я сказал для того, чтобы истина въелась в самую кору. На самом деле, для того вэба, коем его считает половина, применима именно серверная реализация, а именно mvp (это тоже mvc, только с толстым контроллером).

MVP и создан был специально для компонентов. Но angular, как и все современные фраймворки, пропагандируют не компонентный подход в его обычном понимании, а компонентный кодход, в котором html и js сливается в одно слово view... Но как всегда, старики не способные адаптироваться назвали данные отображения - моделью.

Answer 1

[Владимир Т.]

Ангулар хорош на старте, но очень легко его стартовыми бонусами пальнуть себе в ногу и поиметь проблем в будущем. Гайды от John Papa хороши, но если у проекта есть потенциал для роста, то вот этот пост почитайте teropa.info/blog/2015/10/18/refactoring-angular-ap... Он о том, как кодовую базу написанную с горячечной радости от двойного биндинга превратить в поддерживаемую и расширяемую.

Comments

[igsavenko]

Спасибо, прочитаю обязательно.