Угловой шаблон MVC шаблона?

Ответ 1

Совсем не странный вопрос - я пытался продать Angular многим разработчикам java, и они спрашивают об этом. Я сам спросил его, когда учился (я все еще учился, кстати)

Если вы возьмете "обычный" java webapp, как вы описали, и Angular -ize, вы должны сначала взять свой сервер и сделать его RESTful API. Удалите JSP и т.д. На самом деле это тяжелая часть, IMO, для записи приложения Angular - получение права REST API. Ключом к тому, чтобы решить, какую логику нужно было входить в сервер, было думать об этом как о чистом апи и забыть на тот момент, что у него будет передний конец.

Этот вопрос действительно помог мне - если кто-то попытается сохранить данный ресурс, и у этого ресурса нет достоверных данных, нет переднего конца, чтобы рассказать им, - они нажимают на API напрямую, поэтому API должен отклонить его. Таким образом, задняя часть отвечает за глубокую проверку. Это относится и к вашей бизнес-логике. Предположим, что кто-то использует только API, и станет ясно, что должен делать ваш сервер.

Серверу также необходимо предоставлять данные в (возможно) формате json (я использую Spring MVC + Jackson), поэтому он отвечает за публикацию модели до Angular и связь с базой данных.

Итак, что такое MVC на стороне Angular?

• Модель. Данные, поступающие от REST API. Если API поддерживает JSON, эти объекты уже будут объектами javascript первого класса.
• Просмотр: HTML и директивы, когда вам нужно манипулировать DOM
• Контроллер: (и настраиваемые сервисы, которые вы внесли из своих контроллеров..)
  • Запросит API REST и поместит все необходимое для представления в области $scope
  • Предоставляет обратные вызовы для директив для ответа на события, которые затем могут потребовать обращения к серверу.
  • Проверка: обычно с помощью обратного вызова к директиве. Скорее всего, перекрыт некоторые из проверок, которые вы уже установили на сервере, но вы не хотите, чтобы ваш пользователь дождался, когда сервер проверит все - клиент должен что-то знать о проверке, чтобы дать пользователю немедленную обратную связь.
  • Бизнес-логика: Практически такая же история, как и проверка.

Но почему дублирование логики в клиенте и на сервере? В основном потому, что вы не пишете одно приложение, вы пишете две независимые вещи:

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

Итак, короткий ответ - получите API REST, забыв, что будет пользовательский интерфейс, и что будет в Angular будет намного понятнее.

Ответ 2

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

Итак, в Angular деление (как правило):

• Контроллер (контроллер): для управления данными (областью действия) за вашим пользовательским интерфейсом.
• Директивы: для настройки DOM для связи с контроллером через область действия и для управления DOM.
• Шаблоны (просмотр): назначение директив элементам DOM.
• Область (модель или модель просмотра): для переноса данных между всеми частями системы.
• Услуги. Инъекционные, многоразовые биты кода. Обычно для зависимостей, таких как обработка Ajax, файлов cookie или других операций ввода-вывода.

Это действительно почти MVVM, а не MVC.

Что касается вашей "бизнес-логики" или правил... все, что требует безопасности, всегда должно быть обеспечено на уровне сервера.

Ответ 3

Важно понимать, что в некоторых версиях шаблона MVC данные, а также логика, которая управляет данными, находятся в "модельном" слое (с уровнем "контроллера", ничего не делая, кроме связывания). Однако в AngularJS только данные ($ scope) находятся в "модельном" слое, а логика, которая управляет данными ($ scope), находится на уровне "контроллера".

Ответ 4

Мне нравится то, что говорит @Roy TrueLove. Но позвольте мне сказать, что это конечный способ использования угловых. Конечно, вам нужно научиться делать ваши приложения таким образом, если вы хотите получить максимальную выгоду от angular. Я молюсь, чтобы я был там однажды.

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

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

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

Ответ 5

Я согласен с ответами здесь. Еще несколько комментариев. Когда вы пишете выражение, сначала нужно сосредоточиться на проблемной области. И создать программную модель какого-то реального бизнеса. Например, если ваш проблемный домен является покупкой, некоторые требования, которые вам нужны для модели, могут включать в себя:

• Кредитная карта должна быть действительной.
• Если вы платите кредитной картой марки X, вы получите 10% скидки.
• В корзине магазина должно быть указано хотя бы один элемент для выполнения проверки.
• Элементы должны иметь запас, чтобы пользователи могли добавлять их в корзину покупок.

