Aug 3, 2005 / Persistence Strategy (from Spring founder)
8 commentsRod Johnson, founder of Spring framework, made great presentation on persistence strategies. He suggests to use O/R mapping framework in 90% of cases and layering/interfaces/Spring to separate persistence and domain model. I wonder when good IoC frameworks with persistence integration support will appear in .NET world. Spring.NET does not provide anything useful, Castle provides NHibermate integration and it works, but I don't like Castle. I can't clearly express my impression, but something in Castle is not attractive for me. Well, the one reason is in lack of IoC configuration, so you have to extend Castle to do something useful. Maybe this is the case.
But, anyway, Castle is the only useful thing for now and its architecture is quite flexible. So I hope things will change. And Castle project needs more support from .NET community for sure.
posted by Michael Dubakov @ 4:46 AM
8 Comments:
Hi,
Not to be too lame here but "I feel your pain", as I also have the need for persistence integration in projects I'm involved with. The Spring.NET team is busy getting a 1.0 release out the door with IoC and AOP support. Integration with persistence tools is on our road map and we *will* get to it. This year promises to be a very productive one for Spring.NET, so hang in there!
Cheers,
Mark
Based on what you said that "Castle project needs more support from .NET community for sure"? Our mailing list has almost 90 subscribers, we're a growing, healthy and exciting community.
If you don't like castle for your personal reasons, please state them clearly. I'm positive it doesn't have anything to do with technical reasons.
About integration: we provide Nhibernate facility, ibatis facility + db4o and prevalence. I personally like ActiveRecord that makes me extremelly productive.
Cheers,
hammett
>> Based on what you said that "Castle project needs more support from .NET community for sure"? Our mailing list has almost 90 subscribers, we're a growing, healthy and exciting community.
Oh, maybe I didn't express my thought good enough. I just want to say that I wich Castle project faster progress. As I see almost all effort spent on MonoRail right now, but IoC has many areas of improvements as well. For me Windsor is more important than Monorail, but this is just my selfish requirements. I evaluate Spring.NET and Castle right now and I feel if I choose Castle it will require more effort to adopt it for my needs than Spring.NET. But, again, this is just my needs, nothing more. I don't want to say that Castle has bad architecture or something else. Don't get me wrong. I just try to estimate my effort required for Spring vs. Castle adoption.
>> I haven't added any specific support for NHibernate yet, but it looked like it wasn't really necessary just to be able to handle creating the NHibernate objects from configuration.
I like DAO templates, session management and transaction management provided by java Spring. This is a real time saver. I believe Spring.NET will have the same feature. And recently we decided to change O/R mapping framework in TargetProcess. Oh, how I regret we didn't used IoC before! Migration going to be quite painful and time consuming. So I don't want to repeat the same mistake twice and spread UnitOfWork over the whole application and expect IoC framework will be able to control persistence session by itself.
>>Integration with persistence tools is on our road map and we *will* get to it
Thank Mark :)
But, as I mentioned above, we are going to replace O/R mapping layer soon and for now I don't know what to choose: Castle or Spring.
Castle provides NHibernate integration, but less usefull IoC. Spring provides better IoC, but no Nhibernate integration. So this is going to be hard choise for us :)
I'm still trying to figure out what is less usefull IoC under your conception. If you want to describe services interconnection within XML, then Castle is not for you. Windsor is going to RC1 within the next month, and I really dont think there are missing features (we have just introduced support to System.ComponentModel interfaces)
Can you post about it/expand it? From what I see you dont seem to have much hands on experience with inversion of control.
I have experience with Spring on Java. Sure, I don't write IoC by myself, so it will be harder for me to argue with IoC creators. I'll try to post about Castle vs. Spring basedon our requirements. So this will be specific post, not a general one.
Hi,
I have the same needs as you. I am building an application that "needs" both IoC and NHibernate. And I agree with your comments. I find Spring.Net IoC more complete and above all you have more control on object creation via the XML config file (just some examples : I can have a config file with properties that will be overriden by another config file, I can specify if a class is a singleton or not, I can access static properties, etc.). BUT to me the whole project is less mature than Castle and I spared a lot of time and efforts using Catsle facilities (Both NHibernate and Transactions).
So I firste choosed Spring.Net for my project (as I didn't knew Castle) and wrote a lot of (dirty) code in libraby to be able to transparently integrate NHibernate. It was dirty code but it worked. Then I discovered Castle and remove the dirty code from my library at the price of having to write a specific class in my project to handle Castle container initialization.
I tried to make things as loosely coupled as possible so shifting from Spring.Net to Castle was not a big deal.
I think that doing it the other way won't be a big deal too. It could happen if Spring.Net finally appears to be more useful to me than Castle.
To Finish I would just add that what helped me in my decision was the "support" of .Net 2.0. I didn't have any problem with Castle.
I think that I will stick with the IoC container that best fit in Miscrost .Net Framework, making its use completely transparent. We're yet far from it (for instance, I would like to use Miscrosoft System.Transaction ou EnterpriseComponent attributes for transactions instead of castle ones).
Regards,
Olivier.
Post a Comment
<< Home