Is it still ok to use Linq-to-Sql

Question

When Linq-to-Sql was first released, I used it quite a lot for small and medium sized projects where a true multi-tier architecture wasn't required.

NHibernate, Small Middleware, Overkill

Where I work, we now almost exclusively use NHibernate for true Domain Driven development.

I'm working on a small temporary (a lifetime of probably a year, maybe less) middleware component where NHibernate feels slightly overkill in terms of configuration and keeping the entities up to date. Especially because I haven't got any control over the DB, it sometimes changes, and it's a little bit "legacy".

Some changes were recently made to the DB, and the NHibernate mappings are not very complete.

Linq-to-Sql? Or EF?

I thought it might be easier just to rip out the IRepository implementation I have and replace it with a Linq-to-Sql implementation. Then I can just use lambdas for my simple queries, and just drag and drop the tables in.

RAD But Dead?

In this scenario the RAD elements of Linq-to-Sql make sense. But it's essentially old technology. Should I not use it? I've never used the Entity Framework. Should I use that, is it as easy and quick to use?

cheers

Answer 1

Is it still OK to use Linq-to-sql?

Yes. It is OK to use any technology which allows you delivering the product in time, with required functionality and quality. You can still find projects using ASP, ADO, VB6. One reason why Microsoft technologies have very hard time in many international corporations is that their products have very short lifetime. Linq-to-sql was on the market less then 2 years and was deprecated by Microsoft but companies / community argued about that and Microsoft changed their strategy little bit. Linq-to-sql doesn't have new features but it is still supported and a fully functional technology.

Will Linq-to-sql or EF solve your problems?

It depends. Perhaps yes and perhaps no. Don't believe to marketing announcements about RAD. Sometimes I feel that people think that RAD is about designer. No. Tools supporting RAD are about well defined API which is easy to understand, easy to use and doesn't contain unexpected behavior (Principle of least surprise) - you will use the API to quickly prototype the application but it still requires understanding and practice. NHibernate's mapping is still prototyping when you compare it with manually doing whole data access. We can even follow the basic rule of good framework: Easy things are easy to do and hard things are possible. That is something that NHibernate accomplish much better then EF or Linq-to-sql.

If you know NHibernate but you don't have any real world experience with EF or Linq-to-sql, you can be sure that neither Linq-to-sql or EF will increase your productivity in first one or two projects where you use it. If you don't have too much experience with NHibernate changing to EF or Linq-to-sql will probably don't cause temporary lose of productivity.

I also don't think that EF or Linq-to-sql will generally help you in situations where database changes. As I remember Linq-to-sql designer doesn't have update mapping functionality at all and because of that it is very often used completely without designer so you must still manually modify mapping. EF's updating model from database can be helpful here but it is not a silver bullet. Some updates can require manual modification of EDMX file (huge XML).

At last be aware that NHibernate's mapping features are much more powerful especially when working with legacy databases. Linq-to-sql's mapping features are very limited, it is mostly 1:1 mapping of tables to classes with some exceptions (basic TPH inheritance). EF offers more complex mapping features but it somehow expects a correct design of the database.

Answer 2

If you (and your coworkers) are comfortable with NHibernate, then it should be just as RAD as Linq to SQL. There's no reason not to use L2S as long as you understand it's not going to get much in the way of updates and improvements from Microsoft, but in my experience if you know how to use both frameworks already, no need in re-doing the work just because L2S might be a little more RAD