EJB design: Design Queries

  1. Design Queries (7 messages)


    We are in the process of developing an application using J2EE and DB2/400. The current system has stored procedures already written. This is case, i need to know the best approach for design.


    Threaded Messages (7)

  2. Design Queries[ Go to top ]

    There is absolutely no way to form an reasonable opinion about this question without a lot more details. What is the nature of your application? How "data-intensive" are these stored procedure? How much effort would it take to convert? What are the transactional requirements? Do you need EJB's benefits or is a Servlet-based solution sufficient? What App server are you deploying to? What is the number or complexity of entities in your database?

  3. Design Queries[ Go to top ]

    A reasonable approach is to use the DAO pattern in your design, in which you define interfaces for your data access functions. For now, you can have an implementation of the DAO's that uses Stored Procedure to access data. Later on, if you decide to abandon stored procedures, you can swap in a different set of DAO's without changing the rest of your components. This method works well with EJB or plain webapp because you can specify the DAO implementation classes in configuration file. The appropriate DAO can be instantiated at runtime with the help of a Factory Class.
  4. Design Queries[ Go to top ]

    This may be feasible if the stored procs only do data access, but usually when people say an application is based on stored procs I would assume they mean the procs also encompass some sort of logic (otherwise why would you even use them?). Do you think it's appropriate for a Data Access Object to provide methods that access business logic?

  5. Design Queries[ Go to top ]

    Given the above scenario, it seems appropriate and is the quickest implementation path and yet provide some level flexibility. But if we were to start this project from scratch,it's not a good idea to code too much business logic as Stored Procedure because this sacrifices compatibility. ie what if we decide to change database, then the stored procedures are not reusable.
  6. Design Queries[ Go to top ]


    I didn't mean to ask whether you think using stored procs is appropriate. Like I said, I can't form an opinion on that without further information. I asked if you think calling the component which calls the stored procs a "DAO" is an appropriate abstraction. I don't think it is. IMHO, a DAO should not encapsulate business logic. And just because you call it a DAO doesn't mean it'll make the shift to a more object-based architecture easier. If you have a class that encapsulates usecase-level business logic then there really is no reason not to use stored procs. If you do want to move to an object-based solution then you'll have to change your code anyway.
    I think an abstraction like Command is more appropriate for encapsulating usecases like this, each command calling a different stored proc (and in the future, the implementation of the command can change to access JDO objects/entity beans/whatever).

  7. Some more input about my project[ Go to top ]

    Its based on MVC architecture with SP's holding most of the business logic . The application is bound to have more data entry screens and few reports . The application will be depolyed on websphere.

    I am looking for a best possible design approach . Also , could you throw light on the kind of j2ee design patterns that can be used here

  8. Some more input about my project[ Go to top ]

    What type of logic do your stored procs encapsulate? Is it data-access functionality (like "create_user") or usecase-level functionality (like "find_user_accounts_and_summarize_positive_balances")?