I'm designing a Digital Asset Manager for a firm here in NYC and I need a bit of advise. The application will need to keep track of around 5 million assets. For each asset there will be meta data, legal data, preservation data, and source data. The application will also need to track all changes that occur to the data. Sound like fun?
The question is this: Should I use an MVC model that does not rely on EJBs, or should I use EJBs with a CMP? I've heard that querying 100,000 rows in an EJB environment can be very slow due to the network transfer involved.
I'm toying with the idea of writing my own query interface that simply returns a result set without making any beans. Then creating a bean once the user has selected the Asset of interest.
Any help here would be greatly appreciated.
Point to note is that Content Management Systems already provide the features you are talking about. Unless you are looking to build one , I recomend that you look at the comercial ones available.
As for data access, look into JDO. It is possibly the best alternative to using Entity beans. I am sure allot of people may agree and disgaree on this stance, but it is a technology you seriously need to consider.
Comparing MVC and EJB/CMP is like comparing apples to oranges. One is a design pattern, the other is an implementation technology.
You will probably want to use MVC as a design pattern.
You will probably want to use Session EJBs to implement your system.
It seems that the real question is how to deal with persistence.
CMP is still new, and yes, it could be hella slow for returning 100,000 rows. If you don't want to use that, you have 3 options:
1. JDO (As the other poster suggested)
2. Some 3rd party O/R mapping tool like TopLink.
3. Use JDBC to do it yourself. With JDBC you will probably use the Data Access Object pattern, Data Transfer Object/Value Object pattern and the session EJB facade pattern. Read about them in the EJB Design Patterns book available on this site.
I will look into JDO, or possibly writing JDBC myself. As you probably noticed I'm very new to the EJB world.
Also read Floyds chapter about alternative to entity beans. The advantage to EJB/CMP is that you will be up and running very quickly. CMP entity beans can be created in minutes. You can then try them out in a proof of concpet before committing yourself.
If you have a large (even medium) set of data to be dealt with, entity beans will be an overkill. Go with JDBC and stateless session beans accessing database thru a JDBC data access layer.
"The advantage to EJB/CMP is that you will be up and running very quickly"
That is correct, except the 'running' part in 'up and runnig'. You will be done with implemnttaion real quick , then you are going to spend your entire life making it run as you expected.
Up and running obviously meant getting it built. I'd be a bit less hasty if I were you before denouncing CMP technology off hat. It sounds like you've had some bad experiences - have you tried the latest CMP engines such as the one with WLS 8.1 - or MVCSoft?
There are more benefits from using CMP that there are from straight JDBC. But I agree that performance can make a lot of the benfits count for nothing.
What I was suggesting is that he tries it out through a POC.
BEA now claims that CMP performance matches that of direct JDBC.