hi edward,
thanx for the critics :) I recognize that this approach is not perfect.
actually I really like the idea of cmp, but until ejb2.0 with dependent
objects is available, I don't think it is really useful for real-life
projects. of course there are o/r mapping tools and you can use bmp, but I
am lazy ;), that's why I try to think of something that could possibly make
the life easier.
and I would be really interested to see some uml diagrams of the approach
you use - if this is not a top-secret-proprietary-solution.
anyway, comments below:
:-----Original Message-----
:[mailto:[EMAIL PROTECTED]]On Behalf Of Kenworthy, Edward
:Subject: RE: [jBoss-User] HOWTO: Replacing Entity with Session bean
:>-use fine-grained CMP Entities
:Stop right there ! EJB Entites are expensive for the container to manage.
:Have lots of teeny entities and you'll overwhelm the server.
well, this is not as bad as it seems. as far as I remember jboss (and
perhaps other servers) don't use that much resources for the beans, so
having a thousand or a few don't really hurt you much. and if you use them
wisely, the numbers don't really grow that huge.
:>-use Value Objects (or Data Objects, Data Holders - same thing - these get
:>generated by ejbdoclet, you don't have to write them)
:That's what we're doing. You have to be aware that there are issues with
:this approach, the first being that you have to duplicate the EJB entity's
:structure, more or less, in the value object (breaking encapsulation).
:Second is locking.
because of synchronization of data structures - see the comment - these get
generated and updated automagically by ejbdoclet each time your ejb
structure changes. and can you explain the locking issue?
:>-these finders should return *Data Holder collections* instead of remote
:>interface collections
:Yuch. This sounds like the approach we initially took, eg use the container
:to the full (eg cmp) and the kludge everything around it to make it work.
:Don't do it.
not much to kludge around IMHO. most of it would be automated.
:>these session beans should be used for retrieving large result sets for
:>read-only access.
:Personally I dislike these kind of tiny session beans. They lead to
:fragmented systems.
this doesn't mean you can't have session beans that map to your use cases,
which in turn can use these session beans. it becomes even simplier, if you
have your business logic in separate classes or servlets, which only require
data to operate.
:>in case you need to create new/update/remove existing records in db, you
:>just use the CMP beans - call create() with your data or look it up using
:
:This goes against one of the most basic patterns in EJB design - allow
:access to your entities only via session beans.
my statement doesn't mean you expose entities to the client directly. this
can be read as 'in case business logic needs to create...'
therefore, if you want to use session beans to store your logic - you're
welcome, if you have business classes (as servlets or smth else) you can do
it from there. this adds additional concerns in writing the business logic,
but so does every other approach.
:>I recognize this would break the integrity of data in some cases, but in
:web
:>environment this would work IMHO - you only see the actual
:snapshot of data
:>anyway.
:
:Uhm. So what you're saying is, don't do the job properly because we're only
:developing for the web ?
well, I am not a perfectionist - if something satisfies my requirements, I
consider it as an *option*.
but can you give an example of a clean implementation of accessing large
sets of data in ejb, say, listing a thousand of products or filling a
combobox with user names?
thanx for feedback,
--andrius
:>what do you guys think?
:
:I think it stinks.
:
:Edward
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
