AngularJS 客户端 MVC 模式? ？

小开

最佳答案

一点也不奇怪——我一直试图把 Angular 卖给很多 Java 开发者，他们问了这个问题。我在学习的时候也问过自己(顺便说一下，我还在学习)

如果你使用一个你所描述的“传统”的 java web 应用程序并将其角度化，你首先需要使用你的服务器并使它成为一个 RESTful API。删除 JSP 等。这实际上是编写一个有角度的应用程序的最困难的部分——正确地使用 REST API。决定进入服务器需要什么逻辑的关键是 认为它是一个纯粹的 api，而且暂时忘记了它将有一个前端。

这个问题真的帮助了我——如果有人试图保存一个给定的资源，而这个资源没有有效的数据，没有前端告诉他们——他们直接命中 API，因此 API 需要拒绝它。因此，后端负责进行深度验证。这也适用于您的业务逻辑。假设有人正在使用只是的 API，那么您的服务器需要做什么就会变得很清楚。

服务器还需要(可能)以 json 格式(我使用 Spring MVC + Jackson)出售数据，因此它负责将模型公开给 Angular，并与数据库进行通信。

那么角度方向的 MVC 是多少？

Model : 来自 REST API 的数据。如果 API 出售 JSON，那么这些对象将已经是第一类 javascript 对象。
当需要操作 DOM 时，查看 : HTML 和指令
Controller : (以及已经从控制器中分解出来的自定义服务. .)
- 查询 REST API 并将视图所需的内容放在 $scope 上
- 提供指令的回调，以响应随后可能需要回调服务器的事件。
- 验证: 通常通过对指令的回调。但是您不希望用户等待服务器验证所有内容——客户机应该知道 什么东西关于验证的信息，以便给用户即时的反馈。
- 业务逻辑: 与验证几乎相同。

但是为什么在客户端和服务器端会出现逻辑重复呢？主要是因为你不是在写一个应用程序，而是在写两个独立的东西:

一个 RESTAPI，它需要是健壮的和可用的，没有前端
需要向用户提供即时反馈而不必等待服务器的 GUI。

所以，简短的回答是——正确使用 REST API，忘记将会有一个用户界面，进入 Angular 的内容将会更加清晰。

小开

我认为“业务逻辑”这个词在这里有点用词不当。客户端应用程序的“业务”是处理用户界面的业务。它不会像安全规则、专有逻辑或其他敏感的知识产权那样。

因此，在 Angular 中，除法(一般)是:

Controller (Controller) : 用于操作 UI 背后的数据(范围)。
指令 : 用于设置 DOM 以通过作用域与控制器通信，用于操作 DOM 的还有。
模板 (视图) : 为 DOM 的元素分配指令。
作用域 (模型或视图模型) : 用于在系统的所有部分之间传输数据。
服务 : 可注入的、可重用的代码，通常用于处理 Ajax、 cookie 或其他 I/O 等依赖项。

它几乎是 MVVM 而不是 MVC。

至于您的“业务”逻辑或规则... ... 任何需要安全性的东西都必须始终在服务器级别得到保护。

小开

我喜欢@Roy TrueLove 说的话。但我要说的是，这是使用 angularjs 的最终方式。当然，如果您想要获得角度的最大好处，就必须学会以这种方式来处理应用程序。我祈祷有一天能在那里。

与此同时，在你的学习过程中，在你完全使用 angularjs 作为你的客户端做事情的主要方式的过渡期间，你可以开始使用它来完成一些小任务，并逐渐习惯它和它的思维方式。

我鼓励人们逐渐接受它，慢慢来，但是我保证，我肯定。

Angularjs 就是为这种方法而设计的，因为它可以完成最小的任务，也可以完成最大的任务。例如，我第一次使用 angle 只是为了在用户键入 id 时显示名称。

小开

我同意这里的答案。更多评论。在编写应用程序时，首先需要将注意力集中在问题域上。然后创建一个实际业务的软件模型。例如，如果您的问题域是一个购物，您需要建模的一些需求可能包括:

信用卡应该是有效的。
如果您使用 X 品牌的信用卡付款，您将获得10% 的折扣。
购物车应该至少包含一个项目来执行结帐
在允许用户将商品添加到购物车之前，这些商品必须有库存

