Hello all, I have a question that probably seems basic, but I really just can't get my brain around it. I understand that Entity beans represent single records in a database table, or something similar. Okay so the question is, most of the time when I write a program, there are a couple different tables and a single SQL statement that ties them all together. If I want to say display a record, then I use that SQL to get back a record with all the descriptions and stuff from other related tables. In the case of EJBs, do I just create a EJB that represents each Table record structure? And with that, if I want to make an object that would have a full record with descriptions and all, would I have put it together somewhere? Basically, can I not do like I did in older apps and just return a complex query into a single record set and work from that?
hi, if your joined sql represent a logical object(it depends on your application design) and you use that data as single unit, then you can create an entity EJB that holds the joined data inside. but if you need to use tha data as a diffarent units nad also as a joined unit then you need to create a number of entitys that one of them can contain the others. you can work with a single record set , if you are not using entity beans (and you dont have to use them) hope that answer your question
In the case of EJBs, do I just create a EJB that represents each Table record structure?
Hell No! While it is very convenient and almost a second nature to map tables to classes, columns to attributes ( and hence rows to objects ), such a mapping scheme has the potential to contaminate the object model and introduce what is known as impedance mismatch. The mismatch arises because of incompatibility between relational schema and object oriented paradigm which are governed by their own set of rules and constraints. While the relational schema is supposed to adhere to rules of normalization, reduced redundancy and structures that support robust indexing and searching, good OO design should reflect the entities that embody the domain logic while making use of principles such as polymorphism, abstraction and encapsulation. Developing an object model that is close to the business domain rather than the data domain is the key that distinguishes an object oriented system from legacy applications. What you need is a design to support "coarse-grained" entity beans that represents a business(aka domain) object. Sometimes this pattern is also referred to as "aggregate entity beans". The idea is to wrap dependent objects that have no domain behaviour of their own with aggregate objects. If you are using CMP, the new Container Managed Relationships(CMR) will make your life a lot easier. If you are using BMP, you will have to implement code that manages the lifecycle of dependent objects in the context of that of the parent object. Try a Google search for "aggregate entity" and you will find a handful of articles, some with examples that help you understand the pattern. Cheers,
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).