到目前为止，我主要使用 Struts 2 ， Spring ， JQuery 技术堆栈来构建Web应用程序 . 关键是，提到的堆栈使用服务器端 MVC 模式 . Web浏览器的主要作用仅限于请求/响应周期（客户端验证） . 数据检索，业务逻辑，布线和验证主要是服务器端的职责 .
我对AngularJS框架的几个问题很少受到以下引用的启发：
对于Angular应用程序，我们鼓励使用模型 - 视图 - 控制器（MVC）设计模式来分离代码并分离关注点 .
来自Wikipedia Model–view–controller：
模型 - 视图 - 控制器（MVC）是一种将信息表示与用户与之交互分离的体系结构 . 该模型由应用程序数据和业务规则组成，控制器调解输入，将其转换为模型或视图的命令
AngularJS使用客户端 MVC 模式 . 所以我想没有其他选择那么以某种方式也将验证逻辑包含在客户端？
What would be the best way to write a robust AngularJS application? MVC on client side and some kind of MC (model, controller) on server side?
这是否意味着，MODEL和CONTROLLER在某种程度上是重复的（客户端/服务器）？
我知道我的问题有些奇怪，但我认为原因是，我在某种程度上习惯了传统的服务器端MVC模式 . 我确信有人已经完成了相同的过渡 .
7 回答
我似乎也有这个问题，因为有些组织只是热衷于新技术 - “我想要 Cloud ......等等，我想要轻量级”，很难证明它是否值得转换到更轻松的框架 .
我一直使用Spring / JBoss seam / JSF和MVC框架开发Web应用程序 . 大多数情况下，java脚本将驻留在表示层验证中，主要操作类/实体和业务逻辑将驻留在Java代码中 . 在对Angular进行了一些基本的实践之后，我开始了解它们对MVC的意义，因为它们在表示层上抽象了另一个层次，我们可以在前端拥有自己的视图和控制器 . 要回答您的问题，就像每个人的评论一样，最好的方法是将其放在表示层上 .
至于安全性的观点，我认为繁重或敏感的业务规则应该驻留在服务器端，因为我们不希望将它暴露给全世界 . 如果业务逻辑开发得很差，人们很容易发现代码的弱点并利用它 .
这是我对Angular这样的框架的想法，就像一个小商店/ SOHO处理客户，他们有一些人，真正高效和快速 . 他们很好地迎合面对业务和交付/接收货物的客户（REST，JSON） . 他们确实有指定的角色和任务，但有些工作人员执行的不仅仅是任务 . 这家商店也容易受到小偷或劫匪的攻击，因为他们通常不会强调安全性 .
对于像Spring / Struts 2这样的服务器端框架，想象一下具有不同管理级别并能够处理更大业务（批处理作业，Web服务，企业总线）的现代公司（CMM Level 5） . 他们确实处理客户，但不直接，经常通过经纪人甚至零售商店 . 安全方面，公司更加强大，通常是前门上的证券，或者重要信息在安全（加密/登录）中受到保护 .
我认为“商业逻辑”一词在这里有点用词不当 . 客户端应用程序的“业务”是处理用户界面的业务 . 它不会像安全规则和专有逻辑或其他敏感知识产权那样 .
所以在Angular中，这个部门（通常）是：
Controller （控制器）：用于操作UI后面的数据（范围） .
Directives ：用于设置DOM以通过作用域与控制器通信，以及用于操作DOM .
Templates （视图）：将指令分配给DOM的元素 .
Scope （model或viewmodel）：用于在系统的所有部分之间传送数据 .
Services ：可注入，可重复使用的代码 . 通常用于处理Ajax，cookie或其他I / O的依赖项 .
它几乎是MVVM而不是MVC .
至于你的“业务”逻辑或规则......任何需要安全性的东西都必须始终在服务器级别得到保护 .
我喜欢@Roy TrueLove所说的 . 但我要说这是使用angularjs的最终方式 . 当然，如果你想获得角度的最大好处，你必须学会以这种方式做你的应用程序 . 我祈祷有一天能在那里 .
同时，在你学习期间，以及在你完全使用angularjs作为客户端主要做事方式的过渡期间，你可以开始在这里和那里使用它来完成一些小任务，并逐渐习惯它和它的方式思维 .
我鼓励逐渐拥抱它并慢慢地走，但当然，我保证，当然 .
Angularjs旨在服务于这种方法，因为它可以在最小的任务上工作，就像它可以做最大的任务一样好 . 例如，我第一次使用angular只是为了在用户键入id时显示名称 .
根本不是一个奇怪的问题 - 我一直在尝试将Angular出售给很多Java开发人员，他们问这个问题 . 我在学习的时候自己问过（我还在学习，顺便说一句）
如果您使用'conventional' java webapp，那么_281163必须首先使用您的服务器并使其成为RESTful API . 删除JSP等 . 这实际上是IMO编写Angular应用程序的难点 - 让REST API正确 . 我决定进入服务器需要什么逻辑的关键是 thinking of it as a pure api and forgetting for the moment that it will have a front end .
这个问题确实帮助了我 - 如果有人试图保存一个给定的资源而且该资源没有告诉他们的前端 - 他们直接命中API，因此API需要拒绝它 . 因此，后端负责深度验证 . 这也适用于您的业务逻辑 . 假设有人正在使用API，您将清楚地知道您的服务器需要做什么 .
服务器还需要以（可能）json格式（我使用Spring MVC Jackson）来提供数据，因此它负责将模型公开给Angular，并与数据库进行通信 .
那么什么是MVC然后在Angular方面呢？
Model ：来自REST API的数据 . 如果API出售JSON，那么这些对象已经是第一类javascript对象 .
View ：HTML，以及需要操作DOM时的指令
Controller :(以及您从控制器中分解出来的自定义服务..）
查询REST API并在$ scope上放置View所需的内容
为指令提供回调，以响应可能需要回调到服务器的事件 .
验证：通常通过回调指令 . 可能会重叠您已经放入服务器的某些验证，但您不希望用户等待服务器验证所有内容 - 客户端应该知道有关验证的信息，以便为用户提供即时反馈 .
业务逻辑：与验证几乎相同的故事 .
但为什么在客户端和服务器中重复逻辑？主要是因为你没有写一个应用程序，你正在编写两个独立的东西：
一个REST API，需要健壮且无需前端即可使用
需要立即向用户提供反馈而不必等待服务器的GUI .
所以，简短的回答 - 通过忘记将有一个用户界面来获得REST API，进入Angular的内容将更加清晰 .
我的方法始终是自下而上的方法 . 从数据库设计开始，在需要时使用正确构造/相关的表，存储过程，然后将Entity Framework添加到解决方案中，或者如果EF不是选项，则使用ADO.Net . 然后开发业务逻辑和模型以将数据输入和输出数据库 .
Build 模型后，我们现在可以使用两条路径：开发MVC控制器和/或开发WebAPI控制器 . 两个控制器都可以访问模型，这只是实例化类和调用方法的问题 .
您现在可以选择设置由MVC控制器控制的MVC视图，或完全独立的HTML页面集或SPA（NodeJS上托管的单页面应用程序） .
使用完全独立的HTML页面集，您将需要使用WebAPI控制器，使用Get，Post，Put和Delete方法，并确保来回包含令牌以识别您的客户端，并启用CORS（用于跨源请求） ）
使用MVC视图，您可以使用控制器属性和/或会话来识别客户端，无需担心CORS，甚至可以根据需要使视图强烈输入 . 不幸的是，如果你有一组UI开发人员，他们将不得不使用相同的MVC解决方案 .
在这两种情况下，您都可以使用AngularJS在控制器之间来回传输数据 .
恕我直言，AngularJS控制器的概念与C＃MVC或C＃WebAPI控制器不同 . AngularJS控制器包含所有javascript逻辑以及通过“ApiFactory”对 endpoints 的调用，而C＃控制器只是服务器端的 endpoints ，它接受并响应UI请求 .
重要的是要理解在某些版本的MVC模式中，数据以及操纵数据的逻辑都驻留在"model"层中（"controller"层除了绑定之外什么也不做） . 但是，在AngularJS中，数据（$ scope）单独驻留在"model"层中，而操纵数据的逻辑（$ scope）驻留在"controller"层中 .
我同意这里的答案 . 还有一些评论 . 当您编写应用程序时，首先需要专注于问题域 . 并创建一些真实业务的软件模型 . 例如，如果您的问题域是购物，则需要一些要求您需要建模可能包括：
信用卡应有效 .
如果您使用品牌X的信用卡付款，您将获得10％的折扣 .
商店购物车应至少包含一个项目来执行结帐
在允许用户将商品添加到商店购物车之前，商品必须有库存
这些要求的实施将模拟您的问题域，这是您的业务逻辑 .
Angular是一个前端框架和工具包 . 这是一个网络前端 . 如果您在Web前端实现此功能，您将错过从其他前端或界面重用模型的机会，例如移动或桌面应用程序 . 因此，理想情况下，您的业务逻辑实现需要与任何用户界面框架分离，并与任何持久性框架分离 . 然后，您将拥有处理用户界面问题的接口对象，并将与您的业务逻辑对象进行通信 . 这可以是Spring MVC控制器，和/或Angular控制器或服务 .
有一个sample application你可以看看，遵循这里提到的原则 .