Lightweight DTO/EJB


EJB design: Lightweight DTO/EJB

  1. Lightweight DTO/EJB (7 messages)

    When designing an online application, many times we need to display a list of all customers or all accounts. These objects are quite robust and have lots of fields that get pulled from the database.

    We are seeing performance issues when polling the DAO for these objects when to the user, we only display maybe 10% of the fields that the object actually contains.

    Is there a solid approach/pattern to handling polling your objects based on UI-level requirements and what the designer's define they need?

    Threaded Messages (7)

  2. Lightweight DTO/EJB[ Go to top ]

    CachedRowSet :)
  3. Lightweight DTO/EJB[ Go to top ]

    have you had much success with the CachedRowset?
  4. Lightweight DTO/EJB[ Go to top ]

    have you had much success with the CachedRowset?

    For passing data from SessionBean to client: yes.
    For updates/inserts/deletes: no. The previous versions of Sun's and Oracle CachedRowSet have problem - always commit after each table data modification, so
    it's impossible to modify more then one table in the same transaction.
    I'm not sure if Sun has changed this in the latest CachedRowSet implementation.
  5. jcache[ Go to top ]

    can jcache solve this problem. There are open source projects which implement this.

    deepak mittal
  6. jcache[ Go to top ]

    the problem i have is that there are multiple RPG apps interacting with the data at the same time-- no timestamps or versions on the fields. Therefore, the requirements say that i can only cache data the scope of a transaction. I am running into examples where my DAO is pulling large objects through the application layers from the db, when i want to only display a smaller snapshot of the data from the db.

    In terms of Domain Layers, how to these lightweight beans fall into place?
  7. jcache[ Go to top ]

    you could still cache and use an invalidation mechanism to invalidate the cache when an update happens.
  8. Lightweight DTO/EJB[ Go to top ]

    One of the advantages to using DTOs is that your DTOs don't have to correspond one-to-one to your EJBs. One EJB could have multiple DTO representations. One DTO might represent data from multiple EJBs.

    You could create a DTO that represents the 10% of the fields you need on the UI. Whether you should actually populate the DTO from the EJBs or populate the DTO from a data access object (DAO) will depend on the specifics of the situation.

    For applications I've worked on, it's fairly common to use a "summary" DTO when displaying search results with a large result set. The summary DTO is often populated using a DAO. Usually the summary DTO has the id (or primary key field(s)) of the object it represents. If the user decides they want to see or work with the details of the full blown object you then make a call to retrieve the full detail DTO which is usually populated directly from the EJB.

    One thing you want to try to avoid is creating a unique DTO for every single view in your system. However, usually you can get by with one detail DTO and one summary DTO for most of the objects in your domain involved in large search results.