EJB design: Database view as entity or session bean?

  1. Database view as entity or session bean? (2 messages)

    Hi There!

    I have a database that contains a set of tables. I'm designing an enterprise application that deals with the information on these tables. The thing is that I want to add some abstraction level on this tables to represent a concept in my problem domain. This will be something like a view. the question is: should this concept be represented as entity bean or as a session bean? Some people tell me that it must be a session bean 'cos the data has no direct representation on a table, but the point is I think they should be entity bean because the conception of the solution. I mean, in my problem description this view appears as an entity...

    Any ideas, criticism or some thing?

    Thanks a lot
  2. Hi
    u see slection of enity bean or seesiob bean depends on
    the table structure and also on transaction invlolved with the same so ... always remeber one rule always use entity bean if the table is shared among concurrent clients
    and trnsaction involved for each feild ..
    if u wasnt to retrive junk of data and storing maas of data then go for session bean with JDbc calls inside or
    Use DAO classes the same i am designing in my architecture solution
    Feel free to talk to me on
    s dot manoj at zensar dot com
  3. Hi Manoj

       The thing is I'm in a very early project development. I'm only looking for entities in my problem and this things... Theorically I'm thinking to add what I call "Database Abstraction Layer" because the system already exists, but for the proper functionality of the system I've thought (and maybe future updates) this Layer simplifies the things.

       So, the point is if it is correct to do it so, I mean, can I group a set of tables into an Entity bean? Of course this grouping involves (maybe) modifications on the set of tables that forms the Entity bean. Anyway it is also possible without this "Entity View" but this adds complexity to the system, maybe dealing with details that not belong to the business of the new system.