-----Mensagem original----- De: andreas oberhack [mailto:[EMAIL PROTECTED]
> 1) Developers in that environment have special needs: > > a) ease of use. This is the most important thing! They do not > want to care about technical things - they want to concentrate on > business logic. No factories, no xml, even no connection handling, no > SQL if possible. Just POJOs - all as easy as possible. Yes, yes!!! I'm looking forward to this, too! > b) stabibility. The software must life for at least 10 years - > interfaces should not change during that time. Hmmm.. Possibly the same here. > c) flexibility. I have to roll back transactions because of > business logic for example. And maybe I'll need nested transactions too. > And I need long transactions and bulk operations. We need transactions, and in a transparent fashion - easy to use - JTA solves this. > 2) enterprise applications are complex: Normal object models consists of > more than 100 persistent classes. Components consist of 1 to 20 > persistent classes (covered by a component facade). Yup. I suggest you take a look at 'Patterns of Enterprise Application Architecture' book. I'm following the Domain Model to create a nice and decent Object Model and a Service Layer to push the use cases. > Taken all this, I don't see automatic transaction management at the > moment. It is easy and smart - agreed. But I'm loosing to much > flexibility. Losing? Where? The imperative level of transactional management I'm proposing here is the same offered by EJB. It is clean and works. Don't see why it would be a problem. regards, hammett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
