Luca, I am not actually sure how far the admin will allow me to promoty our poduct on thisgroup. In order to give some value to everyone in this posting, I will, though, explain our design decisions - I mean, I will not only answer your questions, but also give you guys some better ideas how such a framework works. Frankly, I can not understand why ANYONE would like o write SQL by hand anymore.
I answer inline starting with Regards Thomas Tomiczek THONA Consulting Ltd. > -----Original Message----- > From: Luca Minudel [mailto:[EMAIL PROTECTED]] > Sent: Mittwoch, 12. Februar 2003 15:46 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Container-Managed Persistence in .NET? > > Thomas thanks for your hints, > I've read the EntityBroker documentation. I like the idea of 'Entity > Set'. I've noticed the deep decoupling between the Db and the objects > EntityBroker enable. > I've some question about the approach and design decisions: > > 1) Some entities have complex persistence requirement so they need hand- > written code, is it possible to seamless put these entities in the same > transaction with entities managed by the EntityBroker (I mean business > objects derived from EntityBroker.EntityObject)? How? No, it is currently not - the support for this may be added in a later point release. We think of adding support for SP's in CRUD operations. Whatever we do, though, will still require full table read access to the tables, OR loosing functionality. There are basically two types of persistence mechanisms out there. Some are "primitive" in their data handling, such as LLBGen and the others. They require you to define your queries at design time. Others, like the EntityBtroker are way more sophisticated. They allow you to define your queries at runtime - in our case using a object based syntax. Now, in order to handle these queries - we then need to be able to access the tables in SQL. So, IF we add support for "user defined persistence", we will definitely expect users from either granting read access on the tables to the broker, OR to loose the query functionality. Now, this might sound minor - but it is VERY easy to make VERY complex SQL Queries with just a few lines of EB query syntax - actually, I would not accept any persistence layer without this feature. The reason for this "being so simple" is that you can basically come up with a query condition like (from an order object): New Condition ("customer.creditrating.agency.address.zipcode", Expression.Like, "23334"). We support full property traversal, and you might NOT want to see the number of tables involved in this condition (at least 4). Normally, the performance of dynamic SQL is also not that bad. We have heard the request for "defined sp persistenc", though, and will act upon it. > 2) Some business rules and constraints are enforced in the Db, does > EntityBroker give the option to have the Db check those constraint? How? > Is it possible to check the Db in a Property Set or in a method (to make > data validation)? There are hook up events that can be used. > 3) Does EntityBroker map Db constraint violation errors to specific > EntityBroker exceptions (uniqueness violated, referential integrity > violated, check constraint XXX violated, concurrence error)? This should happen :-) If you get a SQL error up from the database, this is a bug. > 4) Is it possible to manage transactions without the EntityBroker (just > like BMP does by the setEntityContext and unsetEntityContext methods? > http://java.sun.com/products/ejb/javadoc-2_1- > fr/javax/ejb/EntityBean.html#setEntityContext(javax.ejb.EntityContext)) Not so sure. He link did not describe what java does with the EntityContext. > 5) Can EntityBroker persists a tree of objects (a UML composition = an ER > Weak Entity Type just like Order->OrderItems->etc.)? How? Sure. Just do it. Insert/Update/Delete statements are reordered so that they work in the database, btw. > 6) If I understood the EntityBroker guarantees object instances uniqueness > (so when I ask an entity, say Order 101, that's already instantiated I get > the reference to that instance). But with Optimistic Concurrency is > instance uniqueness still necessary/useful or is it just a complex task > that can be avoided? It is DAMNED usefull. See, that's another rant now - do not never ever accept a framework that does not guarantee object uniqueness. Unless you work in a VERY limited environment or GUI, you WILL encounter situations where you may come up to the same piece of data repeatedly. Uniqueness means: (a) you can rely on == as comparator and (b) there is no chance that you manipulate the same object in two different ways in one transaction, by accident. > Are there public UML models documentation of EntityBroker? No. > And finally a 'philosophical' question: don't you think that the kind of > important and complex tools as EntityBroker should be very very very > light (easy to learn, easy to use... can they be???) or they should met a > wide community acceptance and support (knowledge shared between all > programmers as a common pattern, no vendor lock-in, wide resources for the > maintenance and evolution) to reach they value? Well, do you think pigs can fly? First, they can not be very easy. They are complex tools. Databases are complex tools. They can be easier (We are working on a graphical designer for the objects), but their complexity is not based on the tool, but on the underlying technologies and concepts. Making them light makes persistence tools less powerfull. Now, for the vendor lock in: right. Don't you think people have a right to earn money with their work? And for a no-lockin-API-approach: where is the common API for us to implement, please? Oh, without a least common feature approach. I would gladly make the broker compatible with a common api - just show it to me. I would atually gladly stop developing the broker, if MS finally had some technology. It is just not there. This is not a matter of thinking. I run a company. Developing the broker costs money, which I have a right to try to recover. And there are no standards set right now. I actually believe MS should come up with a tool, but I and others don't have the time to wait another year or two - we need something now.
