EJB design: Designing the Domain Model for the Entity Bean context

  1. We need a business domain model with many business objects like Customer, Address, Article and so on.

    Since our persistance layer uses Entity Beans, no inheritance is possible with these Business Objects (I know there is a trick, but we cannot use it).

    So I thought that the same principles could be applied like in relational database design. I mean we could use Normalization rules for our business objects in order to achieve a good design. This would be a formal process. I would suggest to normalize the domain model at least to the third normal form. What do you think of this idea?

    Of course it would be proper to make a technical neutral analysis model with UML. It would include inheritance of business objects. But I think it will be hard to convince the decision people of doing two models, one technically neutral, one which considers the technical base (Entity Beans). So I think we will have only one model, the technical.

    I'm testing ideas first here because I need some arguments to convince the decision people.

    Please take a look at my small example of a business object called Address (UML class diagram): http://www.geocities.com/springfont/index.htm

    In this model I applied the normalization rules. I fear that some people will think that there are too many classes. Of course there are many 1:1 relations. But because of funcional dependance, I don't put them all in the Address object (Street, PoBox and City). Is it good or bad this way? I think it documents itself better this way than having all the objects in one bigger object called Address.

    By the way, we use a persistance framework which will map the objects to the database. So it will be possible that all these different objects can be stored in one table because of better performance.

    So my questions are: Would you apply Normalization rules when designing Entity Bean business objects and what do you think about the design of Address?
  2. Your diagram looks nice but I think you should also think about an object method that receives your Address object as its parameter and how it would identify whether the passed object has Street reference or PoBox reference. From this point of view I think the following might help:

    StreetAddress extends Address
    PoBoxAddress extends Address

    The receiving object can then use instanceof operator to identify which kind and process accordingly.

  3. I think basing your EJB object model design on database normalization rules is a bad idea. You can get away with heavily normalized data in your database design, because databases are optimized for that sort of thing. EJBs are not.

    If you split your Address up into four separate EJBs, you will need four separate queries to retrieve a single address. Designing queries to retrieve multiple addresses will be hideously ugly, because EJB-QL is nowhere near as functional as SQL (no joins).

    If you want to get something remotely resembling reasonable performance, you should design your EJB model around logical business concepts. Group the data together in the units you will be working with, so you can focus on optimize the EJB-to-database interactions.
  4. Nalla Senthilnathan:
    I think I cannot do it with inheritance because Entity Beans don't allow this. Further it would not be correct to extend StreetAddress and PoBoxAddress from Address because we need a object which can store both street address and P.O. box address. But StreetAddress stores only the street and PoBoxAddress can only store a P.O. box.

    Paul Strack:
    Its no problem with performance. The reason is because Street, PoBox and City are "composition objects". We don't use Entity Beans directly but we use a kind of homegrown persistance framework which itself uses Entity Beans. So in the end Address and the composition objects would all be located in the same table. Its no problem with the EJBQL queries. The advantage of this approach would be that we have a good performance and a more comprehensible object oriented model.
  5. Hans:
    If you are using BMP and a home-grown persistence framework instead of CMP, most of my objections go away.

    I still think you will be better off building your domain model around logical business concepts, though. Having to parse data out of three for objects for information that you are almost always going to be using as a unit (like an Address) is going to get tedious, and I don't see any real benefit from it.

    If you want to go this route, I suggest you make value objects for your "low level" objects, and do something like this:

    class AddressEntity {
      Street getStreet()
      City getCity()

    Or maybe that is what you meant to do all along and I misunderstood you, in which case I apologize :)
  6. Hi Paul,

    I know what you mean that it seems tedious with so many objects.

    I tried to apply the Normalization rules. They were invented because to reduce redundancy and to prevent anomalies. But the objects are automatically merged by our persistance framework before they are saved. So they end up in one table ADDRESS. The whole thing works although we use CMP. Don't aks me how, we just use this framework which is on top of CMP.

    The main reason why I wanted to apply the Normalization rules (although they have no effect on the DB) is because of comprehensibility and self documentation of the Domain Model. Maybe its exagerrated in my case (Address), I have to think about it.
  7. Hi,
    My thought is that you should not let the technical details (using entity beans) interfere with your design. A good model is a technical neutral one (like the one in your UML class diagram). You should isolate the persistence of your domain objects in a layer that deals with the object/relational mapping. Here you can have different DAO implemnetations : with entity beans, straight JBBC, Hibernate, JDO, other OR mapping tools (TopLink, Cocobase, etc.). If you want your domain objects to be distributed objects you should wrap your domain objects in session beans or expose the operations on the domain through a session facade . Another (bad) approach for distributed domain objects would be entity beans. But with remote entity beans you don't have container managed relations and you have the overhead implied by the entity beans.
    Best regards, Mircea