为什么业务逻辑应该从 JSP 中移出？
既然 JSP 主要用于表示，那么将业务逻辑保留在 JSP 之外有什么优点？我们仍然看到业务逻辑编写在 JSP 内部，因此我需要知道通过将业务逻辑移出 JSP 可以获得什么好处。
What are the advantages of keeping the business logic outside JSP, since JSP's are meant mainly for presentation? We still see business logic written inside the JSP, so I needed to know what benefit we get by moving business logic out of JSP.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
MVC的主要好处 是您可以拥有多个视图以及干净且独立的架构& 简单性
可重用性
假设明天您需要在桌面应用程序上运行相同的应用程序。那么你就可以改变视图。
可测试性
您可以对服务方法进行单元测试，但不能简单地从视图中对逻辑进行单元测试。
可维护性
服务方法中的代码很容易理解，我们也可以更改它/发布服务API并轻松维护它
版本能力
您可以为您的API提供版本并维护如果您使用服务 API 而不是逻辑视图，则与问题/更新相关的标准文档
另请参阅
The main benefit of MVC is you can have multiple view and clean and separated architecture & Simplicity
Re usability
Suppose tomorrow you need same app running on a desktop app. then you can just change the view.
Testability
You can unit test your service methods, but you can't simply unit test logic from view.
Maintainability
It is easy to understand the code from Service methods, also we can change it /release service api and maintain it easily
Version ability
You can give version to your API and maintain standard docs related to issues/updates if you use service API instead view for logic
See Also
这是关注点分离设计原则的典型应用。
通过分离问题，即通过为每个单元创建单独的逻辑单元（主要是类），您可以减少更改任何特定单元的原因数量。
SoC 的另一个好处是减少这些单元的平均大小和复杂性。这反过来又使您的软件更容易理解和更改。
此外，拥有小的逻辑单元使它们更容易进行单元测试，更容易在集成测试中模拟，并且更容易在实现更改后修复测试。
It is a typical application of the Separation of Concerns design principle.
By separating concerns, i.e. by creating separate logical units (mainly classes) for each of them you reduce the number of reasons to change any particular unit.
Another benefit of SoC is reducing the average size and complexity of these units. This in turn makes your software easier to understand and to change.
Furthermore having small logical units makes them much easier to unit test, easier to mock in integration tests and easier to fix the tests after changes in the implementation.
我将为这里发布的所有非常好的理由再添加一个理由。
客户端技术一直在变化。用户不想通过桌面、浏览器或移动应用程序来访问；他们想一直使用所有这些。因此，如果您将业务逻辑嵌入一种类型的用户界面技术中，您可能必须将其复制到所有其他技术中。这不利于维护、可重用性和添加新的业务逻辑。
您不想仅仅因为决定更改 UI 技术就必须重新编写应用程序。
这对于安全性来说也更好。如果业务逻辑深入到浏览器，用户就有可能看到代码并弄清楚您在做什么。
因此，最好将业务逻辑保留在服务器端。
I'll add one more reason to all the very good ones that are posted here.
Client technology is changing all the time. Users don't want to come through a desktop, browser, or mobile app; they want to use all of them, all the time. So if you embed business logic in one type of user interface technology, you'll probably have to duplicate it in all the others. That's bad for maintenance, reusability, and adding new business logic.
You don't want to have to re-write your app just because you decide to change UI technology.
It's also better for security. If business logic goes down to the browser, there's a chance that users could see the code and figure out what you're doing.
So you're better off keeping business logic on the server side.
我不确定，但这可能是原因：
它是为了可重用性目的。
Jsp 应该只用于
演示目的和我们的 html 设计师，后来设计
页面不知道java编码会不舒服。
并在 servlet 中编写所有业务逻辑让代码
可重用。并且用于在 jsp 页面中编写业务逻辑
是像使用 scriplet 一样的其他方式吗？那么为什么要做这项工作
利润减少，工作量增加。
现在，如果我们使用 jsp 页面来执行业务逻辑，那么
scriptlet 将更多地位于 JSP 页面内，这导致
维护成本高。业务单元单独声明servlet将
避免以上所有情况。
I'm not sure but this can be the reason:
Its for reusability purpose.
Jsp should be only used for
presentation purpose and our html designer,who later design
the page is not aware of java coding will not be comfortable.
and writing all buiseness logic in servlet lets the code
reusable.and for writing buiseness logic in jsp page there
are some other way like using scriplets.so why do the job
with less profit and extra work.
Now if we are using jsp page for business logic then
scriptlet will be more inside the JSP page which leads to
heavy maintaince cost.The seperate declaration of servlet for business unit will
avoid all above.
只是为了补充其他同行发布的充分理由，特别是关于“业务逻辑应该从 JSP 中移出”。
简而言之，在工作中我们有很多 JSP，其中业务逻辑全部结束，而且看起来非常混乱。存在从会话/请求中获取对象并执行某些检查的逻辑。一个简单的例子是根据 JSP 中的某些条件构建不同的页面标题。
我们最后如何移动这个逻辑是引入一个 Page Builder/Composer 对象，该对象接收构建特定页面所需的所有必要细节，并检查和设置页面 bean 对象中的所有正确字段。然后根据请求设置此页面 bean 对象，例如，这意味着您在 JSP 上拥有的所有先前逻辑现在都移至页面构建器/组合器对象，然后最重要的是您可以编写单元测试进行测试！页面 bean 中是否设置了正确的值。
buildPage 方法将返回页面 bean 对象，并且在 jsp 中，一个简单的示例 getTitle 将仅返回标题（由于逻辑被抽象，因此易于阅读）。
Just to add to the good reasons posted by other peers and particularly regarding "business logic should be moved out of JSP".
In a nutshell at work we had lots of JSPs where business logic was all over and it was pretty messy looking at it. There was logic to obtain objects from the session/request and perform certain checks. One simple example is contruction of different page titles depending on certain conditions all in the JSP.
How this logic was moved at our end was to introduce a Page Builder/Composer object which takes in all the necessary details to contruct a particular page and checks and sets all the correct fields in the page bean object. This page bean object is then set on request for e.g. This means that all the previous logic you would have on the JSP is now moved to the page builder/composer object and then most importantly you can write unit tests to tests! if the right values are set in the page bean.
The buildPage method will return the page bean object and in the jsp a simple example getTitle would simply return the title (easy to read as the logic is abstracted).
如果业务逻辑与表示逻辑分离，则最好重用和维护 Web 应用程序。
假设我有 3 个 JSP 页面，每个页面都需要执行一些常见的业务逻辑。如果我将业务逻辑放在 JSP 页面中，就会出现重复的代码。
It is better to reuse and maintain the web application if business logic is separated from the presentation logic.
Suppose I have 3 JSP pages, each require some common business logic to be performed. If I put the business logic inside the JSP pages, there will be duplicacy of the code.