Реализация этих требований будет моделировать ваш проблемный домен, это ваша бизнес-логика.

Angular - это интерфейсная структура и инструментарий. Это веб-интерфейс. Если вы реализуете это в веб-интерфейсе, вы пропустите возможность повторного использования вашей модели из другого интерфейса или интерфейса, например мобильного или настольного приложения. Таким образом, в идеале, ваша реализация бизнес-логики должна быть отделена от любой платформы пользовательского интерфейса и отделена от любой постоянной структуры. Затем у вас будут объекты интерфейса, которые будут касаться проблем пользовательского интерфейса и будут взаимодействовать с объектами бизнес-логики. Это может быть контроллер Spring MVC и/или контроллер или служба Angular.

Существует пример приложения, на котором вы можете взглянуть, следуя принципам, упомянутым здесь.

Ответ 6

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

Я разрабатываю web-приложения с использованием Spring/JBoss-шва/JSF и на основе MVC. В большинстве случаев java-скрипты будут находиться для проверки уровня представления, а основные классы/сущности действия и бизнес-логика будут находиться в Java-коде. После некоторых основных практических действий на Angular я начал получать то, что они имели в виду под MVC, поскольку они абстрагировали другой уровень на уровне презентации, где у нас могут быть свои собственные представления и контроллеры на передней панели. Чтобы ответить на ваш вопрос, точно так же, как и все комментарии, лучший способ - разместить его на уровне презентации.

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

Здесь моя мысль для фреймворка вроде Angular похожа на клиента с небольшим магазином /SOHO, и у них есть несколько человек, и они действительно эффективны и быстры. Они хорошо подходят для клиентов, сталкивающихся с бизнесом и доставки/получения товаров эффективно (REST, JSON). У них есть определенные роли и задачи, но некоторые работники выполняют больше заданий. Магазин также уязвим для воров или разбойников, поскольку обычно они не подчеркивают серьезную безопасность.

Что касается структуры на стороне сервера, такой как Spring/Struts 2, представьте себе современную корпорацию (уровень 5 CMM) с разным уровнем управления и способную обрабатывать более крупный бизнес (пакетные задания, веб-службы, корпоративная шина). Они обрабатывают клиентов, но не напрямую, часто проходят через брокеров или даже в розничные магазины. Безопасность разумна, корпорация более надежна, и часто ценные бумаги на входной двери или важная информация защищены в безопасном режиме (шифрование/регистрация).

Ответ 7

Мой подход всегда является подходом снизу вверх. Начиная с создания базы данных, с правильно построенными/связанными таблицами, хранимыми процедурами, когда это необходимо, затем добавьте Entity Framework в решение или используйте ADO.Net, если EF не является опцией. Затем создайте Business Logic и Модели, чтобы получить данные в базе данных и из нее.

С установленными моделями теперь мы можем идти по двум направлениям: разработка MVC-контроллера и/или разработка WebAPI-контроллера. Оба контроллера могут иметь доступ к моделям, это просто вопрос создания экземпляров классов и вызова методов.

Теперь у вас есть возможность настроить MVC Views, которые контролируются контроллером MVC, или полностью отдельный набор HTML-страниц или SPA (одностраничное приложение, размещенное на NodeJS).

С полностью отдельным набором HTML-страницы вам нужно будет использовать контроллеры WebAPI с методами Get, Post, Put и Delete и не забудьте включить маркер взад и вперед, чтобы идентифицировать своего клиента, и включить CORS (для Cross Origin Request)

С помощью MVC-представлений вы можете идентифицировать своих клиентов, используя атрибуты контроллера и/или сеансы, и не нужно беспокоиться о CORS, и даже при необходимости можете сделать свои представления сильно-типизированными. К сожалению, если у вас есть набор разработчиков пользовательского интерфейса, они должны будут работать с одним и тем же решением MVC.

В обоих случаях вы можете использовать AngularJS для переноса данных из/в контроллеры.

IMHO концепция контроллера AngularJS не совпадает с контроллером С# MVC или С# WebAPI. Контроллер AngularJS содержит всю логику javascript, а также вызовы конечных точек через "ApiFactory", тогда как контроллеры С# - это не что иное, как конечные точки на стороне сервера, которые принимают и отвечают на запросы пользовательского интерфейса.