Hi Joe. I am no expert but here are my opinions:
1 - No, Hibernate uses 3rd party libraries that just don't have a conversion to .net to allow for compilation. I suppose you could use JNBridge (it is named something like that - I believe Borland makes it to allow native Java and .NET to communicate, basically a remoting wrapper) to allow .NET code to call Java code - of course, that is not LPGL or open sourced.
2 - I have recently been posting some questions to the Discussion Forums for NHibernate. The project has been dead as can be for a while, but there is interest in it. It probably went dead because there are some significant differences between how JDBC and ADO.NET work. The biggest difference is in the Providers (SQL, OLEDB, ODBC, Oracle) and how you configure commands. This is completely transparent to Java - regardless of the actual JDBC provider - a prepared statement look exactly the same (minus the SQL differences). In .NET some can use ? for parameters, some require @paramName, some require :paramName except when creating them - quite a cluster... So the code written around the PreparedStatements will need some redesign for an IDbCommand. There are also more options to handle Transaction in Java. I am not at all familiar with Proxies in .NET, but from what I have read in the developer discussion indicates they are different.
There is no reason the design and concept behind Hibernate can't work. Hibernate's design is soooo much better than any other OSS or commercial offering in the .NET world. Most of the existing ones require you to extend a base class and some even try to offer all the extra crap of Data Binding in your business objects. In particulare I have been browsing OJB-NET, one of the recent discussions is the developer saying he can't do dirty checking if the object doesn't extend an object or implement a certain interface, but that is exactly what Hibernate does! So it can be done, he just doesn't have the design to support it.
3 - ObjectSpaces: who knows. MS has been very quiet on this subject and I have my doubts that the first version or two will work with any data provider other than the System.Data.SqlClient. Their design will most likely use Attributes, I just don't like the idea of decorating my business code with all the persistence configuration, but it is very popular thing to do with XDoclet and Hibernate. The only difference is that with Hibernate/XDoclet you can modify a XML file generated by XDoclet without needing to recompile your code like you do with Attributes.
Just my $0.02
Mike
|