为什么业务逻辑应该移出JSP？
在JSP之外保留业务逻辑的好处是什么，因为JSP主要是为了演示？ 我们仍然可以看到JSP内部编写的业务逻辑，所以我需要知道将业务逻辑从JSP中移出来会带来什么好处。
MVC的主要好处是你可以有多个视图和清洁和分离的架构和简单性
重用性
假设明天你需要在桌面应用程序上运行相同的应用程序。 那么你可以改变视图。
可测性
你可以unit testing你的服务方法，但你不能简单地从视图unit testing逻辑。
可维护性
很容易理解Service方法中的代码，我们也可以改变它/释放服务api并轻松维护
版本能力
如果您使用服务API而不是查看逻辑，则可以将版本提供给您的API并维护与问题/更新相关的标准文档
也可以看看
- 了解MVC
- 什么是MVC？
- 分离关注
这是“关注分离”devise原则的典型应用。
通过分离问题，即通过为每个问题创build单独的逻辑单元（主要是类），可以减less更改任何特定单元的原因数量。
SoC的另一个好处是降低这些单位的平均规模和复杂性。 这反过来使你的软件更容易理解和改变。
此外，使用小逻辑单元使得它们更容易进行unit testing，更容易在集成testing中进行模拟，并且在实施变更后更容易修复testing。
我将在这里发布的所有非常好的理由添加一个理由。
客户端技术一直在变化。 用户不想通过桌面，浏览器或移动应用程序来访问; 他们一直想要全部使用它们。 因此，如果将业务逻辑embedded到一种types的用户界面技术中，则可能必须将其复制到其他所有types的用户界面技术中。 这对于维护，可重用性以及增加新的业务逻辑都是不利的。
您不想因为您决定更改UI技术而不得不重新编写应用程序。
这对安全性也更好。 如果业务逻辑进入浏览器，用户有可能看到代码并找出你正在做的事情。
所以你最好把业务逻辑放在服务器端。
- 它变得可重用（对于其他应用程序和不同的视图（例如JSON API））
- 它把它从devise师手中带走（所以它不会妨碍他们，而且不会意外地打破它）
我不确定，但这可能是原因：
它的重用性的目的。
Jsp应该只用于演示目的，而我们的htmldevise者，后来devise页面的人不知道java编码会不舒服。 在servlet中编写所有buiseness逻辑可以让代码重用，而且在jsp页面中编写buiseness逻辑还有其他的一些方法，比如使用scriplets.so为什么做的工作利润less，额外的工作。
现在，如果我们使用jsp页面来处理业务逻辑，那么scriptlet将会在JSP页面内部更多，从而导致大量的维护成本。业务单元的servlet的单独声明将避免以上情况。
只是为了增加其他同行发布的好的理由，特别是关于“业务逻辑应该从JSP中移出”。
简而言之，我们有很多JSP，其中的业务逻辑已经全部结束了，看起来很杂乱。 有逻辑从会话/请求中获取对象并执行某些检查。 一个简单的例子是根据JSP中的特定条件构build不同的页面标题。
在我们的结尾如何移动这个逻辑就是引入一个Page Builder / Composer对象，该对象接受所有必要的细节来构造一个特定的页面并检查和设置页面bean对象中所有正确的字段。 然后，这个页面bean对象被设置为请求eg。这意味着，您将在JSP上拥有的所有以前的逻辑现在被移动到页面构build器/作曲者对象，然后最重要的是您可以编写unit testing到testing！ 如果在页面bean中设置了正确的值。
final SimplePageBuilder pageBuilder = new SimplePageBuilder(object1); request.setAttribute("TestBean", pageBuilder.buildPage()); buildPage方法将返回页面bean对象，在jsp中有一个简单的例子，getTitle只是简单地返回标题（因为逻辑被抽象而易于阅读）。
如果业务逻辑与表示逻辑分离，最好重用和维护Web应用程序。
假设我有3个JSP页面，每个页面都需要执行一些通用的业务逻辑。 如果我将业务逻辑放在JSP页面中，将会有代码的重复。
