Чем является директива в концепции mv* в AngularJS?
Вот как мыслю я. Angular является, как это заявлено, mv*. Значит если я использую контроллер, модель и ng-bind, то я использую mvc. Если же я использую ng-model которая предоставляет двухсторонние связывание (которое по правильному вроде и называется data binding, по крайней мере в flex и не опнятно почему авторы angular исказили в обратную сторону), то я автоматически реализую mvvm.
И вот так получается, что в первом случаи я жесточайше нарушаю концепцию mvc решая за модель в директиве что её делать. А во втором случаи не понятно с какого боку взялся контроллер, да и почему до сих пор vm стоит выше чем модель.
Это как испытывая голод рот будет принимать решение за мозг сожрать арбуз целиком.
Так чем же является директива?
директива - кусок встраиваемого независимо работающего компонента (приложения).
который вы можете вставлять в ХТМЛ как обычный тег (по концепции с веб компонентами).
тоесть если говорить в рамках MVC - то это ещё один mvc.
да и вобще не парьтесь по поводу концепции, их разрабатывают чтоб упростить жизнь, в некоторых приложениях удобно объединить контроллер с внешним видом, иногда удобно объединить контроллер и модель. Главное - не пытаться всё подгонять под какие-то догмы.
Не могу согласится, так как любое отклонение возвращает нас во времена из-за которых и придумали эти концепции. А тот факт что кнопка может управлять САМИМ ПРИЛОЖЕНИЕМ просто взрывает весь разума, пусть даже она написана САМИМ ГУГЛОМ.
vasIvas: этот паттерн появился за долго до появления веба. и нет ничего страшного чтоб его модифицировать под свои нужды.
кнопка в ангуляре в качестве директивы может работать, как отдельное самостоятельное приложение, ничего в этом страшного.
концепция двойного связывания реально очень удобная -> нет необходимости создавать события, добавлять для них обработчики и тд.
работа с событиями становиться значительно проще и удобнее. для фронтэнда это очень элегантный и удобный подход.
ангуляр больше похож на HMVC, в таком случае директива это самодостаточное MV* приложение или его компонент, и да у него могут быть свои зависимости и т.д.
Однажды, в самом начале своего пути, я заразился одержимостью архитектуры.
Я многого не знал в своем первом языке, но в разговорах о архитектуре часто был на равных со старожилами.
Но когда я начал изучать вэб, то столкнулся с непониманием вэб архитекторов и их фразами о "незагоняйся, архитектура ерунда". От всего этого у меня в голове образовалось месиво и я решил разобраться. нашел самые истоки, первые презентационные доклады, которые подтверждали мою правоту. Но что меня по настоящему удиви, это то как люди искажают данные. Найдя английскую версию я поле в интернет гуглить что-то подобное на русском и все статьи которые мне попадались были следующие. Авторы рассказывая "неправильную версию" подтверждали её первоначальной статьей.
Это я к чему, а к тому что я почитал о hmvc и это вообще какое-то безумие. Это же ЕСТЕСТВЕННО что каждый компонент приложения это своя триада. А задумка что каждая триада общается через свой контроллер вообще *нутая. За каким фигом для каждой кнопки плодить контроллер? Ведь правильно будет создать только один контроллер и все компоненты должны с ним общаться при помощи медиатора.
А если должны общаться представления с представлениями, а модели с моделями, то они это делают через свои main. И когда у каждого из триады есть свой main, то это не какой-то отдельный *mvc, это и есть обычный и правильный mvc. Просто автор скорее всего не думал что существуют такие программисты, которым алгоритм поедания яблок нужно описывать так -
> положи в рот яблоко и съешь.
>> а если у меня два яблока, тогда как?
> положи в рот яблоко и съешь, положи в рот яблоко и съешь
>> а если у меня три яблока, тогда как?
>> *дец.
vasIvas: какая задумка? О чем вы? К чему пример с яблоками?
Имхо вы слишком много загоняетесь по довольно обычным вещам. MVC/HMVC/etc это еще не архитектура. Архитектура это SOLID, GRASP, слоеная архитектура... А знать имена шаблонов и т.д. это еще не разбираться в архитектурных штуках.
Стоимость грамотной архитектуры - избыточность. В реально жизни обычно идут на уступки и устраняют излишнюю избыточность. Вот и все.
vasIvas: но все же раскроете свою мысль менее сумбурно, особенно часть про общение через контроллер (и что тут странного, везде так реалиовано, а контроллер и есть медиатор)
Сергей Протько: здесь я написал с полсотни строк, но понял что по смыслу они все разрознены, что вызвано недостатком знаний. По этому я все стер, но обязательно продолжу, когда соберу нужную информацию.
vasIvas: мне на самом деле очень будет любопытно почитать. Пока же я не понимаю одного - вы говорите что взаимодействие через контроллеры это тип не ок и что должны быть медиаторы, хотя контроллер это как раз таки медиатор между view и model.
Сергей Протько: нет. Я говорю, что общение контроллеров, это вполне естественно. И я пытаюсь обратить внимание на то, как отклонение от естественности приводит к смешным формулировкам, чем является Hmvc. Человек описывает обычное mvc, но называет его Hmvc.
Ещё близкий пример, на мой взгляд, это mvvm. Просто так вышло, что браузерный язык разделен на три части html+css+js и его воспринимают, как три разности, относя html к представлению, а js к модели.
Например во флеш один язык во всем клиенте и по этому на клиенте реализуется "изящная-каноническая" mvc архитектура со своей моделью и представлением.
Но в вэбе из-за того что js это модель, получилось смешивание логики представления с логикой приложения-моделью. Если сейчас задать вопрос о том, что такое js, то почти все ответят, что это модель клиента. И именно по этому теряется смысл настоящей клиентской модели.
Это двумя словами если.. Хотя ещё стоит добавить, что по этой причине на клиенте отсутствует правильная модель и на её замену пришел валуеобжект, который был навеян серверистами, что даже в вики осуждается за толстый контроллер. И именно по этому и был придуман двухсторонний биндинг, который по своей философии не нарушает никаких концепций. Но если вспомнить что сама концепция биндинга образовалась на неправильной концепции толстого контроллера и ко всему этому ещё добавить Hmvc, то получается веселая история.
vasIvas: на счет вэба не согласен, html это чисто шаблоны, view layer это не только html + css.
хз, можно сколько угодно разглагольствовать по плюсах минусах и прочим, а можно просто писать код. Я пожалуй займусь вторым. Буду продолжать искать баланс в толстоте контроллеров.
Сергей Протько: я с Вами тоже согласен, но частично. Пока я думаю о обычном сайте на angular, то у меня все получается, но есть один нюанс. Представьте что Вам покажут работу на angular с логикой в модели, что Вы подумаете?
Но самая большая головная боль начнется тогда, когда я начну писать очень сложное приложение, в котором одной просто вью и просто модели не будет достаточно.
Если представить что в приложении будет находится 3d движок и само приложение будет иметь очень сложную логику, о из-за того, что все это сложное отправится в модель-js, хотя 3d и физические движки, это самое что не на есть представление, начнется настоящая головная боль. А сложная модель приложения в angular не предусмотрена, так как все хваленое mvc является не архитектурным, а компонентным.
То есть angular похож на компонентный фраймворк, а не на архитектурный, какие например есть в том же flash. И хочу подчеркнуть, что пусть все ненавидят flash, но он является тем, к чему вэб идти ещё несколько десятилетий.
Хотя более вероятно, что с приходом вэбасамблера js-html-css уйдут в небытия, так как любой продвинутый язык сможет написать свой один единственный вэб язык.
vasIvas: angular (особенно вторая его версия) и есть компонентный фреймворк, и это круто. Это то что мне в нем нравится.
Что до чувака который пишет логику в модели - если при этом сохраняются принципы единой ответственности, если все согласно шаблону "информационный эксперт" и все такое то не вижу в этом ничего плохого. Вы зациклились на MVC, просто забейте. Жить станет намного проще. Есть куда более важные вещи о которых надо париться.
Сергей Протько: на днях прочел статью на хабре о "моделях и логике" и теперь немного в замешательстве, так как не понимаю модель из mvc это не модель предметной области?
vasIvas: и да и нет. Модель предметной области это частный случай скорее. В MVC (олдскульном) модель (фр. modèle, от лат. modulus — «мера, аналог, образец») это просто какое-то состояние ваших данных, вы можете совершать над моделью действия и в ответ она будет менять свое состояние.
vasIvas: я это к тому что MVC не регламентирует что у вас там и как за контроллером, оно регламентирует как должен происходить процесс интерактивного взаимодействия пользователя (через слой представления) и модели через промежуточный медиатор - контроллер.
А ссылку на статью все ж дайте, любопытно что вас там смутило, может сам начну сомневаться)
Сергей Протько: habrahabr.ru/post/263025 статья очень интересная. А смутило меня то, что однажды у меня состоялся разговор начатый со слов о mvc, но потом мой оппонент переключился на слова, которые меня подтолкнули к мысли, что я не понимаю значения модели. Ну или он чересчур хотел сумничать, упрекнув меня что я не знаю что такое модель предметной области. И вот вчера я увидев статью на хабре и прочтя её, усомнился в понимании значения модели. Я тоже всегда думал что в mvc, модель это само приложение, данные + поведение.. Но кто его знает..
vasIvas: статья интересная, но опять же, причем тут MVC? MVC регламентирует как следует строить взаимодействие между приложением и интерфейсом, и не более. То есть модель в контексте MVC это ооочень обобщенное понятие. Вся идея MVC заключается во введении медиатора между двумя слоями дабы устранить зависимость одного от другого.
Средний
