Subsonic Vs NHibernate

Question

What is the concensus on when to use one of these tools adversed to the other? I find Subsonic very useful in terms of getting things done quickly, but on large projects it

Answer 1

I believe you should stick to one which you can utilize the best. The ultimate goal is the productivity and good performing quality code. If you know SubSonic in and out then stick to it and if you know NHibernate in depth stick to NHibernate. This is very subjective question. You should also consider the fact that what your team-member are having expertise with. If you are good at it you will be able to easily maintain it.

I've seen large projects using SubSonic whereas NHibernate is already famous and used widely.

The decision of picking ORM does not solely depend on the ORM itself.

Answer 2

I have evaluated both and I believe it would not be fair to recommend one over the other without understanding what your goals are. In your question you stated the differences well and I believe that needs to be your deciding factor. Personally I have used both and will continue to use both depending on the project.

• NHibernate is my choice for larger scale projects because its uses of lightweight POCO's. If I were to ever switch out my ORM "I believe" this would be much easier to refactor.
• SubSonic is my choice when I have a smaller scale project. I believe that performance wise SubSonic scales well. However, I feel tightly coupled with it because it is so engraved in my project. In smaller project I can still switch it out because the code base is so small and it really helps me rip out code as advertised.

Answer 3

For what its worth...I have had the opportunity to use both technologies quite abit more since asking this question. And I have to stay which if these technologies you choose matters very little. Sure NHibernate allows your business entities to be slightly less coupled to your database structure, but I still find that there are many occasions where you still have to bend to the will of the database.

In my opinion the only true way it to totally seperate your Domain Model from your Database model is to write your own DTOS (essentially POCOs for passing data around), and then map them back to your ORM of choice in your data layer. But in most cases, this approach will me more hassle than its worth.