Stateless EJB and Domain Model pattern


EJB design: Stateless EJB and Domain Model pattern

  1. Stateless EJB and Domain Model pattern (1 messages)


    I have a question regarding use of Domain Model pattern. In our project we are creating customer profiles. We have modeled profile something like this.

    class Profile {
      Name name;
      List<Address> addressList;
      List <Phone> phoneList;

    We have CRUD operations for Profile, Addresses, and Phones. Each of the CRUD operations, is a separate HTTP request from web client, mapped directly to DAO method.

    For CRUD operations, we have DAO facade like this

     class ProfileDao {
       void insertProfile(Profile profile);
       void Profile getProfile(String profileId);
       void addAddress(String profileId, Address a);
       void addPhone(String profileId, Phone p);
       void updateAddress(String addressId, Address a);
       void updatePhone(String phoneId, Phone p);
       void deleteAddress(String addressId);
       void deletePhone(String phoneId);

     Client for this code will be like this.
     class ProfileClient {
       void handleAddRequest(Request request) {
    Address address = getAddress(request);
        // Should return address something like this.
        //new Address("112 Fifth Street", "NJ", "US", "08857");

    String profileId = getProfileIdentifier(request);

    getProfileDao().update(profileId, address);


     Instead of using Facade like this, I thought we could use it like following.

     1. Clients will do all CRUD operations on Profile object itself.
     2. All the classes will have isUpdated, isNew and isDeleted flag.
     3. Dao will have just one update(Profile p) method.
     4. Dao will check for updates and make queries accordingly
    Dao will now become like this.

    class ProfileDao {
       void insertProfile(Profile profile);
       void Profile getProfile(String profileId);
       void update(Profile p);

     Client for this code will be like this.
     class ProfileClient {

       void handleAddAddressRequest(Request request) {
    Address address = getAddrss(request);
    //Load profile object from Cache and then add addres to it.
            Profile p = getProfileFromCache();

            //Update profile
  2. Such a change might suit your current situation, but you are in some ways restricting your future development.
    Your current dataobject (Profile) is just a holder, a simple pojo with the values that define a Profile.

    Your DAO is in essence your business facade, as you are going with just two tiers (webclient to db behind DAO). Thats why I notice that your DAO isnt exactly CRUD operations, the method names actaully map to real life operations that you do from your client, (like addAddress, deletePhone) so your DAO is more like a business interface.

    Your issue seems to be that you want a simple DAO interface which is just CRUD while you still want the nice business methods that make sense to a client side developer, as in client developer changing a phone number in a list of addresses and then calling update(Profile p) doesnt really explain it all to him. The simplest solution, and i dont think its over kill is to abstract the client from db (put in that middle tier). Your implementation of this business interface is simply delegating the nice english named busines methods, on to the appropriate CRUD DAO method. In this middle tier, you can decide what needs to be updated, maybe have the DAO be clever and deal with not the Profile Pojo but aDAOPojo which has the flag attributes you mention above. Reason for this is I would keep the domain object model as just simple Pojos, as back on client tier, or for object to object, or if introducing new client, you want your business logic/intelligence in the one business middle tier, not passed about and exposed to all tiers (client, middle, persist).

    In truth what you have is ok, but i understand your need/want to change it, but if you do lock down to a very neat DAO, that your client uses (without business tier) when time comes for that one magic way out custom method that is requested in next release it will leave a bad taste in your mouth if you are forced to put it on your DAO as opposed to a business method , that you can handle more gracefully.