Fluent Relatioships Without EntitySet<T> and EntityRef<T>, but only plain T and List<T> ?

Nov 10, 2009 at 1:18 PM


After working with Linq to Sql for several projects, and facing some of its drawbacks, I find this "fluent" approach really nice and helpful.

As you probably already know, the biggest concern about Linq To SQL is "what if the customer wants also support for Oracle?". Of course, "what if" almost doesn't happen, but still this is a risk for many projects, and needs to be properly handled.

I'm thinking that creating models without the EntityRef<T> and EntitySet<T> (just plain T and ICollection<T>) would add more flexibility. Would it be possible for most of the logic behind model relationships to be handled by "someone" else, but not by the model itself? (I'm talking about all the entity code behind these relationships...)



Nov 10, 2009 at 1:36 PM

I'm glad you find the fluent approach helpful.

It is perfectly possible to use Linq to Sql without EntityRef/EntitySet (see http://blogs.msdn.com/digital_ruminations/archive/2007/08/28/linq-to-sql-poco-support.aspx) but with this approach you lose support for lazy loading.

However, if you're concerned that you may need to use a different database, such as Oracle, then I would highly recommend not using Linq to Sql. Even if you're using POCO models without EntityRef/EntitySet, you'd still have to completely replace the underlying mapping technology due to Linq to Sql's lack of a provider model. In this case, something like NHibernate would be a much better choice as you can swap out the underlying database with relative ease and not need to change the ORM technology (see http://codebetter.com/blogs/karlseguin/archive/2009/10/22/migrating-to-postgresql-with-my-friend-nhibernate.aspx)