Last post Mar 20, 2010 04:37 PM by texx
Mar 17, 2010 07:13 PM|sah302|LINK
Hi all, pretty new to programming and at work we use LINQ, I haven't done anything advanced with it yet, but my friend told me nhibernate is way better and showed me some examples of it being awesome, I thought wow this is cool. However, my friend hasn't
used LINQ really at all. LINQ is what we use at work so I would like to stick with it..so can I do the following things in LINQ:
1) In Nhibernate if I have a an object which contains more objects within it such as having a UserBlogPost object which contains a User object and a BlogPost object, if I just call .Save() on UserBlogPost it takes both objects and writes them to their appropriate
tables, I guess this is due to a .xml mapping file for each object so there is no that = this for every property. Can this be done in link?
2) Can you use LINQ to do generic stuff such as the following:
public abstract class EntityDao<InterfaceType, ImplementationType, IdType> : IEntityDao<InterfaceType, ImplementationType, IdType>
where InterfaceType : IEntity<IdType>
where ImplementationType : Entity<IdType>, InterfaceType
private ISession session;
public EntityDao(ISession session)
this.session = session;
public InterfaceType getOneById(IdType id)
InterfaceType entity = default(InterfaceType);
if (id != null)
//.get is a hibernate method
entity = this.session.Get<ImplementationType>(id);
3) Are there any other limitations to LINQ when compared to Nhibernate or visa versa? It's been really hard to find a direct comparison, everyone says LINQ is super awesome, but at initial glance LINQ seems lack some great features, but as I said I am fairly
new to both and haven't done anything advanced in either. Commentary from more versed people would be much appreciated.
Mar 20, 2010 03:55 AM|sah302|LINK
Just doing a bump in case anyone has a clue about this. I really either want to stress using Nhibernate at work (which takes some massive convincing points) or figure out how to do this kind of stuff with LINQ.
Mar 20, 2010 04:37 PM|texx|LINK
We are currently switching from nHibernate to Linq-to-Sql for various reasons, but mostly because using any open source software creates some headaches and paperwork.
1) Yes, Linq-to-Sql handles this by default. If you have a parent object, child object, child object however deep. And you change the grandchild/child object, and save the Parent, the save cascades down through them.
2) Yes, you can write generic methods that can return single objects. We used the ActiveRecord pattern with nhibernate, so I spent some time implementing it with Linq-To-Sql. It wasn't terribly difficult, and I fould some useful articles like
3) I think the biggest problem we have run into with switching to Linq-to-Sql, is having to handle the DataContext somewhat manually. nHibernate does a great job of handling the DataContext within itself, persisting across sessions etc., but with Linq-to-Sql,
you have to decide how you want to do it, and implement it. A great article on that
All in all, I think our transition has gone very smoothly. And I don't know of any functionality that we used in nHibernate, that we don't have in Linq-to-Sql.