Hi, First of all I'm going to describe the architecture I'm using. I'm writting an application that uses an Oracle 9i Database, and Weblogic 6.1 sp1 as the Application Server. Also I use Entity CMP EJBs mapped to the database. In adittion I use Session EJBs as Facades of the Entity Beans. The presentation tier is implemented with JSP and Servlets (and perhaps XML). 1- When I have to return a "record set" to the client (in this case a JSP page) from the Facades I use a Collection containing Value Objects in place of a Collection containing Remote Interfaces to the Entity Beans. Is it a good solution in terms of performance? 2- It would be a good solution to return XML from the Facades in place of Collections? 3- Is there any API to generate XML from Collections? Thanks in advance. Cristian.
I suggest u not to create Entity bean retmote interface collection just for the purpose of displaying data. I suggest u to retrive the data to be viewed from session beans using JDBC rather then calling findBy method of entity. The reason is u will end up creating ejbobjects for the entity beans ..and u are just displaying the data. U have un necessarialy created EJBobjects which are not used.Delay the creation of such objects until that entity is used. I advice u not to use XML because of its nature of redunant data. U can download Oracle XDK Kit from Oracle site that can convert database rows into XML file.
I'm in agreement with everyone else. Returning a collection of Value Objects is by far the highest-performing solution of the set of solutions you've suggested. I also believe that you should ONLY return XML if you plan on rendering your interface using XSLT -- and in that case, I'd probably STILL return value objects and then ask them to render themselves as XML inside the servlet. Kyle
As Pradeep said, there can be problems with finders on entity beans. When you get a collection from a finder, the container will create entity objects in the pool for each of those objects. For finders that return many objects or heavily loaded servers this can be a problem (you can fill up the pool). If your finder only returns a few objects, it is not really a problem - only when the finder returns hundreds or thousands. However, to trade the entity beans - and especially the advantages of CMP - for a session with pure JDBC is not really a good trade, IMHO. You could replace the finder with a entity home method that uses a select method to return primary keys or value objects. This way the finder does not have to activate all of those beans, and you can still back the select method with EJB-QL. As for the XML thing, where you do it depends on why you are doing it. If you are doing XML because of some needs in your presentation layer, then do the XML translation there. But if the XML is somehow fundamental to your middle-tier (either Model or Controler in MVC terms), then it would make sense to move it there.
Originally posted by Kyle Brown: I'm in agreement with everyone else. Returning a collection of Value Objects is by far the highest-performing solution of the set of solutions you've suggested. I also believe that you should ONLY return XML if you plan on rendering your interface using XSLT -- and in that case, I'd probably STILL return value objects and then ask them to render themselves as XML inside the servlet. Kyle
Only thing I would change here is the "render themselves as XML inside the servlet." I am totally against having objects XMLize themselves. That should be done by an outside entity. Don't muddy up your business domain objects with XML code. Just my $0.02
James Carman, President<br />Carman Consulting, Inc.