logo标签列表

为什么业务逻辑应该从JSP中移出？

javajspdesign-patternsjakarta-eeservlets
18

将业务逻辑保持在JSP外部的优势是什么，因为 JSP 主要用于展示？我们仍然会看到业务逻辑写在 JSP 中，所以我想知道将业务逻辑从 JSP 移出可以获得什么好处。

1
相关：https://dev59.com/13A75IYBdhLWcg3wqK10 - BalusC
7个回答
14

MVC 的主要优点是你可以拥有多个视图和干净分离的结构以及 简洁易懂。

可重用性

假设明天你需要在桌面应用程序上运行相同的应用程序，那么你只需更改视图就可以了。

可测试性

您可以对服务方法进行单元测试，但不能仅仅从视图测试逻辑。

可维护性

很容易从服务方法中理解代码，我们可以轻松地更改/发布服务API并进行维护。

版本管理能力

如果使用服务API而不是视图来处理逻辑，则可以为API提供版本，并维护与问题/更新相关的标准文档。

参见

9
这是关注点分离设计原则的典型应用。

通过分离关注点，即为每个关注点创建单独的逻辑单元（主要是类），可以减少更改任何特定单元的原因数量。

另一个SoC的好处是减少这些单元的平均大小和复杂性。这反过来使您的软件更易于理解和更改。

此外，拥有小的逻辑单元使它们更容易进行单元测试，在集成测试中更易于模拟，并在实现变更后更易于修复测试。
@Codemwnci，您介意我将您的评论并入答案中吗？ - kostja
理论上，您可以将演示层替换为其他内容。或通过 Web 服务公开功能。 - Joeri Hendrickx
请不要直接回答问题，而是在评论区留言。如果有好的回答，请点赞支持。 - Codemwnci
3
我会在这里添加一个很好的理由。
客户端技术一直在变化。用户不想通过桌面、浏览器或移动应用程序访问，他们希望随时使用所有这些方式。因此，如果您将业务逻辑嵌入到一种类型的用户界面技术中，您可能需要在所有其他技术中复制它。这对于维护、可重用性和添加新的业务逻辑都是不利的。
您不希望因为决定更改 UI 技术而不得不重新编写应用程序。
这也更有利于安全性。如果业务逻辑下放到浏览器，用户有机会看到代码并了解您正在做什么。
因此，最好将业务逻辑保留在服务器端。
2
  1. 它变得可重用（既可以供其他应用程序使用，也可以供不同的视图使用（例如JSON API））
  2. 它将其从设计师手中拿走（这样它就不会妨碍他们，并且设计师也不会意外破坏它）
1

我不确定，但可能是这个原因：

它是为了可重用性的目的。

JSP应该只用于展示目的，我们的HTML设计师，后来设计页面的人对Java编码不熟悉，会感到不舒服。在Servlet中编写所有业务逻辑使代码可重用，并且在JSP页面中编写业务逻辑还有其他方法，比如使用脚本。所以为什么要做利润较少、额外工作的工作呢？

现在，如果我们将JSP页面用于业务逻辑，那么脚本将更多地出现在JSP页面中，这将导致维护成本增加。为业务单元单独声明Servlet将避免以上所有问题。

0

只是想补充其他同事提到的好理由，特别是关于“业务逻辑应该移出JSP”的问题。

简而言之，在工作中，我们有很多JSP，其中业务逻辑分散在各个地方，看起来非常混乱。有一些逻辑用于从会话/请求中获取对象并执行某些检查。一个简单的例子是根据某些条件构建不同页面标题的逻辑都在JSP中。

我们如何将这个逻辑移到我们这边呢？我们引入了一个页面构建器/组合器对象，它接收构建特定页面所需的所有必要细节，并检查和设置页面bean对象中的所有正确字段。然后将此页面bean对象设置为请求，例如。这意味着您现在可以将以前在JSP上的所有逻辑移动到页面构建器/组合器对象中，最重要的是您可以编写单元测试来测试！页面bean中是否设置了正确的值。

final SimplePageBuilder pageBuilder = new SimplePageBuilder(object1);
request.setAttribute("TestBean", pageBuilder.buildPage());

buildPage方法将返回页面bean对象，在JSP中，一个简单的例子getTitle将简单地返回标题（易于阅读，因为逻辑是抽象的）。
0

如果将业务逻辑与表现逻辑分离，可以更好地重用和维护Web应用程序。

假设我有3个JSP页面，每个页面都需要执行一些共同的业务逻辑。如果我将业务逻辑放在JSP页面中，代码会出现重复。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接