自从我学习了面向对象的程序设计以来，我一直有这个问题。现在，我有一个很棒的论坛，我想问这个问题。

可以说我们正在使用EJB实现员工管理应用程序。

现在，有两种方法可以做到这一点。

• 通常，我们创建代表员工的实体(POJO)。然后，我们使用添加，删除，更新，检索，retrieveAll方法创建一个EJB接口" EmployeeManager"。这样，我可以将"雇员"实体用作数据传输对象。
• 我们将EJB接口本身称为"雇员"。实现可以称为" EmployeeImpl"，它具有字段以及方法实现(添加，删除，更新，检索，retrieveAll)。如果我使用一种分层方法，其中我的业务逻辑需要访问员工详细信息，则需要传递" EmployeeImpl"(因为它包含值)。

我们认为哪种方法更好？

我喜欢第一个，因为它看起来"不错"并且不会感到尴尬。喜欢

EmployeeMgr empMgr = // JNDI lookup;
Employee emp = new Employee();
empMgr.add(emp);
Employee employees[] = empMgr.retrieveAll();

第二个看起来像什么(尽管我不确定)，

Employee emp = // JNDI lookup;
emp.setName(); //set the properties
emp.add();
Employee employees[] = emp.retrieveAll();

如我们所见，第二个看起来很尴尬。

我要求你们给我建议。

谢谢
满州

解决方案

第一个肯定更清晰，并且清晰无疑应该是代码的目标。但是，在第一个方面，我将指导我们：Jeff Atwood不建议将其称为" SomethingManager"。

在示例中，我不建议使用＃2，因为它给Employee类带来了太多的责任。

尽管没有给出直接的答案，但我还是可以诚恳地推荐Martin Fowler的书《企业应用程序体系结构的模式》。就我个人而言，这是一个很棒的大开眼界，并描述了几种不同的方法。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

我还认为开源的Hibernate是持久化实体的好工具。我敢肯定，我们会在这里找到很多不错的建议。

为保留Employee而设置分离的类看起来更加面向对象。而且更加灵活，因为我们可能希望使用DBEmployeeMrg，FileSystemEmployeeMrg，InMemoryEmployeeMgr和MockEmployeeMgr来测试所有这些类，因此可能以不同的方式实现EmployeeMrg接口。

为了使代码更短，我们可能希望让员工能够保存自己的名称而不是employeeMrg.save(employee)的employee.save()。
当员工进行自我保存，更新甚至删除时，我可以理解设计，但是绝对不需要一个员工按ID加载另一个员工并加载员工列表。

力求适当的设计，而不是" OO合规性"。

顺便说一句，EJB根本不是面向对象的。

使用EJB的最佳实践是：

• DataContainer类保存我们从数据库或者用户那里获得的数据； " POJO"
• EJB具有可在DataContainer上运行的方法
• DAO处理从数据库中持久/检索DataContainer。

EJB通常没有字段，除非将它们部署为无状态(这很少需要)。

如果我们使用的是EJB，那将是大多数人期望的设计。显然这不是面向对象的，因为DataContainers不包含实际方法，而EJB / DAO不包含实际数据。

这不是一件坏事;它可以将关注点分离开，并使系统更具可变性和可维护性。