Arguments for moving from LINQtoSQL to Nhibernate?

Question

Backstory: Hi all, I just spent a lot of time reading many of the LINQ vs Nhibernate threads here and on other sites. I work in a small development team of 4 people and we don't even have really any super experienced developers. We work for a small company that has a lot of technical needs but not enough developers to implement them (and hiring more is out of the question right now).

Typically our projects (which individually are fairly small) have been coded separately and weren't really layered in anyway, code wasn't re-used, no class libraries, and we just use the LINQtoSQL .dbml files for our pojects, we really don't even use objects but pass around values and stuff, the only time we use objects is when inserting to a database (heck not even querying since you don't need to assign it to a type and can just bind to gridview). Despite all this as I said our company has a lot of technical needs, no one could come to us for a year and we would have plenty of work to implement requested features.

Well I have decided to change that a bit first by creating class libraries and actually adding layers to our applications. There is a big opportunity to make some good apps with overarching functionality. I am trying to meet these guys halfway by still using LINQtoSQL as the ORM yet and still use VB as the language. However I am finding it a b***h of a time dealing with so many thing in LINQtoSQL that I found easy in Nhibernate (automatic handling of the session, criteria creation easier than expression trees, generic an dynamic querying easier etc.) So...

Question: How can I convince my lead developers and other senior programmers that switching to Nhibernate is a good thing? That being in control of our domain objects is a good thing? That being able to implement interfaces is a good? I've tried exlpaining the advantages of this before but it's not understood by them because they've never programmed in a true OO & layered way.

Also one of the counter arguments to this I can see is sqlMetal generates those classes automatically and therefore it saves a lot of time. I can't really counter that other than saying spending more time on infrastructure to make it more scalable and flexible is good, but they can't see how.

Again, I know the features and advantages (somewhat enough I believe) of each, but I need arguments applicable to my context, hence why I provided the backstory. I just am not a very good arguer I guess.

(Caveat: For all the LINQtoSQL lovers, I may just not be super proficient as LINQ, but I find it very cumbersome that you are required to download some extra library for dynamic queries which don't by default support guid comparisons, and I also find the way of updating entitites to be cumbersome as well in terms of data context managing, so it could just be that I suck hehe.)

Answer 1

The main argument of switching to new technologies that will always convince people is: "Saves your team approximately x hours of time in project y". They will compare it with the argument "It costs z hours to learn the new technology". It will be a mental switch and a learning curve for your team. When you work on a lot of smaller projects, it might be right to compare the "learning time" with the "saved time" of multiple projects. Sometimes it is worth the effort to convert existing projects to the new technology and sometimes it is better to use the new technology on new projects. You can make your arguments stronger by showing that you are prepared to use the new technology and have thought about how to give your team help and directions to learn the new technology faster.

Answer 2

In my opinion, Linq2Sql probably was a better fit for the development model you are trying to move away from. As you move into a richer domain model, the reasons for moving to NHibernate will become more apparent. Some of the biggest issues I can see are:

1. Linq2Sql isn't extensible like NHibernate is (interceptors etc...).
2. Linq2Sql only really handles eager loading well to the parent / child level. Once you hit parent / child / grandchild relationships things will start to go off the rails.
3. NHibernate's HQL makes it easier to control how the SQL is generated for tricky queries than Linq syntax.