将业务逻辑放置在Java Beans中？

Question

我正在阅读这个页面，并发现以下声明：

Java Server Pages中的MVC

既然我们有了方便的架构来分离视图，那么我们如何利用它呢？ Java Server Pages（JSP）变得更加有趣，因为HTML内容可以与Java业务对象分离。 JSP还可以使用Java Beans。业务逻辑可以放置在Java Beans内部。如果设计正确，Web设计师可以在不干扰Java开发人员的情况下使用JSP网站上的HTML。

有趣的是，在我的教科书中，我引用了以下语录：

在MVC架构中...原始请求总是由servlet处理。servlet调用业务逻辑和数据访问代码并创建bean来表示结果（这就是模型）。然后，servlet决定哪个Java Server Page适合呈现特定的结果，并将请求转发到那里（JSP是视图）。servlet决定适用哪些业务逻辑代码以及哪个JSP应该呈现结果（servlet是控制器）。

这两个语句似乎有点矛盾。最好的使用bean的方式是什么：我们应该在其中放置业务逻辑还是只放置结果？ bean在表示模型方面是否存在不足之处？

- Kiril

Answer 1

在IT技术中，将业务逻辑放置在带有Manager后缀的类中是相当普遍的。虽然有些人会将业务逻辑放在数据对象bean本身上，但我发现最好只在数据对象上编写简单的方法，这些方法不依赖于任何外部依赖项。所有其他业务逻辑都应该放在一个Manager bean中，它能够使用多个数据对象javabean和其他外部依赖项来跟踪业务逻辑。例如，AccountBean将包含账户字段和一些简单的方法，这些方法使用这些字段计算并返回值，或格式化字段。所有业务逻辑都将在Manager中，可能是AccountManagerBean。

- Dark Castle

---

你的JSP使用Manager Bean还是只使用Model Bean？ - Kiril

你的视图希望在JSP之后有一些东西，在Struts中它是一个Action类，在某些地方它是一个servlet类，其他框架使用其他东西。在那个Java类中，您可以使用Manager查找、更新、添加、删除并传递数据bean。在JSP中，最好尽可能少地使用Java，因此我只会在那里使用视图数据javabean，并将Manager排除在外。 - Dark Castle

我觉得这一切都很矛盾。因为在大多数关于JavaBeans的文本中，它们似乎强调它们是简单的数据容器，几乎只应该有getter和setter，这与我的业务对象应该如何看待的观点不太相符。我完全尊重您的答案！只是想听听您对JavaBeans具有getter和setter的“限制”，然后添加其他方法以添加逻辑的想法的看法。也许我误解了整个JavaBeans的概念？我真的不知道。 :-o - brat

Answer 2

第二个语句基本上是在讲两个JavaBean：一个用于业务逻辑，另一个用于模型。因此，是的，业务逻辑仍然可以放置在JavaBean中。业务逻辑的JavaBean可以将模型的JavaBean封装为其属性。

public class User {
    private Long id;
    private String name;
    // ...
}

public class UserManager {
    private User user;
    // ...

    public void login() {
        // ...
    }

    public void logout() {
        // ...
    }
}

- BalusC

---

你知道有哪些情况下Bean可能不适合用于呈现模型吗？我还没有遇到足够的情况来举出一个好的例子，但是有哪些不适合使用Bean来呈现模型的例子呢？ - Kiril

此外：在JSP中，商业Bean是否可以像模型Bean一样使用？ - Kiril

我认为没有哪种情况下Bean不适合表示模型。是的，您可以像访问属性一样在JSP中使用它来访问属性。根据请求，控制器将调用相应的操作。 - BalusC