首先我们设计一个JndiHelper类，用于封装查找实体Bean的JNDI操作，同时还对实体Bean的Home接口缓存。

　　我们把所有的逻辑封装到3个Session Bean中：

　　MusicView.ejb：用于封装浏览，下载等页面操作。

　　AccountManage.ejb：用于封装注册，登陆等账号操作。

　　MusicManage.ejb：用于封装管理员的各项操作。

　　首先建立MusicView.ejb，我们一共设计了以下业务方法：

　　所有的方法均为远程方法，这样Web层和EJB就可分开部署。当然你也可以将会话Bean接口全部改成本地接口以进一步提高性能。方法看上去虽多，但逻辑相当简单，例如，getAlbums(int artistId)方法：

　　基本逻辑大致为：

　　查找相应的实体Bean，获得实体Bean对应CMR关系的集合，在将其包装成值对象返回给客户端。你可以看到，由于没有JDBC操作，代码被大大的简化了，并且由于容器处理了底层数据库连接，使我们的代码更加健壮。

　　在这里我们采用了值对象（Value Object）模式，用于在Web层和逻辑层之间传送对象。你可以很容易的写出每个实体Bean对应的值对象，比如Album.ejb对应的值对象AlbumVO。

　　然后创建AccountManage.ejb，用于处理用户帐号相关的操作：

　　如果要提高系统的安全性，建议使用MD5码存储用户口令，MD5算法是一个单向函数，即使获得数据库表也无法得知用户口令。如果要进一步防止使用预先算好的MD5码攻击，还可以采用加盐处理。为了简单起见，我们直接将用户口令存储在数据库表的字段中，因此login(String username, String password)看起来像这样：

　　如果找到了相应的实体Bean（即数据库表中存在此记录），再判断password字段，如果相符，验证通过，否则，抛出一个自定义的UnauthorizedException异常。这里也不涉及JDBC操作，因此代码非常简单。

　　搜索功能是通过实体Bean的Finder方法实现的，标准的EJB QL 2.0并不支持带参数的like关键字（在SUN J2EE SDK中编译就会失败），幸好WebLogic对其进行了扩充。为了实现模糊搜索，这里我们定义了Song.ejb的一个Finder方法findByTitle(String title)，对应的EJB QL为“SELECT OBJECT(o) FROM Song AS o WHERE lower(o.title) LIKE concat(%, concat(?1, %))”。如果使用其他厂商的服务器，你需要查看厂商的EJB QL文档然后作相应的修改。

　　最后一个是MusicManage.ejb，用于管理员创建、删除信息：

　　创建和删除实体Bean的代码都非常简单，唯一需要的就是捕获相应的异常，我们在deleteSong(int songId)中将RemoveException包装成更一般的ApplicationException异常返回客户端：

　　需要特别注意的是，对存在一对多CMR关系的实体Bean，如果指定了级联删除，当删除“一”时，对应的“多”会被自动删除，因此执行删除前要异常小心，至少应该提示用户，或者，只允许删除“多”为空的实体Bean，比如删除Artist.ejb时：

　　home = JndiHelper.getArtistLocalHome();

　　artist = home.findByPrimaryKey(new Integer(artistId));

　　Collection c = artist.getAlbums();

　　if(c.size()>0) throw new Exception("Cannot delete unless it is empty.");

　　为了安全起见，我们在删除时不允许删除“多”一方不为空的实体。

　　编译，部署。OK，小功告成！现在我们可以测试一下我们的逻辑层。一个好的办法是使用JUnit测试，但是似乎Workshop尚未集成JUnit。没关系，我们自己写一个客户端Java程序来测试逻辑层。

　　在MusicClientProject中建立Client.Java类，放在包music.client中。为了测试，我们首先在数据库中创建一些测试数据：

　　void initData () throws Exception { … }

　　然后，我们写一个testGetCategories()方法：

　　void testGetCategoris(int parentCategoryId) throws Exception { … }

　　类似的，我们对每个业务逻辑都写一个相应的测试方法，直到每一个业务逻辑都正确无误。在一个独立的Java客户端程序中测试EJB要比在JSP中方便得多，你可以方便地设置断点，跟踪以便查看变量，随时使用System.out.println()在控制台输出任何调试信息。

　　表示层用于向用户提供系统交互的接口。采用J2EE的系统表示层一般都是瘦客户端，使用JSP/Servlets技术，使用户能通过浏览器使用系统。在JetMusic站点中，我们将考虑以下几种实现方式：

　　1．在JSP中使用业务代表模式：

　　通常，在JSP/Servlets中直接调用EJB并不是一个好主意，这需要大量的查找JNDI的代码，业务代表（Business Delegate）是一个不错的模式，它封装了所有的EJB查找和调用，使得表示层和逻辑层的耦合度能降到最低，并且还可以进行一些缓存。

　　由于业务代表类将Web和EJB隔开了，因此，对于JSP/Servlets来说，它们根本就不知道EJB的存在。这将带来另一个好处：只要在设计时仔细定义了业务代表的接口，Web层和EJB的开发人员立即可以同时开发各自的模块，Web层的开发人员可以首先对业务代表类进行硬编码，以便返回他们希望的结果。等到EJB开发完成后，再用实际的EJB调用替换即可。

　　为了封装对MusicView.ejb的所有调用，我们建立一个MusicViewBD的业务代表类：

　　在index.jsp中即可使用MusicViewBD以便输出Categories：

　　2．使用NetUI标签实现数据绑定

　　WebLogic提供了大量的NetUI标签，能够方便地在JSP中绑定数据。我们下一步将创建一个viewCa.jsp页面，此页面向用户展示分类。

　　我们首先创建一个EJB Control。WebLogic向我们提供的EJB Control完全封装了EJB调用。利用EJB Control，我们不用写一行代码，立刻就可以在JSP中调用EJB。这个EJB Control可以看作是一个用标签封装的业务代表模式的应用。

　　在MusicWeb工程下新建文件夹music.control，用于存放EJB Control。新建EJB Control，命名为CallMusicView：

　　选择“Browse application EJBs…”，直接找到“MusicView (remote jndi)”，Workshop会自动填好相应的接口，点击“create”即创建成功。

　　当我们获得了从EJB返回的Collection后，可以使用Repeater标签显示这个复杂的数据，在这里我们不打算进一步讨论Repeater标签的细节，关于如何使用Repeater标签，可以参考下面的文章：