Hello all,
I'm not entirely sure whether I'm posting in the correct forum. It may not be a bad idea to create a separate forum for discussion of general design and pre-implementation issues?
I am working on a project of mine that implements something close to CRM. The exact details do not matter, but I am very early in the design process. So far I've created my Model and some experimental View components, and I'm using pure JDBC with embedded SQL in my control logic (applying the Command pattern).
I started with JDBC, because I've read in Sun's manuals that this is the right way to start a primarily web-oriented application: start with direct SQL interaction, and then move to EJB as needed. Not that all sources agree on this subject, most newer publications suggest that the EJB spec and container implementations have evolved enough, such that representing even the lightest persistent objects with EJB's is not really such a performance hit after all, and that's indeed the right way to go.
In my application specifically, the model objects are relatively light, and do not critically need distributed transactions, method-level security etc. On the other hand, if I went the JDBC route, I would still have to implement my own persistence, caching, the whole thing, and I doubt I will do it better than the JBossCMP engine would handle the task :-) It seems to me like it would be a waste of time to implement my own persistence layer now, only to dump it later if the application grows?
It seems like CMP EJB's are the easier route, but what are the disadvantages of doing that, if any? Besides, I would really really want my application to be as portable as possible. Handling that in JDBC can be quite tricky, even if you pay attention not to use vendor-specific RDBMS extensions.
Thanks for sharing your thoughts!
Pavel.