这些需求的实现将为您的问题域建模，这就是您的业务逻辑。

角度是一个前端框架和工具包。这是一个网的前端。如果你在网络前端实现这一点，你将错过从其他前端或界面(如移动或桌面应用程序)重用模型的机会。因此，在理想情况下，您的业务逻辑实现需要与任何用户界面框架解耦，并且也需要与任何持久化框架解耦。然后，您将拥有处理用户界面问题并与业务逻辑对象进行通信的接口对象。这可以是一个 Spring MVC 控制器，和/或一个角控制器或服务。

有一个样本申请书你可以看看，它遵循这里提到的原则。

小开

我似乎也有这个问题，因为一些组织只是热衷于新技术——“我想要云... ... 等等，我想要轻量级”，这很难证明它是否值得切换到一个更轻量级的框架。

我一直使用 Spring/JBoss seam/JSF 和 MVC 框架开发 Web 应用程序。大多数时候，Java 脚本将驻留在表示层验证中，而主要的操作类/实体和业务逻辑将驻留在 Java 代码中。在对 Angular 进行了一些基本的实践之后，我开始明白他们所说的 MVC 是什么意思，因为他们在表示层上抽象出了另一个层次，在这个层次上，我们可以在前端拥有自己的视图和控制器。为了回答你的问题，就像每个人的评论一样，最好的方法是把它放在展示层。

至于安全性的观点，我认为繁琐或敏感的业务规则应该驻留在服务器端，因为我们不希望将其公开给全世界。如果业务逻辑开发得不好，就可以很容易地找到代码中的弱点并加以利用。

这里是我的想法框架像 Angular 就像一个小商店/SOHO 处理客户，他们有一些人，真正有效率和快速。它们很好地迎合了面临业务和高效交付/接收货物(REST，JSON)的客户。它们确实有指定的角色和任务，但是有些工作人员执行的任务不止一项。这家商店也很容易被小偷或强盗抢劫，因为他们通常不强调严密的安全措施。

对于 Spring/Struts 2这样的服务器端框架，设想一个具有不同管理水平并能够处理更大业务(批量作业、 Web 服务、企业总线)的现代企业(CMM Level 5)。他们确实处理客户，但不直接，经常通过经纪人，甚至零售商店。在安全方面，公司更加强大，通常前门有安全措施，或者重要信息被保护在保险箱里(加密/登录)。

小开

理解这一点很重要，在 MVC 模式的某些版本中，资料和操纵逻辑中的数据都驻留在“模型”层(“控制器”层除了绑定什么也不做)。然而，在 AngularJS 中，数据($scope)单独位于“模型”层，而操作数据($scope)的逻辑位于“控制器”层。

AngularJS "MVC"

小开

我的方法总是自下而上的方法。从数据库设计开始，使用适当构造/相关的表，在需要时使用存储过程，然后将实体框架添加到解决方案中，或者如果 EF 不是一个选项，则使用 ADO.Net。然后开发业务逻辑和模型来获取数据库中的数据。

随着模型的建立，我们现在可以走两条路线: 开发 MVC 控制器和/或开发 WebAPI 控制器。两个控制器都可以访问 Model，只需要实例化类和调用方法即可。

你现在可以选择设置由 MVC 控制器控制的 MVC 视图，或者设置完全独立的 HTML 页面或 SPA (托管在 NodeJS 上的单页应用)。

使用完全独立的 HTML 页面集，您将需要使用 WebAPI 控制器，以及 Get、 Post、 Put 和 Delete 方法，并确保来回包含令牌以标识您的客户端，并启用 CORS (用于 Cross Origin Request)

使用 MVC 视图，您可以使用控制器属性和/或会话来识别您的客户机，不必担心 CORS，如果需要，您甚至可以使视图强类型化。不幸的是，如果您有一组 UI 开发人员，他们将不得不使用相同的 MVC 解决方案。

在这两种情况下，您都可以使用 AngularJS 在控制器之间来回传输数据。

恕我直言，AngularJS 控制器的概念与 C # MVC 或 C # WebAPI 控制器不同。AngularJS 控制器包含所有的 javascript 逻辑以及通过“ ApiFactory”对端点的调用，而 C # 控制器只是服务器端接受和响应 UI 请求的端点。